32.7->32.8 regression in ERPM measurement

[jacqu]

Hi,

Our lab is developing a Simulink block to access Beltaflight in hardware-in-the-loop simulations: We modified betaflight to be able to send a custom MSP command at a high frequency. The command returns, among others, the ERPM velocity of the motors acquired with bidirectional DSHOT. We noticed a regression between 32.7 and 32.8: in the same conditions (same Simulink, same throttle value, same setup) with the same ESC configuration (Low PWM frequ = High PWM freq = PWM freq of 32.7=48kHz), the ERPM measurement is far more noisy with 32.8 with huge spikes as shown in the following Simulink plots. All data have been acquired at 200Hz, the ERPM signal is converted to RPM with the following code in the modified betaflight firmware (the betaflight function getDshotTelemetry has not been altered): (uint16_t)lrint( (float)getDshotTelemetry(i) * 100.0 * 2.0 / motorConfig()->motorPoleCount )

The same behavior occurs with various ESCs. Here we are using the Flywoo F745 AOI.

Thanks for looking into this since it may yield important disturbances for the dynamic notch filtering in betaflight.

Jacques

[sskaug]

Hi Jacques

Thank you for this detailed report, we will surely investigate it.

Some questions:

• What are the blue and yellow traces above?
• Is it the erpm frequency that is 200Hz?
• Do you see the same noise at other erpms?

Thanks, Steffen

[jacqu]

Hi Steffen,

Thanks for your feedback. The blue and yellow traces are the RPM of two motors running simultaneously at different speed (resp. throttle 1076 and 1168) sampled at 200Hz. So 200Hz is the sampling rate of the RPM measurement within the Simulink block. In other words, Simulink is doing a 200Hz sub-sampling of Betaflight bidirectional DSHOT measurement that runs at 8kHz on the FC.

You can see that with firmware 32.7, the noise level increases when the speed increases (throttle 1076 on one motor yields approximately 4500rpm and throttle 1168 on the other motor yields 8000rpm). The noise is clearly higher at 8000rpm wrt 4500 in the first plot. When increasing speed further, the noise continues to increase.

With firmware 32.8, the behavior is different: the variance of the noice signal seems to decrease with speed but the amplitude and the number of spikes tend to increase. This is very odd. Could the spikes be related to sampling rate overruns whose probability increases with motor speed ?

Thanks for looking into this. For our research, we plan to use this measurement to regulate the motor velocity. This is possible with 32.7 despite the noise amplitude but almost impossible with 32.8 due to the huge spikes. You can see the kind of system we are developing in this video (on this system we used KISS ESCs but we are now switching to BLHeli).

dextAIR on YouTube

Best, Jacques

[jacqu]

This is a step response of a motor speed regulation loop with BLHeli 32.7 using bidirectional DSHOT ERPM feedback. The velocity measurement is filtered with a 150Hz cutting frequency low-pass filter. Y-axis is in rpm and x-axis in seconds. Unfortunately, this regulation does not work very well on 32.8.

[sskaug]

Thanks again for the info. We will surely dig into this. Would you be willing to test experimental codes to help diagnose this? Which exact code does your ESC use?

[jacqu]

Thanks again for the info. We will surely dig into this. Would you be willing to test experimental codes to help diagnose this? Which exact code does your ESC use?

Yes, we would be glad if we could help. The board we currently use is this one (FLYWOO_GOKU406S_PRO): Link to product

[sskaug]

Great, so now I have posted three testcodes: https://github.com/bitdump/BLHeli/tree/master/BLHeli_32%20ARM/Noisy%20erpm%20data%20testcode

All will show up as rev32.75, the difference between them are given in the hex file names. There is one 32.7 equivalent and one 32.8 equivalent in order to establish baseline correlation. And then there is one "EQU_32P8_NO_FASTERPMUPDATE" where I have reverted an update to the capturing of erpm data, where the sample rate was increased from 1x per electrical rev to 3x per electrical rev for low erpms (longer erpm periods than 1024us).

[sskaug]

Actually, thanks to your very good plots, I'm pretty sure I have nailed the cause of the large spikes. So I believe that the "32P8_NO_FASTERPMUPDATE" testcode does not have spikes. And also a new hopefully fixed Rev32.81 code posted in the above folder shall not have spikes.

[jacqu]

Dear Steffen,

We tested the 3 experimental firmwares at 2 speeds: 4000 rpm and 15000 rpm. Below, the results. I would like to thank my PhD student Miguel Arpa Perozo for all the experiments. All the plots have been autoscaled so that it is easy to read the peak-to-peak amplitude of the noise [given within brackets below].

Best, Jacques

32P8 4000 rpm: [600] <- peak-to-peak amplitude of noise 32P8 15000 rpm: [2500] 32P8_NO 4000 rpm: [200] 32P8_NO 15000 rpm: [2500] 32P7 4000 rpm: [150] 32P7 15000 rpm: [2500]

