Really appreciate the improved dShot telemetry accuracy in 32.8.3, plus a question about this data

[jimkazmer]

A big thank you for the improved data you can see in the two charts below! The first one is using 32.8.1.2, and the second one is using the (improved) beta 32.8.3; all the firmware settings were (almost) identical (I added screen shots of those as well). The vertical axis is the motor's RPS*256 (not eRPS); to get the actual motor RPS, divide by 256. The horizontal axis is time in milliseconds.

The ESCs are being given bidirectional dShot commands for 30% power for 10 milliseconds, then 90% power for 10 milliseconds, then 30%, then 90% etc... the bidirectional dShot commands are being sent at 4000Hz. The telemetry from the 30% "decelerating" speeds are the red lines and the telemetry from the 90% "accelerating" speeds are the green lines. The new commands occur at the next 4000Hz update interval after time=0. The motors being used are 1200kv HobbyKing propdrives 2830s.

I was doing this to see the latency/response times of the ESCs. As most of you already know, it takes much more than 10 milliseconds for the motors to reach their new speed. For my purposes, I need to pulse the motors at these short intervals (sometimes as short as 4 or 5 milliseconds), so I am changing the ESC speed setting long before it ever approaches its target speed.

Are there any tips for changing the configuration settings or the dShot commands sent to avoid the "hesitation" seen in the red (decelerating) data that is occurring around 1.5milliseconds and in the green (accelerating) data around 1.0 milliseconds? Any tips for further improving the speed changes in such short intervals?

[sskaug]

Thank you for sharing the data. I assume this motor is the common 12N14P configuration. In which case 31000 in the above graph is about mechanical 121RPS and 848 electrical RPS. In which case one electrical rotation is 1.18ms. Part of the noise reduction is filtering, although very modest - for erpm periods larger than 512us, a sliding average of weighing the new sample with 0.5 is used. For shorter erpm periods the weight of the new sample is 0.25. So in your case, this weighing should cause something in the order of 0.5ms of delay. Of course your system will have other delays too. The Dshot command takes some time. And it takes some time to send the erpm data back. And your test setup most likely also has other delays.

[jimkazmer]

The motors are 9N12P configurations. Quantizing the delay is useful, thank you for sharing that. The telemetry values I get from the 108Mhz ESCs are much nicer looking than those I get from 48MHz ESCs. However, I too have noticed the dShot initialization issues with the 108MHz ESCs that you have mentioned in other posts.

[jimkazmer]

On a previous post, which I can't seem time find, you mentioned the maximum update rate for the telemetry value. This has likely changed with your new filtering algorithm. You mentioned it when I asked about the duplicate/triplicate repeated values in a prior post when using dShot at 8000Hz. In the above charts (at 4000Hz), you can see that the 32.8.1.2 values are frequently doubled up, but in the 32.8.1.3 charts the values are smoothed out by your new averaging and that there are not "repeated" values. On slower 48MHz ESCs, instead of getting two of the same values in a row, I'll get three of the same value. What are the factors that impact the telemetry sampling rate?

[sskaug]

The erpm period is updated for every electrical revolution, if the previous period was shorter than 1024us. If the previous period was longer than 1024us, then period data is updated 3 times per electrical revolution.