If the ESC has this capability, it allows monitoring and logging of performance data that previously required additional sensors (like power modules and RPM sensors). The detailed data provided by every ESC allows real-time decisions and individual ESC or motor performance tuning and failure analysis.
Note
BLHeli is an ESC firmware, and BLHeli32 is the 3rd generation after BLHeli and BLHeliS. BLHeli32 is written for ESC ‘s that utilize 32-bit MCU (STM32F0 Cortex-M0 at 48MHz), unlike BLHeli and BLHeliS ESC’s that runs on 8-bit processors. BLHeli32 does not work with 8bit Atmel or Silabs ESC’s.
ArduPilot does not currently support the polling of the ESCs for telemetry data via throttle idle messages over the signal line in non DShot protocols.
Connect all ESC’s telemetry wires to a single serial port’s RX pin on the autopilot (above diagram uses Serial5 as an example). ESC telemetry is currently only supported with BLHeli_32 ESCs. A pin or wire for ESC telemetry is pre-soldered on most BLHeli_32 ESCs. If the wire isn’t pre-soldered you will need to solder it yourself. Pinouts for serial ports on The Cube can be found here.
- Quick guide on how to install BLHeliSuite32 for BLHeli32 (BLHeli32)The Download Link for PC changed to https://drive.google.com/drive/folders/1Y1bUMnRRolmMD.
- I noticed that blheli32 required windows-only software after I bought my ESCs but it runs absolutely fine with wine on linux (I saw some guides for mac os as well). Still closed source though:P 2.
Set the following parameters to enable BLHeli_32 telemetry feedback to a autopilot’s serial port:
- SERVO_BLH_AUTO = 1 to enable automatic mapping of multirotor motors for BLHeli_32 pass-through and telemetry support. for most multirotor and quadplane users this will do the right thing. If using BLHeli_32 ESCs on non-multirotor motors with the respective SERVOn_FUNCTION set to 70 (=throttle), 73 (=throttle left) or 74 (=throttle right), you will need to further specify the used outputs as follows:
- SERVO_BLH_MASK : a bitmap used to enable BLHeli_32 pass-through and telemetry support on non-multirotor motors and / or exactly specify which servo outputs you want to enable pass-through and telemetry on (if available in ESC).
- SERVO_BLH_OTYPE : This needs to be set to the protocol being used for the DShot protocol being used on those additional outputs if not the same as the normal copter style motor outputs.
- SERIAL5_PROTOCOL 16 (= ESC telemetry). This assumes serial port 5 is used. Adjust the serial port’s protocol parameter to 16 , for the serial port whose RX input is connected to the ESC(s) telemetry pad. The correlation between serial port numbering and UART physical ports for you autopilot should be documented in its description page linked here.
- SERVO_BLH_TRATE defaults to 10. this enables telemetry at a 10hz update rate from the ESC.
- SERVO_BLH_POLES defaults to 14 which applies to the majority of brushless motors. Adjust as required if you’re using motors with a pole count other than 14 to calculate true motor shaft RPM from ESC’s e-field RPM.
Logging and Reporting¶
The autopilot requests status information from one ESC at a time, cycling between them. This information is logged to the onboard log’s ESCn messages and can be viewed in any ArduPilot compatible log viewer.
- RPM
- Voltage
- Current
- Temperature
- Total Current
The RCOU messages are also written to the onboard logs which hold the requested output level sent to the ESCs expressed as a number from 1000 (meaning stopped) to 2000 (meaning full output).
This data can also be viewed in real-time using a ground station. If using the Mission Planner go to the Flight Data screen’s status tab and look for esc1_rpm.
Note
Sending BLHeli_32 telemetry data to the GCS requires the telemetry connection use MAVLink2. ArduPilot uses MAVLink2 by default on the USB port but if another port is used it may be necessary to set the SERIALx_PROTOCOL parameter to 2 (where “x” is the serial port number used for the telemetry connection).
In addition, some telemetry values can be displayed on the integrated on-board OSD, if your autopilot has one.
By setting a battery monitor instance to BLHeli32 ESC type (for example BATT2_MONITOR = 9), all connected BLHeli32 ESCs with connected telemetry wiring to the configured autopilot serial port, will be aggregated as a single source. The voltages reported will be averaged, the currents totaled, and the consumed current accumulated.
Newer versions of BLHeli_32 (32.7) and BLHeli_S (16.73) support returning motor RPM values over the Dshot signal line. Supporting bi-directional Dshot requires exclusive use of one or more DMA channels and thus not all versions of ArduPilot support it. Versions that support bi-directional Dshot natively are BeastH7, BeastF7 and KakuteF7Mini, other firmware versions end in “-bdshot” to indicate support for bi-directional Dshot.
Setup¶
First ensure that you have an appropriate version of BLHeli_32 or BLHeli_S installed on your ESCs. The majority of ESCs do not come pre-installed with these versions. The official 32.7 version of BLHeli_32 supports bi-directional Dshot. Official versions of BLHeli_S do not support bi-directional Dshot, you will need to either buy a version from JESC or use the unofficial version from JazzMaverick. If you try and enable bi-directional Dshot with the wrong firmware version then unpredictable motor operation can occur.
Set the following parameters to enable BLHeli_32 and BLHeli_S bi-directional Dshot:
- SERVO_BLH_AUTO = 1 to enable automatic mapping of multirotor motors for BLHeli_32 pass-through and telemetry support. for most multirotor and quadplane users this will do the right thing. If using BLHeli_32 ESCs on non-multirotor motors with the respective SERVOn_FUNCTION set to 70 (=throttle), 73 (=throttle left) or 74 (=throttle right), you will need to further specify the used outputs as follows:
- SERVO_BLH_MASK : a bitmap used to enable BLHeli_32 pass-through and telemetry support on non-multirotor motors and / or exactly specify which servo outputs you want to enable pass-through and telemetry on (if available in ESC).
- SERVO_BLH_BDMASK : a bitmap used to enable BLHeli_32 or BLHeli_S bi-directional Dshot support. On flight controllers without IOMCU this would normally be set to 15 to indicate four active channels. On flight controllers with an IOMCU this can be set to 3840 to indicate four active AUX channels (bi-directional Dshot will only work on the AUX outputs). The BeastH7 only supports channels 1 and 4 for bi-directional dshot (mask set to 9).
- SERVO_BLH_OTYPE : This needs to be set to the protocol being used for the DShot protocol being used on those additional outputs if not the same as the normal copter style motor outputs.
- SERVO_BLH_POLES defaults to 14 which applies to the majority of brushless motors. Adjust as required if you’re using motors with a pole count other than 14 to calculate true motor shaft RPM from ESC’s e-field RPM (small motors might have 12 poles).
We have official BLHeli_32 confirmation from BLHeli Developers. Let’s find out what it is about, what advantages it brings, and what changes there are moving forward.
BLHeli is an ESC firmware, and BLHeli_32 is the 3rd generation after BLHeli and BLHeli_S.
BLHeli_32 is written for ESC‘s that utilize 32-bit MCU (STM32F0 Cortex-M0 at 48MHz), unlike BLHeli and BLHeli_S ESC’s that runs on 8-bit processors. BLHeli_32 does not work with 8bit Atmel or Silabs ESC’s.
Check out this article to learn about ESC firmware.
The 32bit processor on BLHeli_32 ESC has faster clock speed than the 8bit processors in BLHeli_S ESC’s. But BLHeli_S has already set the bar high for performance, it would be interesting to see how much better BLHeli_32 is than BLHeli_S.
With the increased in processing power, faster input signals with lower latency and higher update rate would be possible in BLHeli_32, such as Dshot1200 or even faster protocols! (Read about DShot)
The most exciting news about the 32-bit platform is the possibility of future functionality and features that simply wasn’t possible on 8bit ESC’s, including
- programmable PWM frequency of up to 48KHz
- Auto-timing for higher efficiency and realiability
- Current limiting (with built-in current sensor on ESC)
- Adjustable “Brake on Stop” force
- Improve direction change in Bidirectional mode
- ESC Telemetry
- Configuring from FC using DShot commands
48KHz PWM frequency and Auto motor timing have been reported to improve flight performance noticeably.
![Blheli_32 Blheli_32](https://rotorbuilds.com/image.php?w=3000&url=/pictures/f_5579_XBukaBNHY9mz6jYT2QzTJ2vMP.jpg)
Blheli_32 Dshot
Note that these features are just ideas from the developer (aka sskaug) at the moment and haven’t all been implemented yet. Some of these sound familiar from the KISS 24A ESC’s. Anyway we should discover more about the new possibility as development continues.
The previous BLHeli and BLHeli_S are open source, however the developers have decided to close source the new 32bit firmware. Their names might maintain the same prefix, but we were told BLHeli_32 has been created from scratch. (BLHeli and _S are both Assembly based while BLHeli_32 is C based) ESC manufacturers will have to pay BLHeli developers a licence fee directly to use their 32bit firmware, therefore expect some increase in ESC price.
When asked why the project has become close-source, sskaug replied:
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.
Blheli_32 Suite
Hopefully BLHeli_32 will also serve the community well, and bring ESC performance and the hobby as a whole even some more steps forward.
One thing remains the same is using BLHeliSuite for flashing and configuring ESC’s, which is known to be incompatible with Mac and Linux but only Windows. BLHeli Configurator Chrome App was created to tackle this issue by third party developer Andrey Mironov,. But we found out that it won’t support BLHeli_32 since it’s close-source.
Here is how to connect to BLHeliSuite32 via FC passthrough.
BLHeliSuite will require an internet connection in order to flash/update firmware and configure settings, that probably means you can’t do it at the field easily. The serial number of the ESC has to be validated at the manufacturers, this is to prevent clones or illegal use of their firmware.
Here is a full list of ESC’s for mini quad, you can look up which ones support BLHeli_32 firmware.
I compiled the specification of all ESC’s for mini quad in this spreadsheet so you can compare them more closely. |
In order to run BLHeli_32 firmware, the ESC must be designed specifically for the firmware. That means 32bit ESC’s that already existed before the firmware was released might not work with BLHeli_32. Also note that some 32-bit ESC’s might only run their own factory firmware, so make sure you check before purchasing.