In this article we will discuss some of the latest ESC development and hot topics: BLHeli_S firmware, hardware PWM and 32 bit MCU. This article is created by Adriel Perkins.
BLHeli_S – New Firmware
BLHeli has released a new code geared for new hardware in ESC’s (electronic speed controllers). It uses the BLHeli 14.5 base firmware revision and improves upon it. It’s specifically designed for new ESC’s such as the Aikon SEFM 30A ESC. Here are a list of improvement from BlHeli_S.
- BLHeli_S delivers a throttle response that is smoother than previous BLHeli, thanks to the hardware PWM. Two MCU’s support this for BLHeli_S, namely the BusyBee1 at 24MHz and the BusyBee2 at 48MHz.
- It will have the same good sync holding properties as base BLHeli.
- BLHeli_S does damped light only.
- It has motor PWM that is Synchronous to the MCU master clock, as it is generated by hardware. This makes the motor run more silently.
- It has very small throttle steps. The resolution varies between hardware configurations (MCU clock speed and driver type), and is between a nominal 512 steps and 2048 steps.
- Supports very high motor Speed: BB1 MCU can support up to 350k eRPM, and currently the BB2 is set to 500k eRPM.
- Supports regular 1-2ms input signal, as well as Oneshot125, Oneshot42 and Multishot. Auto-detected when the ESC sees an input signal.
All these improvements look promising and when reached, definitely will change the way our multirotors fly!
You should also check out this guide about how to choose ESC. Check out this article to learn about ESC firmware.
The changes in programming are directly related to the ability of improved hardware that is being implemented. As SSKaug mentioned, this new line of ESCs are running the BusyBee1 (EFM8BB10F8) and the BusyBee2 (EFM8BB21F16) MCU’s (Microcontroller Units). These two MCU’s are different than the previous Silabs chips that many ESC’s have been using. The reason these MCUs are going to be better is because instead of using software PWM they will be using hardware PWM that is synced to duty cycle.
The great thing about using dedicated hardware to generate the PWM is that the speed at which the ESC writes the values to the motors is doubled! With old Blheli ESCs and software generated PWM signals, the ESCs write to the motors at a 16khz rate. With hardware generated PWM it’s bumped up to 36khz. These means that your motors are getting input even faster which allows for better response. KISS ESC’s are an example of this. They have hardware generated PWM and the smoothness and response you get with those is hard to beat.
Is 32 bit ESC better than 8 bit?
Currently the Aikon SEFM 30A ESC is the only ESC being tested with BlHeli_S on it. Of course, there will be many more ESCs to make the switch to BlHeli_S in the future. At the moment there are a few different options. Some of the best and most popular ESCs that will be competing with the Aikon ESC during its release are:
- KISS 24A RE ESCs
- DYS XM20A and 30A ESCs
- XRotor 30A and 40A (40A may also be BlHeli_S capable, unconfirmed)
- SEPM32 ESC
- VGood Firefly ESC
Three of these ESCs are actually using 32 bit processors on them. Being that they are 32 bit ESCs, they’re capable of much more processing and storage. These ESCs are the KISS24A RE ESCs, the SEPM32 ESCs, and the VGood Firefly ESCs. The other ESCs (pretty much all OTHER ESCs) use an 8 bit processor.
More processing power is generally better with every bit of technology. However, in this case there really isn’t a difference in actual performance. ESC’s are not even close to the 8 bit processing capacity at the moment. In the future 32 bits may become a requirement as coding gets more complex. Right now the only difference between the two is from a coding perspective. The 32 bit ESCs can be programmed in C++ because of the added bytes, but the 8 bit ESCs have to be programmed in assembly. Does it make a difference in practice? Only if you’re a programmer and only know C++ not assembly and cannot take the time to learn the syntax.
Personally, I’m very excited about the improvements BlHeli is going through. I’ve been flying BlHeli for a long time and even tried SimonK and others back in the day. It’s amazing how far ESCs have come and how much an improvement they have made to flight characteristics of multirotors. I look forward to testing these ESCs in the future and comparing them in real life situations to other ESCs. Keep your eyes out for them!
Author: Adriel Perkins Join us as a guest writer and help move the hobby forward.
Novice question on quadcopter esc. I noticed that quadcopter esc’s are cheaper than other esc’s. That makes me want to use them in a different way. I am trying to build a low cost underwater thruster to move a fishing line out about 100 yards then stop. I do not want to add a speed dial controller or wireless controller to limit cost. My plan is to use a dc timer and set a cut off time interval. Will a quadcopter esc fit the bill? Can I program the quadcopter esc to use a default speed on lack of wireless signal and just run at a selected speed. Can you recommend an esc and or programmable interface? This is the thruster.. hawk hobby 860rpm 16v hp 300watts on Amazon for 52.99. Thank you.
I flashed my Hobbywing Xrotor 4in1 40a in connection with my Hobbywing F4 Flight Controller in BLHELI-Configurator on my imac and after flashing my 4 motors sounds clicking hard in staccato and both, BLHELI-Configurator and BLheli-Suite do not read my esc until now.
What can I do?
If you have a information, please tell me. Thank‘s.
Have a nice day,
I´m having a problem of hot motors. I only tried them at hover and some flips but no fpv yet. Stock PIDs, all filters on, flip32 f4 fc, racerstar rs 30a lite s, dhsot600, 8khz/8khz, fc soft-mounted, screws not touching the windings. I tried going to dshot300 but motors still getting hot. Some told me to try multishot. Question is, esc´s where dhsot ready out of the box (cap removed from factory), do i have to flash them with a special firmware in order to get multishot working?
i have cicada 20a x2 esc and i need the blheli_s code firmware i have messed up bad
Are blheli_s escs going to be compatible with a fc designed for blheli protocal instead such as the lumenier lux
BLHeli is a firmware, it’s not a protocol :)
Yes any FC that is capable of outputing PWM or Oneshot or Multishot would work with bLHeli_S :)
How do I calibrate the Little Bee 30A ESC with BLHeli_S, in Betaflight/Cleanflight/BLHeliSuite? Thanks.
I Have just received 4 XRotor 40A ESC (asian pacific) all the items passed “Anti-counterfeit Code” meaning that they are all genuine original.
When I was about to flush them with blheli I noticed that the PCB is different than the one seen in the blheli guide, on mine the MCU is F394 but it is turnd 90 degrees as well as the programming pinouts.
One other change is that the new ESC is using a new driver which is single IC is FD6288 where the old driver uses a 3 separate IC NCP5106B.
New Driver: FORTIOR FD6288 250v 3 phase HVIC.
Internal 200ns dead time.
link to the new driver:
I have contacted hobbywing and they have confirmed the the new circuit is genuine .
I have attached images of the new and old PCB.
I have ordered only 4 ESC, so if i fail to flush it with blheli I am left with only 3 ESC and no quad.
I couldn’t attache images, so I have opened a thread in the “diydrones” forum.
I couldn’t attache images, so I have opened a thread in the “rcgroups” forum.
“C”, not “C++”….
What do you mean by XR40A “could” be compatible to blheli_s? i thought it needs to have a specific mpu like BusyBee1/2 ? Do you have any further informations on this? as it would be really great if i could try out blheli_s on my xr40a as people say its so smoooth :)
Greetings from Germany
You write: “Only if you’re a programmer and only know C++ not assembly and cannot take the time to learn the syntax.”
C++ is not just a different programming language compared to assembly, it’s more like the difference between drawing a cartoon film like about 100 years ago at the Walt Disney Company and producing the same film now with computers and animation software. In theory you can get the same result but drawing is probably at least 100 times slower.
Summary: C++ programmers will be able (at least in theory) to make huge changes in relative short time like hours compared to days with assembly.
That’s rubbish. A programmer profound to a certain MCU type does not need much more time. Otherwise no one would do so. Everything has its pros an cons. With assembler, programming a LCD user menu may be more painful, but programming hardware in real time environments is done quite fast, and most important: It is 1:1 exact, so 100% hardware predictable, and easy to change. Most inner core programs of medical devices, measurement equipment, and (as you can see here) ESC’s as well, are written in assembler, just to give a few examples. There is an ISO standard for life saving equipment that demands assembler code for core functionality. Stop yelling ‘it is old and obsolete’ just because you do not understand its purposes and benefits.
Anyone tried installing BLHeli_S on DYS XM20A ESCs? Is there any benefit? I want to try it on mine
They lack the required hardware (hardware PWM) to run blheli-s.
I don’t see any hex files for XM20A ESCs. Is that list just a running list of the best performing ESCs? Or is it a list of BLHeli_S compatible ESCs?
Their not running BLheli, but i really like the ESC32’s with its stm32, closed loop rpm mode and can-bus interface.
Don’t know why can-bus isn’t used more already for speed controller interface. I saw that the Kiss FC has room for a can chip, hope that others will follow.
You sure they’re 32bit? I’ve read this a few times now, but I’ve looked up the BusyBee MCU specs over at SiLabs, and they specifically call it an 8bit microcontroller (the EFM8 series the Aikon SEFM uses). The technical specs list an 8051 CPU, which is 8bit.
I think you’re correct. At least in the case of the DYS XS 20A, the MCU listed on Banggood is the Silabs EFM8BB2 which is 8-bit:
Why can’t we move the ESC processing to the flight controller? Back in the days, ESCs had to have logic because their input was PWM 1-2ms from an analog receiver, but in the multicopter era, all control signals come from an mcu. Putting mcu’s on all four ESCs cost money and makes for larger ESCs. And you have the added complexity of the interface between them, and us multicopter builders sit here on wonder how to get everything to talk to each other and keep in sync. If the mcu on the flight controller either provided PWM to the ESC FETs (or maybe the flight controller could also integrate gate drivers) it would bring complexity and and cost down. You would also know that “ESCs” (FETs…) are updated when the control algorithms had computed a new output value.
The only limitation I see is lack of I/O and hardware PWM. No mcu has (minimum) 12 of these unused. For example the all so popular STM32F103C8 has actually 12 hardware PWM channels and this is a low pin count mcu.
Are littlebee pros on this list ?
No. Littlebee Pro’s run regular BlHeli and use software generated PWM.