DP405.r2B11: Inductive spike on output may damage Q8

[gregdavill]

I'm not sure this is something that actually needs to be actioned, but thought I'd open an issue to get your thoughts, and have it available here on github.
(This is a summary of a twitter thread: https://twitter.com/GregDavill/status/1400034208580390915)

What happened

I was powering a very cheap 25W LED panel with an inline controller, the controller only has ESR ceramic caps on it's voltage input.
The power supply was set to 12V and was supplying the LED panel with ~2A of current.
It was connected to the power supply with alligator clips, these came loose, and the light went off, so I simply re-attached it.
There was a decent, and audible, spark when I reconnected the alligator clip.
The light was back on, and I continued my work.

A minute or two after I noticed a slight burning smell, and another pop. That's when I noticed that the power supply was showing 13V, instead of 12V...

When I disconnected the LEDs the power supply wasn't regulating correctly and outputting the full ~40V.
As a result, not the original fault, the load resistor, R29, in the down-programmer had literally popped.

I went through the circuit to work out why the Q3/Q4 were basically being left on, when diode checking Q8 I noticed it's collector basically shorted to it's emitter. So I ordered a replacement.
I also noticed some residue on R49 so I also replaced it, but that may have been fine.

With these parts replaced the module is working again.
Thanks! The fact that the design is open-source meant I could quickly fix it myself. :)

Why it happened

I'm not 100% sure here, but I suppose that the combination of low ESR capacitors in the LED controller, and inductive cables running to the alligator clips created a >100V spike which simply passed through Q4/Q3, R35/R34 and still had enough energy to damage Q8. The datasheet for Q8 lists it's breakdown voltage at 140V,100uA.

If I'd had OVP enabled R29 likely wouldn't have be damaged. But I'm unsure if Q8 would have been saved, inductive spikes are very rapid.

Potential fix

If this is the cause of the failure, a TVS diode with a 50-100V rating on the input would help absorb energy from inductive spikes before it makes it back to more sensitive components?

Another option is adding some bulk capacitance to the output. I've seen this employed on some other PSU designs. But that may have unintended consequences.

[prasimix]

If this is the cause of the failure, a TVS diode with a 50-100V rating on the input would help absorb energy from inductive spikes before it makes it back to more sensitive components?

The thing is that we have a 51V TVS on the power output (ZD5, see sheet 6/6), the question is still what is really happened. We definitely need to spend some time trying to reproduce this issue.

[gregdavill]

The thing is that we have a 51V TVS on the power output (ZD5, see sheet 6/6), the question is still what is really happened. We definitely need to spend some time trying to reproduce this issue.

Oh! You're right. Then I have no idea how this happened. 😕

[prasimix]

We still cannot reproduce this issue. However, there is some indication that this issue could be related to #108. If that is true then DP (down-programmer) should starts to overheat even when fast list is executing. One can check that and keep eye if DP resistor will starts to overheat i.e. start to smoke. If that happen, then adding X2 cap on any of Mean Well's AC inputs could make a real difference.

[prasimix]

Two additional protection mechanisms have been added for the DCP405 module (#195, #202) in firmware v1.7.

[gregdavill]

Thanks!

[gregdavill]

I'm really not having much luck with this module. 😓
I'll just add this here, because it's on the same module, so might be related to the original issue?
I thought I'd fixed the original fault, but after using this module for over a year at this point the channel stopped working again.

One thing I'd noticed, when it was working, even when the channel was off the CV/CC lights would toggle occasionally, which I thought was odd, because the other module doesn't do that. But it seemed to work when enabled so I just ignored it.

Currently the OVP kicks in every time I attempt to turn the channel on.
If I disable the OVP, the output just remains at ~40.5V.

I opened up the unit, and took the module out, seems like there was a fault with the fuse holder? Maybe a loose contact point. The top contact got hot enough to melt the plastic cover, along with slightly charring the plastic base. The metal is very discolored.

I've not yet gone down the debugging rabbit hole. But have you seen this before in your testing?

Here are some photos:

[prasimix]

No, damaged fuse holder is an indication that HW OVP tripped (as expected), i.e. triac is switched on and max. power is sourced from the power pre-regulator due to fact that post-regulator voltage control loop failed, hence you can measure more the 40 V on the output. You have to check Q8, R49 and Q9 at first place. If R49 even looks as it is undamaged, be sure that its resistance is within tolerance.

[gregdavill]

Thanks for insight into the design. I suspect this end of holder got hot because it wasn't making perfect contact with the fuse, leading to an added resistance, especially considering the other end doesn't have the same damage.

I've removed the fuse, and pinched the wings on each end closer together. It's now holding the fuse much tighter.
I'll try to pick up a replacement soon, since in it's state it's likely not making the best low-resistance connection.

I've replaced Q8, R49 and Q9. Already had parts on hand. It has fixed the OVP issue, and the board seems to be regulating correctly again.

Could a loose fuse connection have caused the original issue a few years ago? Which seems to have happened again, damage to the post-regulator front end. (Ignoring the OVP induced damage, since that seems like a consequence, not a cause)

[prasimix]

I’m not sure, I’d rather say that some unfortunate combination of set output values and connected load led to a problem.

[gregdavill]

Understood.

Unfortunately I don't seem to have any photos when the original fault occurred that show the fuse holder, so it's not easy to check to see if it was a potential issue back there. I notice that the unit does report an OVP error, and disables the channel if I jostle the fuse enough to the point it briefly disconnects. So that is reassuring.