bitdump
RPM spec racing - ERPM measurements accuracy question
Hello
Quick introduction: A new RPM spec racing steadily becomes a new thing. Its the type of racing where every quad matches with weight and propellers, and runs a special BF version that limits the RPM at pretty low numbers, basically making everyone slow and close to each other at full throttle. This brings very close racing, and more enjoyable to watch the race. The racing becomes more about choosing the correct line rather than reaction time. For example 18000 rpm limit for 6S drone is about 50-60% of full 6S RPM.
Most of the racers running Blheli_32 32.9. This brings a question of how accurate the ERPM readings in blheli_32 are, and what factors can affect the accuracy. It is possible that one ESC spins faster/slower despite it reporting the same ERPM as the others?
A quick talk with AM32 and blheli_s devs brought up a few things:
-
Internal high-frequency oscillator like efm8bb21 can actually be 24.0 or 25.0Mhz depending on the temperature and manufacturer. That brings +/- 2% for ERPM readings. Another example is stm32g071, based on the datasheet it can be +/- 1-2% depending on the temperature and also some "TRIM" options can affect the accuracy.
-
The commutation period readings in microseconds or half-microseconds bring it's own small error.
-
A lowpass filter on top of commutation period readings
((3*old_value) + new_value)/4brings its own error as well if done in integers.
Wondering what are the BLHELI_32 dev thoughts, what affects blheli_32 accuracy in RPM readings, and if are there any ways to improve the situation.
For BLHeli_32 there is no significant quantization of erpm period. And the accuracy of the averaging calculation is also good. What is left, is the accuracy of the internal RC oscillator. Which varies a bit between the various MCU manufacturers, but is in the order of +-2%. The only way to improve this, would be to add a crystal to the ESC design.
For BLHeli_32 there is no significant quantization of erpm period. And the accuracy of the averaging calculation is also good. What is left, is the accuracy of the internal RC oscillator. Which varies a bit between the various MCU manufacturers, but is in the order of +-2%. The only way to improve this, would be to add a crystal to the ESC design.
Could you please elaborate, if it is not a secret, what's the size of quantization for erpm period? And what's the accuracy of the averaging calculations, do you use half of us, or quarter or 1/8? Or any other techniques?
For erpm period, the transmitted quantization is of course 1us. The internal is generally smaller, normally by the MCU clock frequency. But some MCUs only have 16bit timers, so for those the intarnal quantization will be larger for lower erpms. But then the period is long and the quantization error will be small. Anyway, at 18krpm 14pole motor, the erpm period will be ~475us, so even a 1us quantization error is small. The averaging operations are done using 32bits, with the timer quantization.
For erpm period, the transmitted quantization is of course 1us. The internal is generally smaller, normally by the MCU clock frequency. But some MCUs only have 16bit timers, so for those the intarnal quantization will be larger for lower erpms. But then the period is long and the quantization error will be small. Anyway, at 18krpm 14pole motor, the erpm period will be ~475us, so even a 1us quantization error is small. The averaging operations are done using 32bits, with the timer quantization.
How you calculated the ERPM period? Let's say 18k rpm, standard 14 poles motor.
Sorry, typo, I meant 14pole motor. Then erpm is 14/2 times mechanical rpm.
sorry if i sound a little confusing. Im not very familiar with the terms yet. But what i learned from other firmwares devs, is that the actual time measurement happening between the "null crossings". And these "null crossings" are happening 6 times per ERPM period (6 steps per electrical revolution)
So 475us of ERPM we also need to divide by 6, resulting in ~79us. And 1us of 79 is ~1.3% error. Or this is not how its happening in BLHELI_32?
No. The 475us is the number that is measured in BLHeli_32 (with the very fine MCU clock quantization). And then it is being sent back to the FC quantized to 1us.
No. The 475us is the number that is measured in BLHeli_32 (with the very fine MCU clock quantization). And then it is being sent back to the FC quantized to 1us.
much appreciate the answers! it make sense now. So from BLHELI_32 the ony error that might come is from the oscillator. And there are two possible reasons as i understand (plz correct me if i'm wrong):
- Manufacturing accuracy
- Temperature difference
Blheli_32 uses internal oscillators everywhere on all processors: F0, F3, F4, G0 etc, does it? What's the proper way to google the accuracy on these oscillators, and how to figure out which one is installed on a particular ESC?
There is a component of both manufacturing accuracy and of temperature drift. The oscillator is internal to the MCUs. You can find info on them in the MCU datasheet that you can download from the MCU manufacturers.
@sskaug checking for example F411 datasheet Am i reading it wrong? But it looks like depending on the temperature the drift can be 4% or even 8%... That sounds like a lot
That is really bad. Good that FCs use an external quartz crystal.
The 'F051 is much better:
That is really bad. Good that FCs use an external quartz crystal. The 'F051 is much better:
Wondering if the ERPM readings could be adjusted with the temperature on the ESC side, most of them have thermometers, haven't they?
Nope. We do not know exactly how frequency changes with temperature. And it will vary from unit to unit. If higher accuracy is required, then an external quartz crystal should be added to the design. BLHeli_32 does support that, but of course this means dedicated hardware.
Another alternative might be to use something with 'known good' timing (like the incoming DShot signal) as the reference for the ERPM calculation. I think @joelucid used this approach way back when.
No
Another alternative might be to use something with 'known good' timing (like the incoming DShot signal) as the reference for the ERPM calculation. I think @joelucid used this approach way back when.
Oh that sounds fancy, to use signals from FC to self-calibrate the ESC clock.
That can probably work for setting the timing of the bidir dshot return data. But for getting to sub 1% accuracy, I doubt it will be feasible. One aspect is the challenge of making such an accurate replicated timing, another is that in my experience dshot timing from the FC can vary significantly. Certainly between BF and KISS, I've seen that, but possibly also between BF targets.
That can probably work for setting the timing of the bidir dshot return data. But for getting to sub 1% accuracy, I doubt it will be feasible. One aspect is the challenge of making such an accurate replicated timing, another is that in my experience dshot timing from the FC can vary significantly. Certainly between BF and KISS, I've seen that, but possibly also between BF targets.
Maybe not sub 1%, but at least avoid 2%+ error? @SteveCEvans might be able to help, why dshot timing from FC can vary?
The datasheet is giving errors of around 2% across a 85C temperature difference, but I think it's fair to assume that during a race, the difference in esc temperatures between each competitor will be quite small and thus, clock drift due to temperature would be negligible?
