+Fr Robert Ballecer, SJ I just wanted to give you a warning about that LED Strip Driver that yo...

[G+_Jeff Gros]

+Fr. Robert Ballecer, SJ I just wanted to give you a warning about that LED Strip Driver that you showed off on Know How 361. Last night I had mishap concerning this LED driver which could have turned out much worse than it did. Don't worry. It was a close call but nothing caught fire.

 

You showed off this product here from IDS Home: https://www.amazon.com/Full-Color-Driver-Control-Module-Arduino/dp/B073P6X3PQ/ref=pd_sbs_147_2?_encoding=UTF8&pd_rd_i=B073P6X3PQ&pd_rd_r=JC74EBQ02P5GQ8NYTENQ&pd_rd_w=6uzO1&pd_rd_wg=htDvQ&psc=1&refRID=JC74EBQ02P5GQ8NYTENQ

 

I'm doing a project that queries my raspberry pi octoprint distro to get the print status. I would then light the LEDs in my 3D printer enclosure to show this status (red for error, green for done, etc). I saw the LED Driver on the show and thought it would do just what I needed.

 

Eventually I'll integrate my work into octoprint as a plugin, however, I'm not there quite yet. I'll post on github and share with the group when I'm a bit further.

 

I found arduino code to drive the chip and adapted it to python code to run on a raspberry pi. Yesterday I tested the code, left the LEDs in the off state on my desk and then left for work.

 

When I came back home from work, I looked into my house from outside and saw a bright white light coming from my office! I wonder what the neighbors thought!

 

Somehow the LEDs had turned on full while I was away! Now, I didn't have much time to probe or troubleshoot things since my desk was scorching hot, however I have a theory that I think is pretty likely.

 

This board has a P9813 LED Driver chip on it. The chip has three outputs which connect to 3 N-FETs which allow 12V to the LEDs. These three outputs have pullups to VDD (5V) to control the gates of the N-FETs. If the chip pulls the lines low to control brightness.

 

The outputs are controlled via SPI. The communication has checksum bits. This is an unlikely avenue for turning on the LEDs accidentally.

 

But what happens if the P9813 doesn't drive the pins? Well I found out! Which I find hilarious since Patrick offhandedly mentioned fire risk on the show! ;)

 

My theory is that I suffered a brownout during the day which caused the P9813 to go into reset but not fully release from reset when power returned.

 

In this state it would not drive the outputs. If the P9813 doesn't drive the outputs, then they pull up, which turns the N-FETs on full (yielding full white LEDs).

 

The LED driver board was powered by the 5V on the raspberry pi. The LED Driver board has no regulation and not much for bulk storage at the P9813. When the brownout occurred, the raspberry pi didn't share any power that remained. The raspberry pi was still sitting patently at a prompt I left it at and was fully responsive when I came home.

 

In my opinion I don't think the P9813 should be used without a reset circuit. It's just dangerous without it.

 

So what lessons did I learn from this?

 

1. Don't leave things that (could) generate heat plugged in when I leave the house! Especially not near flammable things!

 

2. Don't buy/use electronics unless I look at the schematic beforehand!

 

The good news is that these LEDs will be going in my printer enclosure, which is acrylic. Versus my much more flammable wood desk.

 

Keep up the good work Padre. I'll miss you when you're gone! :)

https://www.amazon.com/Full-Color-Driver-Control-Module-Arduino/dp/B073P6X3PQ/ref=pd_sbs_147_2?_encoding=UTF8&pd_rd_i=B073P6X3PQ&pd_rd_r=JC74EBQ02P5GQ8NYTENQ&pd_rd_w=6uzO1&pd_rd_wg=htDvQ&psc=1&refRID=JC74EBQ02P5GQ8NYTENQ

[G+_Jeff Gros]

Fr. Robert Ballecer, SJ

 

Added mention because I'm a dummy that doesn't know how to use google plus.

[G+_Jim Hofmann]

Still not sure what got hot. The driver board, the LEDs or the RPi? It sounds like, other then having your code startup with the RPi, the circuit did work. Or in this "brownout" condition did the driver board get warm enough to toast? It "should" be able to handle 72 watts. If it did toast than possible there is a feedback to the RPi? In any case I'd add a fuse rated for the amps expected.

 

Good lesson though, if it's going to be more than bench testing (playing) add fuses and safeties as needed and test, test, test.

 

Thanks.

[G+_Jeff Gros]

The LEDs got hot. The driver board doesn't do much power wise. It just controls some gates. All the current is going through the LEDs.

[G+_Telford Dorr]

Uh, if you were driving a light strip, the light strip should have current regulation in it to limit LED current. Thus, continually driving the strip at full voltage should have done nothing more than fully light the LEDs. Assuming the LEDs are mounted such that they have some air circulation, there should be NO fire danger. You just wasted some energy.

 

As to the driver board, your software should periodically refresh the board, even if there are no brightness changes (say, maybe every 1/2 second, for example). That way, if there is a glitch, and all the LEDs go full bright, the periodic refresh will reset them back to the correct state. Rule of thumb: never depend on the memory capabilities of SPI things like driver boards, etc.

 

As a secondary backup, if your PI has a watchdog timer (I'm not a Pi user [yet], so I don't know - I know that the Arduino does), you should program it to command the driver board to full off mode. That way, if the PI gets glitched, the watchdog will time out and command the LEDs to turn off.

 

Just a thought...

[G+_Jeff Gros]

