Thread Tools
Jan 22, 2020, 12:37 PM
Registered User
Thread OP
Quote:
Originally Posted by Willsonman
Is there any chance to have an implementation of a "governor mode"? Meaning, you set the throttle to a certain level and the prop will spin at the same constant speed no matter what. I have an application that this would be useful for and I feel like it could easily be done on the controller rather than some crazy jumbled mess of parameters on my radio.
At the moment, no. We understand that there are application areas out there that could benefit from this, but for now we do not have any plans for it.
Sign up now
to remove ads between posts
Jan 28, 2020, 09:07 PM
Registered User

Bidirectional DSHOT Telemetry


@sskaug, can you confirm that bidirectional telemetry only includes motor speed and not the 3d motor direction ?
Jan 29, 2020, 01:17 AM
Registered User
Thread OP
Yes. The only thing the ESC sends back to the FC over the signal cable, is RPM info.

But - the FC can also send commands to the ESC over the signal line, to change direction etc. This is used in e.g. turtle mode.

Then there is the "bidirectional 3D" mode (that can be selected via BLHeliSuite32), where the motor will move "fwd" above center throttle and "rev" below center throttle.
Jan 29, 2020, 01:33 PM
Registered User
Yes, that is what I am seeing in the FC code. I believe the 3d ramp-up power is not working correctly in your latest software. While it is acceptable in my 8-inch quad similar to the one you purchased from me, I am now trying micro-quads and when the motors reverse they would just fall out of the sky. I have addressed this by modifying the flight controller code to reverse the motors with a very high throttle value until they reach a minimum RPM to synchronize the motors before applying the throttle and PID control to the motors. When checking the bidirectional telemetry RPM, I have added a 50ms delay to make sure the motors have reversed before reading the motor RPM. I was just trying to determine if I could further improve this approach.

Video of a sample flight after modifying the FC code:
Zappy Z100 With 3D Motor Synchronization Reversals. (3 min 0 sec)
Jan 30, 2020, 11:30 PM
Registered User
Are we going to have 96k or 128k or even higher PWM frequency in the future?
Jan 31, 2020, 02:37 PM
Registered User
Thread OP
Quote:
Originally Posted by rc_corner
Yes, that is what I am seeing in the FC code. I believe the 3d ramp-up power is not working correctly in your latest software. While it is acceptable in my 8-inch quad similar to the one you purchased from me, I am now trying micro-quads and when the motors reverse they would just fall out of the sky. I have addressed this by modifying the flight controller code to reverse the motors with a very high throttle value until they reach a minimum RPM to synchronize the motors before applying the throttle and PID control to the motors. When checking the bidirectional telemetry RPM, I have added a 50ms delay to make sure the motors have reversed before reading the motor RPM. I was just trying to determine if I could further improve this approach.

Video of a sample flight after modifying the FC code:
https://www.youtube.com/watch?v=nlYEZhBlHyQ&t=4s
Hey - that's really cool and clever.
Small motors are a different beast from the larger ones we focused on last time. Reliable reversals are challenging, maybe because of little inertia. But also many small motors can handle fast large power steps very well, so rampup power can be maxed, or even unlimited, without desync.
Jan 31, 2020, 02:42 PM
Registered User
Thread OP
Quote:
Originally Posted by Liujinlongljl
Are we going to have 96k or 128k or even higher PWM frequency in the future?
Yes. New codes from now on can have higher pwm frequencies than 48kHz. We are currently delivering codes with up to 96kHz.
Unfortunately this is linked to bootloader, so codes not initially designed for it, are limited to 48kHz.
Feb 01, 2020, 09:08 PM
Registered User
Quote:
Originally Posted by sskaug
Yes. New codes from now on can have higher pwm frequencies than 48kHz. We are currently delivering codes with up to 96kHz.
Unfortunately this is linked to bootloader, so codes not initially designed for it, are limited to 48kHz.
So that means we need a hardware update( changing to new ESCs ) to have 96k PWM frequency?
Feb 02, 2020, 08:42 AM
Registered User
One thing to keep in mind is that while higher PWM frequency will decrease inductor losses (due to ripple current), it will also decrease the current and therefore reduce torque.

