Specs for LDP8806 RGBLED strip?

[gduprey]

Howdy,

Read somewhere that you don't have a datasheet for the LDP8806 controller in the new digital RGBLED strips. Is there anyway to post a summary of the protocol details you folks determined through your observations?

While I understand the basics from looking over the code sample, there are a few areas that are unclear to me. In particular:

* Is the data/bytes that is being sent in the latch logic the # of LEDs are represented as a bit/clock count or just some number of bytes that are needed to do a latch?

* What is the significance of the ((x + 63) / 64) * 3 equation? The previous question may illuminate this one.

* I see in the code that when changing the number of LEDs, the latch is written then -- is it necessary to send the latch to inform the number of LEDs before sending colors? If not, what is the purpose of writing the latch after the # of LEDs is changed?

* Is the strip at all aware of the number of LEDs you are driving or is it a simple serial line passing along the bit stream until a latch comes?

I'm writing some PIC code for a "smart" driver for the strips. The driver is written in assembler to be able to handle fast updates and while the code samples can sort of help, I'm left with a number of questions that get murky answers which makes coding a driver problematic.

I appreciate any help/details with addressing these strips. I've only got a little of it working and it's already so much better than the crappy PWM I had to do for the previous HL1606 strips!

Thanks,

Gerry

[pounce]

Gerry,

Have you looked at the FastSpi library?

http://code.google.com/p/fastspi/

If a chip hasn't been latched and data has passed through it then it will just keep passing data to the next chip. If you send a latch then this tells the chip to accept the first 3 bytes and then just keep passing data. In other words if you don't latch the unknown state of a chip you can't write to it and be sure of what you will get.

The chips have no idea how many other chips there are downstream. Just shift data.

[gduprey]

Howdy!

Thanks for the link -- I'm looking at the code now.

You say that unless it's latched, it'll just keep passing data. So if, for example, I had a 10 LED strip, shift out 30 bytes of G/R/B data, then send 3 bytes of 0x00? Or send 3 bytes of G/R/B data and then 3 0x00 latch bytes, repeating that 10 times?

Thanks!

Gerry

[pounce]

Gerry,

This thread is interesting:

viewtopic.php?f=47&t=22982&p=123319&hilit=latch#p123319

[pburgess]

The initial latch (before any data) is done because the LED driver chips will power up in an unknown state; this makes sure they're uniformly ready to receive data.

The format of the LED data always has at least one bit set, even if "off." The driver chips can then easily spot the latch condition as a number of zeros.

The latch is three zeros (for up to 64 LEDs), but longer strands require a longer latch sequence. 65-128 LEDs = 6 zeros, 129-192 = 9 zeros, and so forth.

[pounce]

The latch is three zeros (for up to 64 LEDs), but longer strands require a longer latch sequence. 65-128 LEDs = 6 zeros, 129-192 = 9 zeros, and so forth.

That's interesting. Do you get this from trial and error? Curious to really know the technical reason for this behavior. Seems a little strange.

[gduprey]

Hmmm -- I've been looking over multiple code libraries. I've seen implementations that use 3-9 zero bytes for a latch and others that send 3*n zeros (where n is the number of LEDs). I'm assuming both work.

However, for the 3-9 zero bytes, how does that get all the way to the end of the chain?

When sending LED data, you have to clock out n*3 bytes (n=# LEDs) in order to reach the last LED. If you only clocked out 3 bytes of zero for a latch, wouldn't that data/latch stop at the first LED?

If the LED responds to seeing three zeros as a "latch" operation, it seems more likely that you'd have to send out a set of 3 zeros for each LED, unless once a unit receives 3 zeros, it auto-broadcasts/sends them along to the next as a special case?

Gerry

[pounce]

The colors are 7 bit. As noted each byte to set color will never be zero. This is how it knows when it gets zeros that it's a latch.

[gduprey]

Thanks and I'm good with the 7 bit color and the needing to set the high bit.

I guess I didn't phrase my last post correctly, so I'll try again.

Given a strip of 10 LEDs, I know that I will need to send 30 bytes of color data out. While I'm clocking this data out, each LDP8806 is passing the data on to it's next neighbor until, at the end, the first data I sent arrives at the 10th LED.

All that makes sense (I've done more than a fair amount of SPI programming and that's how it always works, so no questions on that).

The question is on the "soft" latch. If I latch all 10 LEDS by sending only 3 zeros, I've only "addressed"/reached the first LDP8806 chip with 3 bytes. How does the "latch" command then make it down to the remaining 9 LEDs?

As I've experienced SPI in the past, I would have expected that if I had 10 LEDs and a LDP8806 responded to three 0s by latching, then I'd need to send 30 zeros to latch all the LEDs/LDP8806s. If this isn't the case (and as I mentioned in the earlier post, looking at the two main code libraries I see, it's done both ways --3 zeros and 3*n zeros), then does a triple zero cause a special case where the first LDP8806 replicates the latch command down the line with no assistance from the controller?

