This article repeats some earlier tests on two competitive ESC firmwares for sensorless brushless DC motors.

The motor chosen for the tests, a 4822-690KV, is of a type that is very popular; a flat radial flux outrunner with high pole count. These are marketed as more suitable to multi-rotors that the barrel shaped motors developed for planes, but the claims are questionable, these motors are often at higher risk of sync loss due than the barrel shaped motors and used feature regularly in forum postings of de-sync problems.

The article Demagnetisation in a sensorless brushless DC drive givese a broad overview of demagnetisation in a sensorless brushless DC drives that depend on Zero Crossing (ZC) detection to synchronise the next commutation phase.

A Demagnetisation Risk Index for a sensorless brushless DC drive gives a quantitative measure that can be used to indicate high risk drives. In my own testing experience, motors unlikely to exhibit sync loss have DRI well less than 5, and those well over 5 are problem motors. High pole count increases DRI, and this is a 22 pole motor, high when compared to 11 pole barrel shaped motors.

DRI on 4S is 5.1, on 3S is 3.8.

On 3S sync loss could be excited with a hand servo tester using BLHeli, it was not observed with SimonK. Previous testing has shown this motor very prone to sync loss on 4S with either ESC and I dismiss it as impractical.

Above is a logged test run of SimonK (~2017) on 3s using script driven by asrg.

Above is a logged test run of BLHeli-16.7.14.9.0.3 (the latest) with default settings on 3s using script driven by asrg.

Importantly they both use default settings including Complementary PWM (though BLHeli calls it something else).

Superficially, they might look nearly identical, but there are some key differences:

• they are both stable, there is no significant sign of desync;
• BLHeli uses more current at all throttle settings (so reduced battery endurance); and
• BLHeli is less responsive to throttle, it is slower to accelerate, and even slower to decelerate (possibly a measure to avoid de-sync).

Lots of claims have been made of the superiority of the 48MHz Silabs based ESC used for the BLHeli test over the 16MHz AVR MCU used for the SimonK test… but it does not result in superior performance, rather the BLHeli ESC isn’t quite as good.

Overall, I would be happy with BLHeli, though it is slightly poorer than the old SimonK (tgy) firmware. BLHeli was taken up by the community, even when it had significant de-sync problems, and I can only guess that users liked the GUI and drives system performance was a lesser priority.

I have not tried the newer closed source BLHeli_32, and doubt that I will. The BLHeli pitch that a more powerful 32bit MCU will result in better performance is questioned by the above comparison of 8bit MCUs… and if it is the GUI one desires, it is already there in BLHeli_S.