UCS1904/2903 based pixels (2811 with different timing).

[tmblue]

I've got some UCS1904/2903 based pixels (2811 with different timing). I can't seem to get them to do anything with the latest library, any insight into this?

Seems like the the bit timing constraints are a bit different as it requires a high of 800ns. Not sure if this is something you can easily tweak (I'm out of my elephant here, so just coming here in hopes :))

I just pulled the latest and still crickets. hook up to standard 2811, no issues.

[Gadgetoid]

This is actually the first I've heard of these pixels. I'd guess nobody with the expertise to add support currently has access to any. Since the timing is pretty fundamental to how the library actually works, I suspect it wont be easy.

Looking at the datasheet, it requires a high pulse of 2us followed by a low pulse of 0.5us for HIGH and a high pulse of 0.5us followed by a low pulse of 2us for a LOW.

The current code uses 3-bit SYMBOL_HIGH 0b110 and SYMBOL_LOW 0b100 constants that represent the timings for low and high pulses.

This is because the total time of a pulse for WS281x-compatible pixels is approximately 1.2us, and the longer pulse is approximately twice the shorter pulse giving a 2:1 ratio (not necessarily true, but there's an allowable margin for error that lets us make that assumption). So 0b110 can represent 0.8us high and 0.4us low or vice versa.

The ratio of pulses in your UCS1905 pixels is 4:1 rather than 2:1, which means you would require 5-bits to represent your HIGH and LOW symbols: 0b11110 and 0b10000

Now I believe it's possible to modify the library to support these larger symbols, but this would have knock-on effects with timing. It would also require some fairly fundamental changes, plus regression testing. I don't think it's likely to happen soon.

If these pixels/driver chips are popular enough, I don't see any reason why it couldn't happen. Though people with more knowledge than I about how this all works may have different opinions.