This becomes more of an issue the higher the motor inductance.
Feb 02, 2020, 11:45 AM
Registered User
Hey, long time blheli user, but I'm tackling a project that requires 8 motors running on 2 HobbyWing 60a 4in1 escs and a Lux F7 fc. Using betaflight and an X8 motor configuration.

There seems to be very little info about 8 motor setups on the internet, so I just don't know what to expect. Will the blheli32 configurator see all 8 escs or can it only see 4 at a time? That's my main concern as it should work alright once the escs are configured. Any insight is appreciated.
Feb 03, 2020, 01:27 AM
Registered User
Thread OP
Quote:
Originally Posted by Liujinlongljl
So that means we need a hardware update( changing to new ESCs ) to have 96k PWM frequency?
Yes - that is the way we are currently set up. Not sure if there is much benefit from going above 48kHz on the typical mid or large size quad. For sure active braking suffers from higher frequency. It is probably primarily the very small motors, like 10mm and below that can have a significant benefit from 96kHz.
Feb 03, 2020, 05:27 PM
Registered User
sskaug, have you ever considered ditching "damped light" for actual braking?

Tracking steady-state RPM for given throttle lets you develop an RPM-throttle relationship (it's roughly linear, but you could also add current into the equation to get a more accurate result).

Using the relationship and given the current RPM and desired throttle you could calculate the delta in RPM. If it's negative engage the brake by shorting the motor phases until the desired RPM is reached.
This could be done without any PWM. Adding PWM however would allow to reduce braking force either by adding in passive freewheeling or even a bit of acceleration (like "damped light") or doing actual regenerative braking.

The former options would make sense if the short-circuit braking is too violent and could be user-configurable.
The latter could make sense in something like electric scooters, though I don't know if BLHeli32 is used in those areas.

If the delta is positive the opposite could be done for acceleration, also without PWM (for maximum acceleration) or with PWM for reduced acceleration.

PWM then would theoretically only be needed at a steady throttle state to prevent oscillation between braking and accelerating and of course for the tracking of RPM as mentioned in the beginning.
Last edited by xnor; Feb 03, 2020 at 05:43 PM.
Feb 04, 2020, 01:18 PM
Registered User
Does anyone know of any BLHeli32 ESCs that support cell voltages from 1S?
Most I found start from 3S, some from 2S.
Feb 04, 2020, 01:57 PM
Registered User
Thread OP
Quote:
Originally Posted by xnor
Does anyone know of any BLHeli32 ESCs that support cell voltages from 1S?
Most I found start from 3S, some from 2S.
At least there is the Racerstar 8A: https://www.racerstar.com/racerstar-...cer-p-194.html
Feb 04, 2020, 02:04 PM
Registered User
Thread OP
Quote:
Originally Posted by xnor
sskaug, have you ever considered ditching "damped light" for actual braking?

Tracking steady-state RPM for given throttle lets you develop an RPM-throttle relationship (it's roughly linear, but you could also add current into the equation to get a more accurate result).

Using the relationship and given the current RPM and desired throttle you could calculate the delta in RPM. If it's negative engage the brake by shorting the motor phases until the desired RPM is reached.
This could be done without any PWM. Adding PWM however would allow to reduce braking force either by adding in passive freewheeling or even a bit of acceleration (like "damped light") or doing actual regenerative braking.

The former options would make sense if the short-circuit braking is too violent and could be user-configurable.
The latter could make sense in something like electric scooters, though I don't know if BLHeli32 is used in those areas.

If the delta is positive the opposite could be done for acceleration, also without PWM (for maximum acceleration) or with PWM for reduced acceleration.

PWM then would theoretically only be needed at a steady throttle state to prevent oscillation between braking and accelerating and of course for the tracking of RPM as mentioned in the beginning.
There are many possibilities for how to control the motor. But there is not much you can do before motor sounds "rough". In order for a smooth operation of the motor, it is as far as I have seen only simple, pure pwm that works.

Closed loop motor control can be a way to go to get an even faster (accelerating and retarding) response from the motor - it is implemented in BLHeli. But due to then locking down the relationship between throttle and rpm, setting up and designing the rest of the system is more complex.


Quick Reply
Message:

Thread Tools