Jim Hofmann Just to be clear, the problem isn't that the board or LEDs couldn't handle 72 watts. The problem is that if the driver chip gets confused, the circuit defaults on.

[G+_Jeff Gros]

Telford Dorr The LED strip has dumb passives (for reference its pretty much the same tricolor strips from the show). If you feed it current it will sink them. All the control is from the driver chip.

 

You are correct that if the LEDs are spread out they should cool. In my case it was coiled on my desk. While the desk was uncomfortably warm to the touch afterwards, there are no scorch marks on the desk, so I don't think I was too close to combustion.

 

Although I don't know conclusively since I was too frantic to troubleshoot, my assumption based on what I observed is that the problem is probably hardware not software.

 

If the P9813 chip gets confused (brownout or otherwise) sending it the code through SPI over and over won't fix it. My software will be doing this anyways just because its easier to code, but it doesn't solve the base problem.

[G+_Jim Hofmann]

HMMmmm? I wouldn't think the LEDs should get hot either. I've wired them directly to +12vdc. Hot LEDs is usually an indication of overvoltage. 5 volt led on a 12 volt supply. Although they usually they become the fuse when they are that far off. I'd check that the +12 is still 12vdc. I've seen regulator after a surge put out <12, usually the unregulated DC. Another is a weird path with the RPi 5vdc making +17vdc. Not sure how that would happen but you might add some diode separation. Definitely odd.

[G+_Jim Hofmann]

OK, we're typing at the same time. Nevermind. :)

[G+_Telford Dorr]

You said: "my assumption based on what I observed is that the problem is probably hardware not software. If the P9813 chip gets confused (brownout or otherwise) sending it the code through SPI over and over won't fix it. My software will be doing this anyways just because its easier to code, but it doesn't solve the base problem."

 

I would think that, unless the voltage remains so low that either the PI or the driver board can't function properly, once the +5 supply recovers, a software refresh should fix it.

 

Otherwise, you could put a big p-channel mosfet in series with the 12 volt supply and drive it with a low voltage detection circuit such that if the +5 supply fell below some critical value (say, 4.5 volts), then the 12 volt supply to the driver board is cut off. Maybe a couple of resistors biasing a LM431 regulator from the +5 volt supply arranged so that anything above the critical voltage activates the LM431, which in turn pulls the gate of the mosfet and its pull-up resistor to ground, turning on power to the LED driver?

[G+_Jeff Gros]

Just for fun, I reproduced the issue with a bench supply. No raspberry pi attached. No code running. Just the LED driver and the LED Strip.

 

Apply 5V at VDD. Apply 12V for LEDs. Turn down the 5V power rail to about 1.5 to 2.5V and then slowly bring it back up. Around this range the LEDs start to flash. You've got to play with it a bit, but the LEDs can turn on full and stay on.

 

I write firmware all day, and this is a common problem for micros, so this was no surprise to me. Not only do you have to worry about brownout but also slow power rise (think solar panels).

 

I've found that typically with micros if you get it to latch up, it will stay in that non-responsive state until you fully discharge it enough so that reset is asserted. But with this P9813 driver chip? Who knows? Maybe you just need to talk to it again? More testing is required...

 

Honestly I'm not sure I'm going to worry about it. I just wanted to point it out as a potential issue.

 

To fix it completely I would want a supply voltage supervisor, but that seems like a lot of work for something I'm just going to hang in my print enclosure.

 

I don't know. I guess it depends on if my Prusa I3 MK3 upgrade ships soon. Once it arrives, everything else gets to wait! :)

[G+_Jeff Gros]

Did another test. Got it into the fault state again with no raspberry pi attached. Then hooked up the raspberry pi and attempted to fix via SPI command. Sending a command did appear to fix the issue and force the P9813 to drive the outputs again. It's unclear how reliable this method is but its probably good enough for most use cases.

[G+_Jeff Gros]

An update. I've been leaving the LED driver on my desk and checking it every once in a while to see if the LEDs spontaneously turned on again.

 

Test setup is the following. LED board powered from 5V supply and 12V LED supply unplugged (except when I plug it in briefly to see if the LEDs turned on by themselves). Clock and data are hooked to raspberry pi (through level translator to get 3.3V to 5V).

 

I found that if I left my script to write the LEDs running (would only write LEDs once, and wait for more user input), the LEDs never turned on by themselves.

 

I found that if I terminated the script, the LEDs would eventually turn on by themselves.

 

So, while I was correct that brownout is an issue, it wasn't my base problem.

 

The issue is that when the script terminates, it "cleans up" the GPIOs, which return them to inputs. I can actually see them float with my oscilloscope.

 

The solution is to tie pullups to clock and data so that when the raspberry pi isn't running, they don't flap around. This wouldn't be an issue with arduino normally since the arduino would typically continuously drive the pins in most applications.

 

I was so sure that this sort of problem was very unlikely because there is a "checksum", but another look at the datasheet clued me in to just how easy it is to fool. Two high bits, followed by a burst of low bits, followed by all high bits gets you LEDs on full.

 

raspberry pi + P9813 + pullups = success

 

Mystery solved! :)

[G+_Telford Dorr]

Driver board input drivers going tri-state; random noise now occurs on said inputs; lights go crazy. Explanation makes sense - I like it. Good work.

[G+_Jim Hofmann]

Interesting. Padre always says to add pullup/down resistors. I've always used the PULLUP parm. If the board dies or gets confused, the outputs could (probably will, Murphy's Law :) float to an unknown state. Thanks.