Feature Request - Support for 5-channel pixels like WS2805 RGBCCT

[m0dbot]

Is it possible to add support for these pixels?
Here is an example product. https://www.btf-lighting.com/collections/ws2805-rgbcct-24v
I ordered some, it should arrive within the next days, then I'd be happy to test anything needed.
Thank you

[strimbob]

following
Also interested in this
thanks!

[robertlipe]

I won't be the one to do it, but for any (sane) architecture you care about and control, the needed modifications aren't hard. There's already support for four-bulb strips; the fifth bulb (cool white vs. warm white) appears in the protocol in the "obvious" way. Roll up your sleeves and tackle it (together, if need be).

On the wire, the protocol is the same. The difference is in the stride. Instead of counting Green, Red, Blue, [ White ], you just have to count off G, R, B, CW, WW. (Maybe the two whites are the other direction; it'll be obvious once you code it...) So mostly you "only" have to change the code actually sizing and populating the pixel buffer, probably starting with approximately

Adafruit_NeoPixel/Adafruit_NeoPixel.cpp

Line 3393 in aa798ff

} else {

The other unfortunate bit of ugliness is that RGB and RGBW, with 8-bit values in each, fit into a 32-bit value easily. This means that uint32_t argument for pixel color conveniently holds one white value, but needs some kind of a sidecar for a second white one. Maybe you add another argument. Maybe you just make that function leave that fifth pixel blank and have another new function that runs along the pixel array and fills it in. There are lots of ways to do it and most of them really aren't THAT hard. But that's the function that neesd to know there are five cards to count off (not three (RGB) and not four (RGBW)) Code like

Adafruit_NeoPixel/Adafruit_NeoPixel.cpp

Line 150 in aa798ff

numBytes = n * ((wOffset == rOffset) ? 3 : 4);

has to know there are five bytes per led to allocate the arrays appropriately. So I don't know what I'd do offhand with code like

Adafruit_NeoPixel/Adafruit_NeoPixel.cpp

Line 3708 in aa798ff

neoPixelType Adafruit_NeoPixel::str2order(const char *v) {

on an 8-bit processor ... but it's also likely that if you're building your own projects, you don't actually CARE about str2order because you know the order (Hint: on this strip, i'm about 98% sure from memory that the order is R, G, B, Warm, Cool. It's on my mind because it bucks the trend of GRB.)

The hard part about submitting a change like this to a project like this is the need to build (and hopefully test) everything from a 8-bit atmega to a dual-core K210 or Pi. If you have to be the one to support every combination of clock speed, every ATMega ever made (in assembly language) every possible ordering of R, G, B, CW, WW, and the responsibility to NOT break the code for others, it's not very much fun. See that "prime directive" in the doc.

For a hobbyist project on an ESP32, one specific strip, and code that never had to work anywhere else, this is probably a fifteen minute task. (I'm not exaggerating.)

If Adafruit themselves sent me a blank purchase order to do this, and a box of all the hardware here and I had to set up cross environments, learn AVR assembly and figure out how to count the exact number of clock cycles taken in every case (do more work, but still has to be 64 btyes long? Ick!), verify I didn't change any function signature to violate that "prime directive", etc. I'd decline to bid. THAT'S the difference in a hobbyist project and changing code like this.

So this is easy (on a grown-up CPU) to do 'well enough' but difficult to do well. It's literally just making space for five bulbs instead of 3 or 4 as is there now.

(Source: Was a professional programmer at the top of the game. I still work on a couple of LED projects like this and have these very strips.)

P.S. I'll stand on the sidelines and coach in this FR if one of you wants to run with it and ask questions. I just won't do the work.