So, I checked out the APA102 protocol. It is somewhat similar, but the APA102 does not have the checksum bits in the first byte and uses 32 bits of "1" as end frame.
Does anyone know of other LED chips that use checksums in their protocol?
in the 2 weeks since Hacker Camp I have finally figured out the mystery LED pixels I had manufactured for me in Shenzhen and I would like to share the story with you since they use a somewhat strange protocol. I am new to this, so please bear with me if this gets too detailed. If you are just interested in the protocol, please skip down to the last section.
The Story: While at Hacker Camp I was looking for some RGB LED pixel chains for some projects I might do in the future. The most important thing for me was that they should have a clock line. I didn’t want to deal with strange timings for them. Several dealers I asked turned me down but while on tour at the Depu market one vendor offered me to have RGB LED pixels with a clock line manufactured for me at their factory and delivered within the next days. I could not turn down the possibility of a custom order while in Shenzhen so I ordered 200 pixels. The vendor promised to e-mail me the datasheet…
Well the pixels arrived, but the datasheet did not. I tried to mail them, but got no answer. So here is my problem: The pixels are encased in semi-opaque plastic. I could see, there was a driver chip but could not read the writing it. I tried to polish the plastic, it stayed semi-opaque. I tried to drill away the plastic, the glue underneath left the chip unreadable. I tried to heat the glue, to no avail. Since I did not want to risk damaging one of the pixels, the only way left for me was trying to figure out the protocol!
Figuring it out I knew that the interface had 4 wires: GND, VCC, CLK and DATA. I also knew from the vendor that the LEDs were 5V (the lady there mentioned it after the sale). The two loose wires on the connector (red and blue) were easy to figure out. So I hooked them to my bench power supply and connected the remaining two wires to my Bus Pirate. Just to be safe, I tried an I2C scan but got no results. So it was probably an SPI interface (or something in that direction). One wire configuration lit up the LED string all white, one in some weird color-mix. I went for the all-white one. After trying a few data packets I was sure that these LEDs used none of the common LED drivers like the WS2812. So I decided to make this work any way I could. And old instructor back at university described the art of reverse engineering protocols as “bang it ‘till it moves, then tickle it ‘till it works”. So, that’s what I did. :)
I switched from the Bus Pirate to an Arduino for this, just because I am more at ease with scripting on the Arduino. After a few cycles of sending combinations of 1s and 0s I managed to turn off the first few of the pixels. So they could be controlled somehow! Thus, the “tickling” part began and I will spare you the details of that. But I tried many, many things. Most of them did not work. The wicked thing with these pixels is that they need 32 bits of data with the first byte having check-bits against the remaining 3 bytes.
The protocol The protocol I figured out is as follows (clock rising for every bit):
+ Start message: 32 bits of 0. + Repeat 32 bit message for every pixel in the chain (e.g. 50 pixels, repeat 50 times) ++ Checksum byte: +++ Bit 1 and 2: “1 1” +++ Bit 3 and 4: Inverted bytes 8 and 7 of byte “blue” (^8 ^7 blue) +++ Bit 5 and 6: Inverted bytes 8 and 7 of byte “green” (^8 ^7 green) +++ Bit 7 and 8: Inverted bytes 8 and 7 of byte “red” (^8 ^7 red) ++ 8 bits for “blue” ++ 8 bits for “green” ++ 8 bits for “red” + End message: 32 bits of 0.[/list] Then the whole chain will latch the new colors.
Now that I figured it out I can start thinking about the nice things I might do with these pixels... And optimize my code for the pixels so I can drive more of them faster.
