RGBW LED Support

[immutef]

Is it possible to get RGBW LED support? I just came over the issue because I accidentally bought two of the 8 LED PCBs, unfortiantely I bought the RGBW version and not the RGB version. This library doesn't work with these but I'd love to I'd like to be able to.

[ajfisher]

It is. The challenge with rgbw devices is you're going to decrease the maximum throughput by about 30% and that will affect both how much you can transmit over the wire as well as how long a frame takes to update.

I haven't got access to one of these strips as yet as they are still crazy expensive here in AU. Looking at the spec though I can give you some good direction on changes you'd need to do.

On Fri, May 6, 2016, 06:11 Pierre Minnieur [email protected] wrote:

Is it possible to get RGBW LED support? I just came over the issue because I accidentally bought two of the 8 LED PCBs, unfortiantely I bought the RGBW version and not the RGB version. This library doesn't work with these but I'd love to I'd like to be able to.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/ajfisher/node-pixel/issues/64

[duncanmcalester]

I’d be interested in taking a shot at this if you can point me in the right direction.

[ajfisher]

@dmcalester so there's a couple of places this needs to occur. The first is that we'll need to configure the firmware to take an additional byte - this means changing all the 3 byte colour values to 4 byte ones.

In recent node pixel we've actually changed to simply an array which is mapped according to pixel depth in preparation for this so it means we just need to jump along it in windows of 4 bytes rather than 3 bytes.

I'm assuming the W channel is just byte 4 but you'll need to check to make sure the mapping is correct.

We'll also need to extend the protocol to configure this to use 4 byte values per pixel instead of 3 byte ones.

Finally, all of the pixel definitions will need to be updated in order to take a white channel as well. This will have a few implications on doing things like this:

pixel.color('green');

As under the hood that gets mapped to an RGB colour with no white information so by default that will be a white value of 0. As will:

pixel.color("#FF0000");

So we'll need to account for this and also allow the extra channel on the end to be ignored in situations where the pixel isn't set to take RGBW.

[MartinMuzatko]

If there is anything I can do to support, let me know, Also wanting to see this :)

[ajfisher]

@MartinMuzatko This has definitely stalled. If you go back to my notes a couple of comments back, the key here is that you need to change the colour depth per pixel and make it variable. Specifically you'll beed to make it configurable but have it default to 3 bytes as it currently it.

The biggest challenge that will happen here is that your total number of pixels will decrease as will the throughput because you're going to be storing and sending a lot more data to the mcu.

[manuman94]

Hi! It would be great to power my RGBW lights with node-lights.

Before adapting the library to be compatible, do you think it would be easy to only send 0 to the white channel for the moment? I tried to find at the code some solution for me but I don't understand I2C protocol and bitwise operators combined.

Maybe a workaround would be enable a RGBW mode where the W channel is not being used.

Can be possible?

Thank you, greetings.