Variable torque at low to moderate RPM

[ChrisRosser]

Following some testing of BLHeli32 with an inertial dyno I noticed variable torque at moderate RPMs.

It is present regardless of PWM or timing setting and has been confirmed to affect Mamba F55 Pro 128K and Tekko32. This issue is not present with AM32 software which makes unlikely to be a test system issue.

Mamba F55 Pro Tekko32

[sskaug]

Thank you for sharing, this is interesting data. Some questions to best understand the data: Being an inertial dyno, I assume each trace is taken during one acceleration run? What is the time it takes to do that run? Is the RPM data mechanical RPM? Do you use a 14pole motor? Do you know why BL32 torque starts at a lower rpm than AM32?

[ChrisRosser]

Yes each trace is taken during one acceleration run which takes approximately 2 seconds. Logging is at ~100Hz. RPM and torque are both mechanically measured: RPM using an optical tape, torque using 2 load cells. The motor is a XING2 2207 1855KV with 14 poles. I'm unsure why the starting RPM and Torque are different for BL32 vs AM32. The test is as follows. 1100 throttle for 5 seconds. Start logging. 1600 throttle until 25000 RPM. Stop logging. I guess BL32 simply doesn't apply as much torque at 1100 throttle as AM32 so after 5 seconds it is at a lower RPM and torque.

[sskaug]

The difference at 1100 is most likely due to different settings for minimum throttle. I do have a hypothesis for the torque ripple you see with BL32. I assume you use a standard servo tester? In that case, throttle signals are most often sent at a 50Hz rate, meaning that there is a new throttle pulse every 20ms. BL32 limits max power for low rpms (as I'm sure AM32 does too), and this power limit is updated on every input pulse. It is possible that this is what causes the ripple you see. In a "normal" multirotor environment this is not an issue, since there the input signal rate is high enough to be smoothed out by the low bandwidth of the mechanical system. In your testing, can you try to increase rampup power? And/or disable low rpm power protection?

[ChrisRosser]

Here is a test at Dshot600

And Dshot600 with Low RPM power protect off

Wiggles still seem to be there.

[cbf123]

It might be useful to show the current draw on the same graph. In the Youtube video comments you mentioned that the current consumption drops relatively smoothly while the mechanical torque varies.

[ChrisRosser]

Sure @cbf123 . Here it is! Does this suggest that something might be going on with commutation? ESC current and torque are not directly proportional.

[sskaug]

Thanks for testing again. I assume your Y-axis is still torque, and that the title "Motor Optical Speed (RPM)" is misleading?

Now we do not have a test setup similar to yours, we generally test with the load that the ESC normally sees (i.e. prop :)). Replicating a test like yours, where throttle is increased over about 2 sec (gradually, as immediate acceleration of course will be very fast), this is what we get: Some ripple in the acceleration curve, but not very significant.

Now, there are some features in BLHeli_32 (which are similar to those in BLHeli_S) that can be potential causes for ripple. The most likely is the extension to the digital bemf filter designed to reduce effects around where motor pwm frequency matches commutation harmonics. Another might be variable averaging weight of commutation period updates. With those two modified, this is what I get: Maybe less ripple, or maybe just differences in measurement noise.

Anyway, if you can test these modifications, please let us know the exact code you use (the name that shows up in BLHeliSuite32 or the Android app).

[ChrisRosser]

@sskaug Happy to test. MAMBA F55 128K 4110

I have to mention that a slow throttle ramp is a very different test from an inertial dyno run. Ramping throttle slowly requires minimal torque from the motor at low RPMs whereas the dyno demands full torque across the RPM range.

[sskaug]

Sure, such a dyno test condition probably resembles e.g. car operation conditions more than air operation conditions. Great that you can test. Here are three testcodes: https://github.com/bitdump/BLHeli/tree/master/BLHeli_32%20ARM/Misc%20testcodes The "MC" code has the bemf filter feature disabled. The "FC" code has the variable commutation period averaging weight feature disabled. And the "BOTH" code has both disabled.

[ChrisRosser]

Test results: MC Firmware FC Firmware BOTH Firmware AM32 for Comparison

Analysis:

Disabling BEMF Filter definitely improves Torque with no visible penalty in terms of current consumption. BL32 with BEMF disabled has a steppy torque curve compared to AM32 which is smoother.

[sskaug]

Great to hear, thank you for testing. The effect from the bemf filter feature is noticeable but probably not very significant in most systems. And with "byRPM" pwm, it will not be necessary. I think we can consider removing it and use a code similar the the "MC" testcode, going forward.

[sskaug]

The above plots are more informative than the initial plots you shared, as individual measurement points are now shown. What is it that determines the sample rate in your system? Are the above curves taken with a high rate input signal (like e.g. Dshot600 at 4k or more)?

[sskaug]

