-
-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RPM steps at high inputs #39
Comments
Hi there, thanks for the detailed info and plots! There's some approximation happening when scaling from DShot throttle value to PWM duty cycle, as well as converting commutation period to e-period (to RPM). DShot throttle scaling has been improved compared to BLHeli_S, but I'm not sure if this is the problem. The ERPM-TEST release should make RPM telemetry as precise as possible for the protocol, but I haven't been able to see any significant improvement from this. Was this test made at 24kHz PWM frequency? It would be interesting if you could compare it to 48kHz to see if this affects the output. I also made these test files a while ago that uses the original BLHeli_S scaling, if you want to compare: v0.14_bls_throttle.zip I can also try to compile a version that scales DShot throttle to PWM without approximation (at the cost of underestimating and not being able to reach 100% duty cycle) to see if this would remove the non-linearity of the RPM output. |
Here is the version without approximate scaling, so a DShot throttle value of 0-2000 will correspond to around 0-97% PWM duty cycle: It would be interesting to see if this affects the linearity of the RPM output. |
@mathiasvr Happy to test whatever you come up with. |
@ctzsnooze Do you still have these logs by any chance? 😅 |
Hi, and thanks for working on improving BLHeli-S.
I'm sure you're aware of this, it's a 'feature' of BLHeli-S, but I was wondering if you can do anything to improve it a bit.
What I'm referring to is the way that at high DSHot signals - high throttle - the ESC doesn't respond smoothly, instead it generates a series of steps. At least that's what the RPM data shows.
Here I am steadily increasing the motor drive signal in Betaflight's motors tab, by holding my up arrow. The entire pass takes about 16 seconds.
This image shows the last 10 seconds. Motor drive signal from betaflight in the top panel, RPM as measured by DShot Telemetry and recorded in the DShot Telemetry debug, with the debug mode set to
motor_test
.Bluejay was set to defaults with dithering active.
Note how there are 5 large, flat steps above about 80% throttle. This is a significant non-linearity that would markedly reduce the PID loop's ability to control the quad whenever a motor is driven above 80%.
I'm fairly sure this has always been the case with BLHeli-S but have always wondered why, and if anything can be done to improve it.
There are other brief steps at about 35 and 66% throttle.
The text was updated successfully, but these errors were encountered: