BLHeli_32 is the new 3rd generation of BLHeli containing software and firmware which allows new and exciting features for ESCs improving on its predecessor BLHeli_S.
If you are not familiar with ESCs, they essentially contain a small microprocessor that runs software and are built to a specific hardware design. The software and hardware have an intertwined relationship and interact closely with each other making it essential that they are compatible with one another. Although it’s sole functionality is to run your ESC, we will discuss how the BLHeli_32 does much more than that.
In the past, if you had a BLHeli ESC, you were required to have an oscillator. When BLHeli_S was released, the company took a big step forward with a specific reference design for the ESC. They had to have several things including gate drivers and dedicated hardware PWM drivers which ultimately make ESCs run better. This explains why many (though not all) had personal preference for the KISS ESC as it was felt that it ran better than BLHeli or Simon K ESC’s. It came down to the fact that KISS had the hardware that the other guy’s didn’t. The addition of these new features created an improved experience as all BLHeli ESC’s were then required to have. It is thought that doing this allowed BLHeli_S to close the gap and allow these ESCs to perform comparably to competitors ESCs in terms of raw performance.
The big thing that BLHeli_32 does is specify that it will run on 32 bit microprocessors. Although 32 bit doesn’t necessarily mean that it will be better or faster, it simply means that it will have longer instruction lengths. The 32 bit processors that are used in BLHeli_32 ESCs deliver more processing performance. DShot 150, 300 and 600 (which use shorter and shorter pulse lengths respectively) allow instructions to pass from the Flight Controller, to the ESC and ultimately the motor in a shorter amount of time. DShot 600 has very short pulse widths and can run up to 32 kilohertz but most available ESCs can't support it.
Now with BLHeli_32, ESCs can run DShot 600 at up to 32 kilohertz and even Dshot 1200. On paper, DShot 1200 performs at twice the bit-rate of DShot 600, but how much does this really help? There is much debate as to whether any of this really matters and a great majority of pilots feel that minimizing the end to end latency between the PID loop and the motor is key to good performance. Perhaps there is something to be said to this point.
The inability of today’s common ESCs to run DShot at 32 kilohertz is one of the reasons why numerous racers say that they prefer Multishot still. Multishot is a much simpler protocol. It has its flaws but one of the things it can do, even on most of today’s ESCs, is it can run at the full 32 kilohertz which allows more frequent updates with less latency. BLHeli_32 now lets us use faster motor protocols with less latency. While this feature may not be the most important thing that BLHeli_32 brings to the table, the big advantage of DShot is the ability to send commands to the ESC. Dshot, short for "digital shot" is a digital protocol which means that you can seamlessly send commands to the ESC. With analog protocols (Oneshot / Multshot), there is no way to give commands and everything that the flight controller sends to the ESC is interpreted as a motor signal. There is no way to relay that what you are requesting isn’t a motor signal.
So this tells us that Digital is the way to go, with both DShot 600 and 1200 providing an advantage running on BLHeli_32.
Another advantage of the faster processor is that it opens the door to all kinds of new features such as current limiting in the ESC. This is great for scenarios such as when you get a voltage or current spike, hit a branch and fry your ESC or your prop is jammed and the motors are spinning but you haven’t dropped the throttle (potential fire!). Having current-limiting built into ESCs will detect if the voltage or current is getting to high with a built-in sensor. This is something that can be added to the BLHeli_32 because the processor cycle is free to accomplish this job (the processes that are used in BLHeli_S are just not fast enough).
Another feature that will be added in is telemetry. While we already have telemetry between the flight controller, receiver and transmitter, we will also gain telemetry to report the current being used and the RPM on the motor. This means that you don’t need a current sensor to get current telemetry from your copter because the vast majority of the current you are pulling is typically from your motor. If can get the current from the ESCs, you are getting a more accurate current reading and you don’t need a separate current sensor elsewhere. The ability to get RPM telemetry from a tuning perspective and know what RPMs are doing in flight is very exciting.
One of the most controversial pieces to the release of BLHeli_32 is that it is closed source. If there’s anything to object to, it’s a company taking an open sourced project to a closed sourced project. The developers of BLHeli took a GPL project and transitioned it into closed source, completely rewriting the whole project in an entirely different programming language (no small feat).
BLHeli has had numerous people ask them what the reasoning was for this change. Essentially they have responded, explaining it was originally written in Assembly and that there was a lack of people contributing and very few understood the code but BLHeli themselves. When they released the code for BLHeli_S, there was a lot of hardware out there (open source) and numerous Chinese manufacturers also developed hardware leaving the developers to offer client support for the hardware. Offering this additional support for the code drained resources and in the end, only the hardware companies were seeing profit. While not all agree with BLHeli’s stance, the motive behind the switch to a closed source product cannot be denied.
What this means is that any manufacturer who wants to release BLHeli_32 ESCs will have to pay a licensing fee. The way it works is that the manufacturer registers the serial number of the ESC at the time that they manufacture the product, the customer receives the ESC and when they go to flash the ESC to upgrade or even downgrade the code, BLHeli will connect to the internet and will look up the serial number and verify that you have a valid licensed ESC.
The goal is to make this all transparent from the user’s perspective but one difference will be that you must be connected to the internet to run BLHeli_32 Suite so that it can look up the ESC for verification. If you could see past GPL and the open source aspect, this may be part that annoys you the most. If you are out at the field and you want to flash or configure your ESCs, finding an internet connection may not be practical.
With all these restrictions, we can expect to see 3rd party ESC's on the market claiming 32bit and DShot1200 support without the use of BLHeli, such as the Racerstar Racer33 ESCs. This is an interesting move for Racerstar as they also have a ligitimate BLHeli_32 ESC on the market, the TATTO 35A. It will be interesting to see where manufacturers go with this moving forward.
The first BLHeli_32 ESC's that were available for purchase (called the “Wraith") are from the company Airbot, the same guys who designed the Omnibus series of boards. They released the Wraith32 35A and the Wraith32 Plus 50A back in April 2017. Since then, lots of manufacturers have jumped in and released BLHeli_32 ESC's, including Lumenier, X-Racer, Favourite, iPeaka, Racerstar and DYS. Its good to note that both the iPeaka and Lumenier's are rebranded from the Wraith32.
For a full list of BLHeli_32 ESC's, we have added them all to our Product Database so check them out! For convenience, they are also linked below.
If you decide to venture into these new ESC's, the following resources will be helpful.
Already running BLHeli_32 ESC's with DShot1200? What you do think of them? Let us know in the comments section!
Last updated on June 25, 2017