5m RGB+W Pixel Tape information

I finally got the LED tapes that I bought from Ray Wu's store working.
http://www.aliexpress.com/item/UCS2912-RGBW-led-pixel-strip-60LEDs-m-DC5V-input-5m-long-non-waterproof-WHITE-PCB/32347877425.html

The data sheet for the UCS2912 describes how the RGB pins are addressed within the data protocol which is a Return To Zero (RTZ) 3 bit pattern for each data bit. The USC2912 can control 4 RGB LEDs.
Sent as RGB1 RGB2 RGB3 and RGB4 to the device makes sense if there aren't any white LEDs. In reality the ordering of the LEDs on these tapes is quite different than just RGBW. The LEDs are mixed around a bit.

Each USS2912 controls 3 of the RGBW 5050 type LEDs. The tape can be cut at each block of 3 LEDs.
The order of the data to the LEDs is as follows:
LED PIN
R1 == R1,
G1 == G1,
B1 == B1,
W1 == R2,
R2 == G2,
G2 == B2,
R3 == R3,
W2 == G3,
B2 == B3,
W3 == R4,
B3 == G4,
G3 == B4,

I'm using a dsPIC30F5011 and the SPI bus to transfer the MOSI data to the LED Strip. I'll report back when I have the DMX data running the LEDs. The 5m strips I have contain 300 LEDs x 4 channels so one DMX Universe won't work. These are going to be used as Valence Lights for normal white lighting and run colours at Christmas.

 

This turned out to be more difficult than I thought. Detailed technical description follows useful for anyone writing their own micro-processor code.

The problem is the UCS2912 wants 400nS bits in a pattern of 100 or 110 for a logic 0 or 1. Using the SPI data line to send this out with a clock of 2.5MHz the problem is that only two logical bits fit in each byte. I was trying to fit 8 data bits into 24 clocked bits. It kind of worked. But certain colours or patterns were wrong.
The solution was to organize an intensity byte into 4 bytes (32 bits) instead of 3 bytes (24 bits).
Each byte holds two data bit patterns. The least significant bits of the byte are 0.

Initially I wrote a Delphi (Pascal) program to generate a look up table for each intensity value from 0 to 255 with 3 bytes per intensity value.
For example:
A 0x61 in binary is 01100001 which the UCS2912 expects to appear on the data input as:
100 110 110 100 100 100 100 110

As bytes it's
10011011 01001001 00100110 which works perfectly via SPI. The MOSI line always drops to 0 after each byte and that matches the data stream so the LED would work.

But now a 0x7F in binary looks like this 01111111 and translated to 2912 format:
100 110 110 110 110 110 110 110

As bytes it's
10011011 01101101 10110110

The problem is between the second and third byte. The SPI MOSI line drops to 0 between bytes and that means a zero is inserted between the two 1's resulting in a 10 10 pattern which illegal. The lights behaved badly.

The solution is to pack the bits into 4 bytes instead of three with trailing 0's in each byte. Then it's impossible to have a 11 pattern broken up and the system is still fast enough to keep up.

Here's one of the lines generated by the pascal program for the look up table.
{0x98,08,08,08}, // 0x7F
In binary this is
10011000 11011000 1101100 11011000 and each bit now looks like this
100 11000 110 11000 110 1100 110 11000

Since the protocol is Return To Zero (RTZ) additional zeros don't matter. Only the 100 or 110 part of the bit stream.
And the Vixen Megatree now easily controls the 120 RGB LEDs. I will control the White ones separately.
Yahoo!

 

An update on driving RGB, RGBW and RGBWI pixels with Vixen.
Attached is a scope photo of some of the signals.
The yellow goes up when DMX512A start of frame is found and down when it's done 513 bytes.
The pink is the RS485 DMX512A at 250 kbps. I'm using 262 slots of the 512
The blue is the NRZ protocol for the GE-35 lights.
The green is CAN bus messages packed with two lights per message running 500kbps.

The GE bulbs are RGBI with 4 bits per RGB and 8 bits for the Intensity. There's also a 6 bit device address. Each bit takes up 10uS pulses and there are 3 per bit so it takes quite a while to send data for 50 lights.

Although not shown the RGBW pixel string runs 400nS per sub bit of RTZ so it's much faster even with 32 bits per byte or about 25.6m

The Olympic Ring Lights are RGB+I but are scaled and packed to 6 bis per colour for 24 bits and 8 bit for intensity allowing dimming without a colour shift.

Vixen still crashes a lot. The J1 SYS board has been great.