[sskaug]

To summarize the numbers: 32P8 4000 rpm: [600] 32P8_NO 4000 rpm: [200] 32P7 4000 rpm: [150]

32P8 15000 rpm: [2500] 32P8_NO 15000 rpm: [2500] 32P7 15000 rpm: [2500]

Are the rpm values for a 14pole motor?

So at 15000 rpm, there is not much difference in noise.

But at 4000 rpm, 32P8 is a lot more noisy than 32P7, maybe due to the spikes (although they do not appear clearly in the plots)? The 32P8_NO code is a little bit more noisy than 32P7, which makes sense as the elevated noise is traded for a higher update rate.

Thanks, -S

[jacqu]

So at 15000 rpm, there is not much difference in noise.

But at 4000 rpm, 32P8 is a lot more noisy than 32P7, maybe due to the spikes (although they do not appear clearly in the plots)?

The 32P8_NO code is a little bit more noisy than 32P7, which makes sense as the elevated noise is traded for a higher update rate.

Thanks,

-S

I'm not sure that Miguel changed the min and max PWM frequency to 48kHz after updating from 32.7. Indeed these settings reset to 24kHz even if 32.7 PWM frequency is set to 48kHz. I asked him and should have the response tomorrow. In this case I will provide you with tests at 48kHz, maybe the PWM frequency has some influence.

Jacques

[jacqu]

So I had just the confirmation that all the experiments were made with PWM min = PWM max = 48kHz.

Below, you will find zoomed out plots where the spikes can be seen in 32P8. Strange enough, the spikes seem to disappear for a speed > 10000rpm. The motors are X-NOVA Lightning V2N 2208-1700KV.

32P7: 32P8_NO: 32P8:

[sskaug]

Again, thank you for the test data, it shows exact correlation with expectations. The spikes will only be present for RPMs below approximately 5600 (14P motor).

It would be great if you could also verify that there are no spikes on the Rev32.81 code posted. This code has a fix, and if all is good, we can publish this for all targets.

[jacqu]

Thanks a lot for this fix. We will send you extensive tests of the firmware candidate, probably tomorrow. We will test it over a larger speed range (3000-25000rpm) and also test it at another PWM frequency (24kHz) since we noted that the noise tends to increase as the PWM frequency decreases.

[jacqu]

Below you will find plots with the 32.81 firmware at 24kHz and 48kHz. The noise at 24kHz is not very different in amplitude though it seems sub-sampled wrt 48kHz, which is normal. Note that there are still some small spikes around 7000rpm. Above 20000rpm the signal/noise ratio degrades a lot. Is there a way to reduce this noise at high velocities ? Indeed, vibrations on drone frames may be maximal at these rpm, so feeding a noisy signal to Betaflight may yield degraded performance for RPM filters when it is most needed. Note that Betaflight filters this signal with a first-order LP filter (default cut frequency=150Hz). But even with this filter, there is still a lot of noise remaining. All the tests have been made on a 14-poles motor. The y-axis in the plots gives the mechanical rpm.

Thanks for your help ! Jacques

24kHz:

48kHz:

[sskaug]

Thank you again for testing. So from these, I'd say that the severe spikes are gone, which should make it worth publishing this fix for all targets.

We will also continue to investigate and try to reduce the noise level.

Thanks, -S

[jacqu]

which should make it worth publishing this fix for all targets.

Yes, it definitely desserves publication. Thanks for continuing investigating and improving this firmware.

Best, Jacques

[sskaug]

Please try out this code: https://github.com/bitdump/BLHeli/tree/master/BLHeli_32%20ARM/Rev32.8.1%20testcode

[StrawHatSam92]

Newb question: How do I add this 32.8.1 test code to BLHeli_32 suite so I can flash my ESCs with it? I get this error window that pops up saying: "Missing RECORD_MARK at file start error".

I uploaded the .hex file by clicking "Ignore" with the walking stick figure icon after going into flash BLHeli tab.

UPDATE: I figured out that I had to download the .hex file a weird way by right clicking on "raw" and save link as. After doing that though I am still unable to flash 32.8.1 because I get an error now saying "ESC#1 Flash"FOXEER_Reaper_4IN1_65A" failed in 0.00s Either the Flash is wrong or corrupted or of an unsupported revision."

UPDATE 2: I installed the latest version of BLHeli_32 Suite and now the flash works correctly after placing the .hex file into the hex files folder of my BLHeli directory. I test flew the Foxeer Reaper 65A ESC with 32.81 and no issues to report. It flies well. Next I will be testing the iFlight 80A 4in1 ESC with 32.81

[sskaug]

Check out this: https://github.com/bitdump/BLHeli/issues/547

