About LPD8806 based RGB LED strips

The LPD8806 IC provides a simple way to offload the pulse width modulation (PWM) control of 6 separate LED channels (2 x RGB LED pixels) with 7 bit brightness resolution per channel.  With 21 bits per pixel, that gives us 2,097,152 different possible brightness/colour combinations.

Strips using the LPD8806 IC are available through many sources (e.g. Adafruit).  Most commonly they are sold as 32 LED per meter, but some manufacturers sell them as 36 or 48 LED per meter.  Also note that some manufacturers make strips where fewer LPD8806 ICs are used, so that several LEDs (typically 2 or 3) are combined into the same pixel, which is not suitable here.  Just FYI, the LEDs on these multi LED per pixel strips are wired in series, and thus require a higher voltage to run the strip, typically 12V (the IC requires 3.3 to 5V supply, but the LED’s can run off a separate, higher voltage).

For our purposes, we use the most common 32 LED, 32 pixel, strips, which operate from a nominal 5 volts.  This strip can be easily cut every 2 LEDs, or at approximately 62.5mm intervals, and re-joined again to build a chain – data & clock outputs of one segment going into data and clock inputs of the next segment.  Depending on the strip, power consumption is typically about 50mA per LED when set to bright white on a 5V supply, although some strips we tried used less and were thus not as bright.

There is one* reasonably serious issue with the LPD8806 – the only documentation available is in Chinese, and lacks it lacks the important SPI protocol description.  Thankfully, the wonderful people at Adafruit, and several others around the net, have reverse engineered the protocol and provided good example code.  But here I will give another description of the protocol, based on my own understanding.

The strips basically implement a large shift register, like SPI, but with a small trick to allow use of only 2 signals – data and clock, without a separate reset or latch signal.  Each LPD8806 implements six 7 bit PWM controllers, but six daisy chained 8 bit shift registers (effectively a single 48 bit register).  With a 1 metre length, and 32 LED/m, that gives a total of 32 * 8 * 3, or a 768 bit shift register.

As only 7 bits per colour are used, the most significant bit (MSB), which is sent first, is used as an indicator to signal when the LPD8806 shift registers should latch the data to their PWM controllers.  The MSB of each byte must be kept high while shifting colour data normally, and the daisy chain data input to output will ripple through all 48 bits normally.  The colour values should thus be in the range 0x80 to 0xFF, and for typical strips are sent in Green, Red, Blue order.

But when the MSB is left low, the internal shift registers will be bypassed, and the data output will effectively follow the input.  This means that shifting just three** zero bytes will immediately latch all colour data along the full length of the chain.  It also resets the shift registers ready for a new set of data to be shifted in.

An example of this data shifting will be shown in a future post of implementing fast software SPI.

* Another issue with the LPD8806 is that it is difficult to source as a standalone chip.  We’ve been able to get hold of a couple of thousand to begin testing our custom PCBs, but most people will just want to buy the LED strip with the components already in place.

** There seems to be some disagreement around about how many zero bytes are needed to latch the data, but our experience has been that 3 bytes, or 24 bits, or all zero is sufficient.

*** While here I’ll mention two other features of the LPD8806.  OMODE seems to allow inversion of the PWM output, so when pulled low the PWM will be active high.  PMODE allows setting a parallel output mode, so when pulled low outputs 1&4, 2&5, and 3&6 are paralleled to provide higher driver currents.  These pins seems to have internal pull ups, so can be left unconnected for normal use.

16 thoughts on “About LPD8806 based RGB LED strips

  1. Pingback: Introducing the hardware | Making Light

  2. I know you’re already going down the shift register route, but the NXP (was Philips) PCA9685 gives you 16 channels (or 5 RGBs plus a spare) on an I2C bus, with 6 bits worth of address setting, so you can use a shed load on a single bus, without needing to do any switching.

    From the datasheet:

    “The PCA9685 is an I2C-bus controlled 16-channel LED controller optimized for LCD Red/Green/Blue/Amber (RGBA) color backlighting applications. Each LED output has its own 12-bit resolution (4096 steps) fixed frequency individual PWM controller that operates at a programmable frequency from a typical of 40 Hz to 1000 Hz with a duty cycle that is adjustable from 0 % to 100 % to allow the LED to be set to a specific brightness value. All outputs are set to the same PWM frequency.”

    $2.30 a piece from Element14, on a 250 part price break.

    Just thought you might be interested :-) Using these beasties in my designs.

    • Hi Smiffy,

      Thanks for the comment. I haven’t looked at the PCA9685 specifically, but have evaluated the Texas Instruments TLC59116 for another project. It is very similar, but only 8-bit PWM.

      We began this project with the intention to use off the shelf LED strip, and the LPD8806 is a common chip used on those. We evaluated several strips, and built a number of prototypes, before deciding we probably want to do our own board layouts anyway. There is also a cool RGB LED available with a built in WS2811 IC, but that requires a high speed clockless data stream (NRZ), which isn’t easily handled in Linux, so would probably need a coprocessor.

      While the PCA9685 would halve the number of IC’s needed compared to the LPD8806, they are much more expensive in quantity. I can buy 100 of the LPD8806 at $0.30 ea, but the cheapest I can get PCA9685 is about $1 each when buying 12,000. We are looking at needing something like two hundred thousand of these chips, so price is pretty important.

      Another point is that I2C runs slower than SPI (i.e. shift registers) and adds a lot of overhead in its protocol. I use I2C DAC’s, ADC’s, and GPIO’s all the time in my designs, and they are great when you want to put a bunch of devices connected and don’t need high update rates. Multiple I2C LED controllers also wouldn’t allow us to synchronously update all LED’s perfectly simultaneously, which we really want for our animations.


  3. Does any try the maximum length can Arduino or RaspberryPi can drive

    I have the main problems with the LEDs number

    I need to control 500 pixels maximum with Arduino / RaspberryPi

    when using arduino it out of ram

    when using RPi it too slow

    anyone have a solution about that?

  4. Pingback: Miscellaneous | Annotary

  5. Pingback: LED Updates | Oceanic Scales

  6. I was able to order some LPD8806 directly from gree-leds.com, they were very responsive. Are you still having trouble with sourcing? The nice folks there also said that the product was likely to be in production for a long time.

    • Dean, we’ve actually moved away from the LPD8806 strips now, not that we ever had any problems sourcing them. Instead are using the WS2812 LED’s which have the control chip built right into the LED. The combined data and clock signal does make communication with the LEDs a little more complex, but libraries like FastSPI take care of that for most applications.

    • Hi Carl,
      The LPD8806 doesn’t have the precise timing requirements of the WS2811/2812 so it is much easier to drive with separate clock and data. When running many metres, you do want to make sure you inject power at regular points due to the voltage drop along the cable/strips. You can run quite a lot of LEDs in one string, but if you want fast updates, then you will want to run several strings in parallel (maybe from different controllers). The best library to look at is FastSPI_LED2 (currently still in beta) and runs on Arduino or Teensy.
      See https://code.google.com/p/fastspi/

Add Comment Register

Leave a Reply