Burned HK_UBEC_20A when using damping light mode about blheli HOT 16 CLOSED

Normally FETs burn due to the low and high side being turned on simultaneously, and this is a risk that must be carefully avoided when running damped light. So, I ran this ESC on 4S, using a 2204/2300kv and a 2207/2100kv motor with 6045 prop. Both ran damped light very well (12.2 code). Current draw was around the expected 20A at full throttle.

Maybe it's your motor that doesn't run well on damped light. I can look at some other motors.
Maybe you can run other motors too?
Or maybe the ESC design has changed. Can you check against the "supported ESCs" pic?

from blheli.

Maybe it's your motor that doesn't run well on damped light. I can look at some other motors. Maybe you can run other motors too?

Interesting, your motor has much higher kv and possibly even electrical kv. I would think that ESC would have more problems with high kv motors.

Do you have any more info on what motor parameter would affect damped light performance?

Or maybe the ESC design has changed. Can you check against the "supported ESCs" pic?
The design hasn't changed visually, but that doesn't mean that some resistor or capacitor value hasn't changed.

I will do a test with different motors and report back.

from blheli.

One question, when damped light mode is enable, should the RPM governor be enabled also? Because I did not turn it on.

from blheli.

It can or can not. They are independent.

from blheli.

@sskaug should I try to remove befm capacitors?

from blheli.

My ESC has CEP85A3 (exact markings on the element: 58A3 3502G) mosfets on both rails, the data-sheet shows:

The ON switching time is much shorter than OFF time. But you have the same delay in https://github.com/bitdump/BLHeli/blob/master/Atmel/HK_UBEC_20A.inc#L55 configuration:

.EQU NFETON_DELAY = 5 ; Wait delay from pfets off to nfets on
.EQU PFETON_DELAY = 5 ; Wait delay from nfets off to pfets on

Maybe this is causing the situation where both positive and negative rail FETs are on at the same time?

from blheli.

I have found an issue in the current code, where during start in damped light mode both fets are on for some microseconds. I have never seen any damage from this (it is for very short time), but it may be related to what you experience.
Running from a current limited lab supply can produce strange results, I think. Also running without a prop is not representative of real behavior. You can run with a fuse, or with a light bulb.

The on and off times in the datasheet are not representative. The delays in the driver circuits are much longer. And the "XFETON_DELAY" values are fine.

from blheli.

I have my ESC modified with additional 1000uF capacitor on the power supply rail. This could cause much higher current spike when bot fets are on at the same time.

Any plan to fix this issue? I haven't done any more tests, because I don't have any spare ESC left. My remaining four ESC use Blheli 12.2 with Damped light turned off and perform flawlessly.

from blheli.

Great to hear that they run well wo damped light, and sorry for the loss. And thanks for the info on the 1000uF cap, that may have caused a lot more energy in these spikes than normal and caused the ESC to fry.

The bug only exists in the Atmel code (not SiLabs), and a fix is in place. We are just working on a few other improvements of the code before we release a rev13. Hopefully not in too many days.

from blheli.

Don't worry about my ESC loss (it is only 7 eur and now I have four spare fets!). Thanks for your efforts and keep up the good work.

from blheli.

@sskaug I want to ask you a couple of questions regarding the internals of blheli.

When ESC is working without RPM governor without Damped light, the PWM pulse duty is proportional to input PPM signal. This (my) assumption is probably correct.

Now we turn on Damped light. Now ESC must somehow know when to apply brake and when to apply power. How does it determine what to do, without some sort of RPM governor. From my understanding it must compare current motor RPM with desired RPM (commanded by input PPM signal). But how is input signal mapped to the RPM values. The ESC surely can not know which RPM value is equivalent to 100% PPM signal. That value depends on motor and voltage.

Now we turn on both RPM governor and Damped light. This makes more sense to me since the governor now produces the decision to accelerate or brake the motor. But again how is the mapping from input PPM to motor RPM done. How does the ESC know which is the target RPM value for full throttle?

from blheli.

No1 is yes.
No2 is the same, just that the part of the output pwm cycle that you do not apply power, you brake. RPM is not controlled, it will be whatever the motor gives at that power level.
Now with governor on, the motor rpm is controlled by the input signal. and the ESC controls the power to the motor to whatever is required to achieve that rpm (if it can be achieved). There is an internal calculation that is done in the ESC, to find the rpm that corresponds to the input signal.

from blheli.

Thanks for answers, it is now more clear. I will order some more ESCs shortly and do some tests and report back.

from blheli.

Rev13.0 is now posted, where this issue is fixed.

from blheli.

Good news. Got a new batch of HK F-20A ESCs and tested with Blheli 13.0:

• Battery 4S
• motor Turnigy Multistar 2216-800Kv 14Pole
• prop 10x5
• Damped light ON
• other blheli settings default

This is almost the same setup as in original post. Works very good, no sync issues. I am starting to believe that my burned ESC had some sort of hardware problem. Maybe there was also a bug in blheli 12.1. Whatever it works now, thanks!

from blheli.

Thanks for the info. Good to hear!

from blheli.