Hope thats better stated

Gerry

[gduprey]

This is really an odd SPI chip (unusual is probably a better word). While I saw the code in the various libraries, I didn't believe that you actually address the chain backwards of normal SPI operation. While with most SPI based, daisy-chained devices, if you have a string of X items, you send the data for X out first, then X-1, X-2, X-3, etc until the last thing you send is for the first device on the chain.

I'm finding that these chips must have a "smart" mode where they absorb the first 3 color bytes and do not echo them. When the next set of bytes come out, then are passed along and the next unit does the same. etc, etc. The result is that the first set of bytes truly controls the first LED.

While this is already obvious to the fine folks who have created the libraries out there, it is well, different. In fact, as much as I didn't like the HL1606, it did act like a normal SPI device (in that the first data sent was "pushed" along til the end, meaning you sent the last LEDs data out first, then the second to last, etc, etc).

Also, monitoring the datalines, I am seeing some sort of "automatic" activity on the lines after the first chip received the 3-zeros latch command. So again, this chip is smarter than most SPI devices and is taking a single command and replicating it without the host helping, all the way down the line.

Hope this helps the next person building something different to control them

Gerry

[pburgess]

Do you get this from trial and error? Curious to really know the technical reason for this behavior.

Trial and error. Indeed, strange. I'm not sure of the reasoning behind this, but I've seen other LED drivers (such as P9813) with a similar behavior, so I'm guessing it's an intentional thing. Limiting the scope of image disruption on a false-positive latch, perhaps?

[pounce]

Gerry,

I think where you are getting hung up is that you haven't realized this is shift register. It's not really a SPI chip. When you send data you fill the register on the first position with 3 bytes. Once its full it doesn't take anymore data and passes everything along with no questions asked until it gets zeros. The next position does the same.

The zeros are unique in that they signal the latch when the register is full.

It might help you to look at the datasheet for the WS2801 chip:

http://www.adafruit.com/datasheets/WS2801.pdf

[gduprey]

Howdy,

Hmm - well, in most of my experience, SPI shift-register oriented devices on a chain work more like the HL1606 (first data in eventually latches into last device on chain). In other words, like a set of "dumb" shift registers wired together. Where as the LDP seems to be "smarter" and "catches" the first 3 bytes and doesn't pass them along and once 3 are received, then goes "transparent" and starts clocking the rest along until it receives a latch command. Just through me a bit as that means the LDP is a slightly more complex beast than most simple SPI linked devices.

Anyway, thanks to looking over the code, reading this forum and some empirical work, I have my assembler LDP driver working now. I can sustain a refresh/update rate of 60hz on a 160 LED strip and can address up to 250 (at about 48hz). The controller remembers the values for each LED, so the serial interface to it can issue simple "set LED X to RGB" and not worry about refreshes, maintaining state, sending all LEDs over, etc. It can also do ranges and wildcards to make the most of the serial link speed (56K, but can be adjusted up or down). You can send text-like commands or binary commands over to it. Since it's on an 18F series PIC, the hardware is literally a single chip and a bypass cap -- no other externals components. Makes it trivial to interface/control from computers or other embedded controller devices that don't have the brains/resources to manage a whole string.

Gerry

[pounce]

Cool. Feel like sharing with the class?

[gduprey]

I'll have to do some checking. Two issues are 1) I'm doing this, in part, for a client and I need to insure they are OK and 2) while the ISR portions are in assembler, the parsers and main logic is all written in C using the PICC-18 commercial compiler. I suspect the code can be adapted to some other C compiler (and the assembler would too), I doubt it would be just grab, compile and go (it seems every PIC compiler has differences in how certain things are handled (setting configuration bits, including assembler, etc).

I do know that I can absolutely distribute the .hex file which can be programmed into the chip easy and cleaning up the docs would be pretty straight forward. Anyone think that would be useful or should I hold out to see if I can get source code?

Gerry