[Myllerman]

Please try out this code: https://github.com/bitdump/BLHeli/tree/master/BLHeli_32%20ARM/Rev32.8.1%20testcode

Can the "Half pwm low frequency testcode" also get this update? At least the AIKON_AK32PRO_50A_4IN1_MINI_6S_Multi. Would be much appreciated.

[sskaug]

Now done. Although the rev is still 32.81, the code is now updated to the same functionality level as the generic 32.8.1 testcode

[Myllerman]

Now done. Although the rev is still 32.81, the code is now updated to the same functionality level as the generic 32.8.1 testcode

Thank you for very fast response! Now i can update all my quads.

[daleckystepan]

I have tested 32.8.1 with fixed PWM 24kHz and variable PWM 24kHz->48kHz. Unfortunately variable PWM does not behave well. iFlight_BL32_4IN1_Multi_32_81

Mid-throttle oscillations. I am not the only one: https://www.rcgroups.com/forums/showpost.php?p=47637207&postcount=4468

Thank you for the investigation.

[sskaug]

Thank you for sharing this data! So is it correct that in this case, the oscillations occur where dynamic D-term filter stops tracking lower?

The way BLHeli_32 currently does variable pwm, is by a linear relationship between throttle and pwm frequency. This has the benefit of increasing motor responsivity, as when throttle is lowered, pwm frequency is lowered, which leads to stronger active braking. But of course this increased responsivity can also lead to unwanted effects, like noise increase or oscillations. So I would anticipate that in some systems the stronger braking can be beneficial, but as you show, it can also produce unwanted behaviour in other systems.

We will shortly publish a testcode where we will add the option of letting pwm frequency track motor rpm, in a similar way that AM32 does it. Such a way of controlling pwm frequency will probably generally be more gentle, but also not provide the potential benefit of increased responsivity due to stronger braking.

[StrawHatSam92]

I can corroborate this mid-throttle oscillation issue with variable PWM enabled. In the air, the drone behaves much like when you have bent propellers that cause vertical oscillations that usually translate into pitch bobbles at slow cruising forward flight. This is on a 7" running 2808 1500kV motors on 6S

[daleckystepan]

I am not sure that this is the case of braking. 24kHz PWM on the first image shows the most aggressive breaking (due to the lowest PWM frequency) and there is no issue. I can also attach BlackBox log and it seems to me that the oscillations are not caused by breaking.

Anyway I am willing to test new FW that will have similar behavior as AM32. Let me know. btfl_all_16.8.bbl.zip

[sskaug]

Now a new testcode Rev32.8.2 is posted that also adjusts motor pwm frequency in a way similar to what AM32 does. Here is a plot of how the various frequencies move with respect to motor RPM: This is for a ~2500kv motor running a 5" triblade prop at 4S.

The two green curves are for variable pwm between 24k/48k and 16k/96k. The blue curve is with variable pwm "By RPM".

The fundamental commutation frequency is really problematic, but will in most systems not meet motor pwm frequency. BLHeli_32 handles the second harmonic quite well, so with fixed pwm frequency, it is generally not problematic. The third and higher motor commutation harmonics are handled very well by BLHeli_32.

[daleckystepan]

Looks promising after few test flights.

dterm brown = new variable PWM 24k to Max by RPM red = static 32k PWM

Feeling: More thrust on low throttle (probably due to lower PWM) and smoother/quiter on high throttle/rpm (probably due to higher PWM)

[sskaug]

Great to hear. Thank you for testing and sharing detailed data.

[Myllerman]

Now a new testcode Rev32.8.2 is posted that also adjusts motor pwm frequency in a way similar to what AM32 does. Here is a plot of how the various frequencies move with respect to motor RPM: This is for a ~2500kv motor running a 5" triblade prop at 4S.

The two green curves are for variable pwm between 24k/48k and 16k/96k. The blue curve is with variable pwm "By RPM".

The fundamental commutation frequency is really problematic, but will in most systems not meet motor pwm frequency. BLHeli_32 handles the second harmonic quite well, so with fixed pwm frequency, it is generally not problematic. The third and higher motor commutation harmonics are handled very well by BLHeli_32.

Looks great! Would really like to try it on my AIKON_AK32PRO_50A_4IN1_MINI_6S with the half pwm baked in too. Is it possible?

[sskaug]

Now posted

[rotorgeeks]

Is it possible to determine if an ESC has the 'fixed' revision of 32.8 or is the fix to update to the now available 32.9? Suite only displays 32.8

[sskaug]

Rev32.9 is the way to go. If you have a Hobbywing ESC, you will still have to wait a bit, for HW to release their code.

[sskaug]

Actually HW code has been released just now :).

[rotorgeeks]

Great, thanks. It almost seems that 32.8 should disappear as an option.