A list of answers to frequently asked questions which may be helpful to your better understanding of BLHeli_32. More Q&A’s will be added.
Why BLHeli team chose to take BLHeli_32 closed source?
Answer from Steffen “sskaug“: From starting as a personal project to make my mCPX helicopter brushless, BLHeli as come a long way.
Some of the major milestones were when we decided to pursue the multirotor segment as well, still as a hobby project, where people flashed various (non BLHeli) ESCs with BLHeli FW. Still moderate activity and efforts. But then at some point, probably starting with the Littlebee, manufacturers started making dedicated ESCs for BLHeli FW. Which I think was a major step forward for the community, as now we have a plethora of very good ESCs for multicopters. Then there was a new milestone where we decided to pursue BLHeli_S, as smoothness of BLHeli was still inferior to other ESCs in the market. And by this time we had close to 20 manufacturers doing BLHeli_S! Supporting which is actually a significant workload. So then came the next milestone – what was next? ARM 32bit MCUs were a pretty obvious choice, as they are flooding the market from various manufacturers and are getting quite cheap. But at least for me, I was at a point where I did not want to undertake the workload I knew would come without some returns. So this is where we are now, closed source with a modest fee for some returns on the work we actually do. While still supporting many manufacturers and keeping the generally low cost profile of BLHeli.
Hopefully BLHeli_32 will also serve the community well, and bring ESC performance and the hobby as a whole even some more steps forward.
I can’t connect to my BLHeli_32 ESC with pass-through even with the latest BLHeliSuite32 app. My FC is loaded with the latest firmware. However I can connect to other ESC (not 32bit) without problem with the old BLHeliSuitE.
I am getting an error when trying to flash new firmware: “Unable to establish server connection!”.
Answer from Oscar Liang: This error occurs when you have no working internet connection on your computer. BLHeliSuite32 checks if your BLHeli32 ESC’s are genuine before flashing new firmware to them. No internet, no check and thus it fails.
I am getting error “Initialization of serial 1wire passthrough or 4way interface failed! Please check Betaflight revision for support of serial 1wire passthrough or 4way interface!”
Answer from Oscar Liang: I was also getting this error when using my Naze32 (F1) flight controller, even with Betaflight V3.2 already installed. I had no way around this error, and I had to use a F3 FC in the end. Maybe BLHeli32 passthrough is not supported in F1 FC’s.
Wanted to know if Blheli_32 is currently stable enough/appropriate to be used on larger platforms running low KV motors (400-500 kv , 16-18 inch props) and on 6s. Planning to use the airbot wraith plus which at 50A and 6s rating, seem like a pretty good option for a larger build. The adaptive timing feature in blheli_32 is also a plus for larger rigs i imagine.
Answer from Steffen “sskaug“: Hopefully BLHeli_32 will also be well suited to larger rigs. When testing with a difficult (=desyncs easily) motor (an old RCtimer 4215 630kv) at 6S with, I think, a 12 or 14 inch prop, auto timing was amazing at holding sync. Timing is held as low as possible (for good efficiency), but also increased whenever required to avoid sync loss due to long motor demag time.
Also, the “max acceleration” parameter is added, as a complement to / replacement for “low rpm power protection”. “Low rpm power protection” is primarily targeted at the FPV racing segment, and can cause issues for larger motors, particularly low kV on low voltage.
Is the max erpm limit increased from blheli_s ? From my understanding there’s no real world benefit but i’d like to know anyways.
What motor control (hope my terminology is correct) mechanism are you using ?
Is it single edge pwm ?
Will you be implementing other technologies such as FOC ?
Is there any actual benefit to us quad pilots runnning say FOC over pwm ?
Answer from Steffen “sskaug“: No problem. BLHeli_32 on a STM32F051 runs a bit faster than _S. For medium fast input rates (say 1-2kHz), it will run up to about 500k erpm. For fast (16-32kHz) dshot, it will run up to about 400k erpm. This is fast enough for any practical setup, I think.
However, there are more powerful ARM MCUs out there, BLHeli_32 also supports a 72MHz Cortex M3 core that executes code about twice as fast as the F051.
Hardware pwm is used, and the F051 harware is good, and very easy to use . Which has enabled the programmable pwm frequency.
FOC is interesting, but still not readily available and mature for FPV racing applications as far as I know. But maybe soon it will, who knows.
Well, I haven’t been working with FOC myself, so it’s hard to say what’s good and bad about it. At least one thing that is challenging is that the ESC needs to know exact motor parameters in order to work properly.
OneShot et al is still supported? When I did a bunch of tests earlier, it didn’t seem to care about OneShot125 timing.
Answer from Steffen “sskaug“: Oneshot and all is still supported, and I’m not aware of any issues.
what’s the significance of that speeding up beep sequence at the beginning, which seems to be in addition to the old BLHeli arming beeps?
Answer from Steffen “sskaug“: That speeding up beep sequence means the ESC for some reason is not activated. See page 9 of the user manual.
At least for Rev32.0, all ESCs shall be activated by the manufacturer. If some Rev32.0 or later ESC happens to beep “not activated”, it should be returned to vendor.
Answer from Oscar Liang: You will need to flash Betaflight V3.2 or newer firmware on your FC, currently it’s not yet released officially and still in Beta, but you can download it and the latest BLHeli32 suite from HERE. Load the firmware target for your FC locally, and flash (shouldn’t need to short bootloader pins).
…… To be continued