I've got a long run of some LPD8806 driver-based LED strips (which use an SPI connection) that I am controlling via a Raspberry Pi. It controls it just great, but when I have the LEDs all off (not powered down completely, just having told the driver chips to clear the LED) a few of the lights will eventually turn on. It's really weird, just a few will turn on to random colors after they've been sitting for several hours. Usually 4 or 5 in a row and often somewhere in the middle of the strip.

What I can't figure out is how they are they are getting these random signals. Could it be something with my connection to the SPI pins on the Raspberry Pi? I have the SPI Data out and Clock pins running through a level converter from Adafruit to bring the signal level from 3.3V up to the 5V of the strips.

I'm more of a software guy, so I'm probably just missing something silly. Do the signal lines need some sort of filtering cap maybe?

Update: I've got 2 rolls, 5 meters each, connected in one long run. I am injecting power at the very beginning of the run and where the second roll connects to the first (otherwise the very last pixels were browning out).

What I've noticed now is that it's only ever pixels at the very beginning of the second roll that are turning on. Not sure why, but maybe this will give a clue to what's happening?

I'm up for trying a cap across the power lines... but have no idea what value to use. The highest rated 10uF cap I have on hand is rated for 100V but it's still tiny. Can't imagine that could handle 10A (since I'd have to wire in one cap for each separate power run).

  • \$\begingroup\$ do you have any decoupling caps for the power? (Also, not SPI technically) \$\endgroup\$ – Passerby Oct 27 '13 at 11:53
  • \$\begingroup\$ I realize it's not REALLY SPI...their datasheet describes it as "SPI-like"... and nope. No caps on the power. Never had this issue before, but I never ran this many. How big of a cap would I even need for 5V @ 20A ? \$\endgroup\$ – Adam Haile Oct 27 '13 at 12:05
  • \$\begingroup\$ The datasheet suggests 10uF, but 20 AMPS? that's 1000 leds (or 333 rgb), are you injecting power at both ends or in the middle or anything? \$\endgroup\$ – Passerby Oct 27 '13 at 17:55
  • \$\begingroup\$ It's 2x 5 meter rolls and a total of 360 5050 LEDs. I'm injection power at the start of each roll (so basically at the start and in the middle). Yeah... don't know enough about caps to know what value to use :( \$\endgroup\$ – Adam Haile Oct 28 '13 at 3:25

Here is my interpretation of what I think is happening: -

The chips used in this product require clocked serial data and each chip has outputs that can feed more chips thus, you can create a large array of LEDs and each LED can be controlled individually. That seems to be the idea but, the general problem with controlling LEDs through an array of shift registers is that the guy writing the code to control the LEDs has to keep tabs on what the state of the LEDs are.

No easy feat and say, because of the size of the array a rogue clock occured, the "controller" (aka MCU) wouldn't necessarily be aware that the "system" is now out of sync. I'm half assuming that the chips are distributed through the product so that LED wiring is made simpler - this can aggrevate the problem if there is interference from some external source - I can envisage random LEDs turning on and maybe this is the problem.

The chip does not appear to be 100% adequately documented and of course there is no guarantee that adequate supply decoupling is used in the produce purchased so it's a bit of a lottery as to what is really happening but, given the "antenna"-like nature of the product and also the lack of adequate grounding throughout the strip of LEDs, external influences could have an effect.

enter image description here

Maybe the problem comes from a local wifi router or someone using a drill nearby; maybe someone using an electric arc welder or maybe just a faulty product.

  • \$\begingroup\$ Hmmm.... See my update. Only happening at the beginning of the second strip in the run. \$\endgroup\$ – Adam Haile Oct 28 '13 at 3:35
  • \$\begingroup\$ I speculate: since the clock and data are regenerated by each chip (per photograph by Andy aka), that it is the connection between the first roll to the second roll that is a cause of failure, and this might be due to either the connection, or electrostatic damage to the first chip on the second roll. Does the problem occur if you swap the rolls? \$\endgroup\$ – James Cameron Oct 28 '13 at 4:14
  • \$\begingroup\$ Maybe try a decoupling capacitor across the power connections at the start of the 2nd run. Also you could connect the power out from the first roll to power in on the second roll. These are just parallel dc levels so it should help too. \$\endgroup\$ – Andy aka Oct 28 '13 at 10:18
  • \$\begingroup\$ Would be hard to swap rolls... they are already installed :( \$\endgroup\$ – Adam Haile Oct 28 '13 at 13:17
  • \$\begingroup\$ I'm not saying that. The power that feeds your 2nd roll might need a decoupler at the point the power wires cone in. You might also try taking the power and ground to the nearest end of the first roll too. This reinforces power to 2nd roll and 1st roll. \$\endgroup\$ – Andy aka Oct 28 '13 at 15:25

I ran into this same problem recently with my LPD8806 strips. It took months to find that my power supply was too close to my Pi. If you are using a switching power supply then it may be causing interference on the SPI bus. Make sure to keep the power supply away from the Raspberry Pi or adding some RF shielding.

  • \$\begingroup\$ Or make sure not to use a very cheap power supply :-) \$\endgroup\$ – m.Alin Jun 2 '14 at 11:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.