The low rpm power protection scheme use has a lot of inheritance from older BLH versions, and looking at is it in detail, the quantization steps at high power levels can be noticeable, particularly for the high inertial load system. So a new testcode is published on github "LOQ", reducing these quantization steps. Would be great if you could test :).

[ChrisRosser]

Great to hear, thank you for testing. The effect from the bemf filter feature is noticeable but probably not very significant in most systems. And with "byRPM" pwm, it will not be necessary. I think we can consider removing it and use a code similar the the "MC" testcode, going forward.

I would agree. For multirotor applications torque required is minimal at low RPMs most of the time. Slightly better responsiveness might be possible with more torque but at very fast change of RPM a lot more comes into play. My test system is not yet capable of measuring such fast phenomenon.

[ChrisRosser]

The above plots are more informative than the initial plots you shared, as individual measurement points are now shown. What is it that determines the sample rate in your system? Are the above curves taken with a high rate input signal (like e.g. Dshot600 at 4k or more)?

The max sample rate I can do is 100Hz. How that relates to RPM points depends on how fast the system accelerates. I can use heavier flywheels to slow things down but that can increase the peak current and increase the risk of smoking motors.

[ChrisRosser]

The low rpm power protection scheme use has a lot of inheritance from older BLH versions, and looking at is it in detail, the quantization steps at high power levels can be noticeable, particularly for the high inertial load system. So a new testcode is published on github "LOQ", reducing these quantization steps. Would be great if you could test :).

Yep happy to test!

[ChrisRosser]

LOQ test code doesn't seem to have made much difference. However, the peak torque is matching AM32 with BEMF filter disabled which is good.

[sskaug]

Thanks again for testing. So there appears to be kind of a plateau from 5-7000rpm. At this point the only rpm dependent mechanisms in the code are bemf sample averaging and low rpm power protection. Still can't figure out how any of them should give any plateauing...

[ChrisRosser]

Thanks again for testing. So there appears to be kind of a plateau from 5-7000rpm. At this point the only rpm dependent mechanisms in the code are bemf sample averaging and low rpm power protection. Still can't figure out how any of them should give any plateauing...

Could it be something time based? Is there a certain throttle setting for a number of ms on a sudden increase? Could it take a few ms to update a certain value/parameter to reflect the new higher throttle setting?

[MartinWa]

Could it be something time based? Is there a certain throttle setting for a number of ms on a sudden increase? Could it take a few ms to update a certain value/parameter to reflect the new higher throttle setting?

A slower ramp up would show that I guess? Perhaps testing that is hard to do, I guess it would need a larger wheel and that might smoke the motor?

[ChrisRosser]

@MartinWa I can try a ramp up with a larger flywheel. I can also do ramps at various throttle settings. Currently I've left rampup power at default. Here are the options:

2 wheels 100/200 kgmm2 Throttle settings 20-50% Rampup power

Let me know what you want to try

[sskaug]

Thanks again for testing. So there appears to be kind of a plateau from 5-7000rpm. At this point the only rpm dependent mechanisms in the code are bemf sample averaging and low rpm power protection. Still can't figure out how any of them should give any plateauing...

Could it be something time based? Is there a certain throttle setting for a number of ms on a sudden increase? Could it take a few ms to update a certain value/parameter to reflect the new higher throttle setting?

Except for limiting mechanisms (low rpm, voltage, current, temp, spoolup) there are no limitations on throttle. Every input dshot frame is immediately converted to and applied as the corresponding motor pwm. Presumably in the testing, voltage, current and temp limiting does not apply. And the motor is already spooled up. Low rpm limiting limits power linearly from about 32000 erpm (default rampup setting) and down.

[slackista]

Are there any research going on with this issue?

[slackista]

Just want to simplify this data https://github.com/bitdump/BLHeli/issues/658#issue-1428883343 In mid RPM the torque is ~60% lower than motor can deliver. Another word for the same performance motor should have + 60% bigger stator volume, it es much bigger, heavier motor.

[kenkamm]

Has this issue been resolved, and if so, in which version?

[sskaug]

Improvements are implemented in the testcode here: https://github.com/bitdump/BLHeli/tree/master/BLHeli_32%20ARM/Dshot%20extended%20telemetry%20testcode

[kenkamm]

Thank you! Will this new code make its way into the official release? If so, when?

[sskaug]

It will, but not yet known when. We would like to see many installs of testcode before we publish an official release.

[truglodite]

Curious how you count the number of installs of testcode... configurator telemetry?

FWIW, I'm flying 32.95 testcode on a tekko32 f4 mini 45 v1.3, and it's working great.

[sskaug]

Great to hear that it runs well for you. We count installs when BLHeliSuite32 or the BLHeli_32 app validates the serial number upon code flashing. 32.95 installs are increasing, not very fast, now in the few hundreds, it seems generally people are happy also with 32.9.