Does FadeCandy support the RGBW Pixels (SK6812RGBW)?

[alain...@gmail.com]

Hi
Does FadeCandy support the RGBW Pixels (SK6812RGBW)?
Alain

[alain...@gmail.com]

The difference is, that the SK6812RGBW needs 32 bit per LED-Pixel, instead of only 24 bits per LED Pixel of WS2812.
Does FadeCandy support the 32 bit RGBW mode? (RGBW = red green blue warm-white)

[Colin Harrington]

I would love to see this too, but I believe that fadecandy is pretty tied to the 24bit color implemented in WS2811/12.  The USB protocol, interpolation, dithering, color lookups, and the underlying DMA  (OctoWS2811z) are all tied to 24bit color.

~ Colin

[ge...@zips.uakron.edu]

I would also really like to see this. I am working in a photo project that could really use the better quality white.

[Joey Verbeke]

+One more to the "I would love to have this" group! :]

[Louis Beaudoin]

Assuming it was possible to add support for driving RGBW LEDs, how would you want it to work?  Would you want a separate color channel for the white LED, or for it to be transparent, so when you set RGB color {0xFF, 0xFF, 0xFF}, the controller would know to turn on the white LED and not any of the RGB LEDs?

[Jonathan Hamilton]

+1 for me.  

I am new to Fadecandy and LEDs, so not sure my vote should count =) , but I imagine there would be a broader palette of colors available if W channel can be controlled independently (e.g., blue + white = light blue).

[Matt Pinner]

Am I missing something where open source became a democracy vs a do-ocracy?

I believe code and tools are available to anyone with the will to add rgbw support to their own fork. Pull requests seem fairly well entertained by fadecandy to date.

Does opc support rgbw? I assume so.

--
You received this message because you are subscribed to the Google Groups "Fadecandy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fadecandy+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Colin Harrington]

Would you want a separate color channel for the white LED

The RGBW strips take the data as 32 bits(4 bytes) per pixel in order.  I would think that the effects generator (the thing sending data to fadecandy) could handle controlling the W values.  RGBW may change the color model that you might want to use.  Technically it might be possible to introduce a new OPC command for just the white channel, but I still think you'd be better of doing it in your effects generator code.

 

Does opc support rgbw?

OPC references 24bit RGB data, but the messages are just a block of bytes with a length field. http://openpixelcontrol.org/  Looks like OPC could handle RGBW data. 

I believe code and tools are available to anyone with the will to add rgbw support to their own fork. Pull requests seem fairly well entertained by fadecandy to date.

Right on!  https://github.com/scanlime/fadecandy/

The underlying OctoWS2811z (custom fork from Paul's OctoWS2811 lib) would have to be updated to handle RGBW (timing differences, etc)

The color lookup tables will have to be refactored.

There are a bunch of places that will have to be updated for 32bit vs 24bit color.  The USB messaging will have to be updated, examples. etc.

One of the key features that I like about fadecandy is the temporal dithering & the interpolation between frames.  Due to the timing/PWM & datarate of the WS2812 style pixels using dithering means that you'll only be able to drive 48 pixels per channel instead of the 64 that you are currently able to.  

Colin Harrington
colin.ha...@gmail.com

--
You received this message because you are subscribed to a topic in the Google Groups "Fadecandy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fadecandy/HajFR96c-uc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fadecandy+...@googlegroups.com.

[Jayarama Marks]

[0]   =   r1   g1   b1

[1]   =   g2   w1   r2

[2]   =   w2   b2   g3

[3]   =   b3   r3   w3

[4]   =   r4   g4   b4

[5]   =   g5   w4   r5

.

.

.

[Shen Tian]

+1 on this. It's quite ambiguous how this could work.

[Mingjing Huang]

Is this a transformation you've tried and works?  Why the misalignment with w[n] values within the 4 24bit blocks?

[Wes Harden]

That's a great question.

[Ashwath Rajan]

I'm not sure why, but Jayarama's transform works like a charm!  It repeats every 12 bits so you can simply swap elements with a new iterator reference every 12 bits

On Friday, December 30, 2016 at 1:52:41 AM UTC-8, Wes Harden wrote:

That's a great question.

[Jonathan Barchi]

I haven't tried this with hardware yet, but it makes sense that it should work based on what the hardware does. 

The integrated controller in the LEDs - whatever kind - is pretty simple by design so they can just be hooked up in arbitrary chains w/o any need for addressing or etc. Consider the 2812 first. what each 'pixel' controller is doing is grabbing and using the first 3 bytes it sees on the data-in pin, and then forwarding everything else out via the data-out pin to continue likewise down the chain. This is why we can just connect them up in chains - and the library/hardware is just taking care of sending the bytes we want out the line to the first pixel as properly timed bits. There's no framing per se (at least that I've seen with a LA on the line); what goes out on the wire is just a stream of bits that gets chopped up and interpreted by the controllers. This is probably why timing is so critical with these parts. 

Now take the 6812 case. Basically all the controller has to do differently is consume the first 4 bytes it sees, instead of 3, and pass the rest on. Because the serial protocol is so simple, it doesn't really matter if we're talking to 2812s or 6812s at the physical layer - either way we just need to generate a long stream of the correct bits, which the hardware (FC) does nicely for us. From a programming standpoint it would be nice to be able to send the FC (R, G, B, W) tuples - or (H, S, V) - but this has no real effect on what ultimately goes out over the line (ignoring, for now, interpolation and dithering). 

Since the 6812 just eats 4 bytes instead of 3, and the physical protocol is essentially the same, we can get the desired effect by composing a message that contains groups of (R,G,B) (W, R, G), (B, W, R), (G, B, W), (R, G, B) ... as needed. 

Now this might cause strange things to happen with the internal dithering and/or interpolation code - although I think the interpolation is maybe just per-color in which case it should be OK - but you can turn those off in firmware if necessary. 

Has there been any progress on the hardware side since the last message (January)? I haven't found anything yet, and it seems like a fun project to work on. I think the most natural interface for the RGBW parts would often be HSV, allowing the FC to decide when and how much white to use for optimal color. Is anyone else interested in playing around with this? 

JB

[Henry Ip]

The RGB to RGBW mapping kind of works but it's not exactly as expected. The setup I used to test is as follows:

• Fadecandy firmware version 1.07
• Processing 3.3.6
• OPC (Open Pixel Control client for Processing) strip64 example from scanlime/fadecandy Github commit Oct 7
• NeoPixel RGBW SK6812

The RGB to RGBW mapping is:

And then it repeats every 4 LEDs.

[Matti]

I would like to know how to get this working, I'm really curious how you did it Henry but your image seems to be gone..

Op maandag 6 november 2017 21:38:38 UTC+2 schreef Henry Ip:

[Fiid Williams]

It can.  I modified opc.py so that it takes RGBW tuples and does the mapping for you.  I can share that if it’s useful.

It does work no probs, but it does bring the strand limit down to 48.

—Fiid

[Fiid Williams]

Hey,

Here is a modified version of the python OpenPixel Client that takes an array of (r,g,b,w) and sends them to fcserver in the right order.

Note that the server still thinks it's talking to RGB leds, so you'll have to do the (n/3)*4 conversion (i.e. 48 > 64) conversion for that, or just leave it thinking that it's talking to 512 LEDs like in the default configuration.  It doesn't matter if you send data to LEDs off the end of the strand that don't exist.

Hope this is helpful,  It's been pretty stable for me.  I ran an 8*48 array from a Raspberry Pi for 4 days continuously and it was still working at the end :D

--Fiid.

To unsubscribe from this group and stop receiving emails from it, send an email to fadecandy+unsubscribe@googlegroups.com.

[Matti]

Thanks a lot! I had the strand already at 48 pixels, that I had somehow figured out :D

Op donderdag 8 maart 2018 21:07:54 UTC+2 schreef Fiid Williams:

To unsubscribe from this group and stop receiving emails from it, send an email to fadecandy+...@googlegroups.com.

[Brian Albrecht]

Can the OPC.py be used with processing as well? Has anyone successfully implemented the RGBW with processing given the 48 pixel limitation caused by the 32 bit per pixel data format with the RGBW?

[Brian Albrecht]

Python seems to work great but still having trouble with processing. Added the highlighted code to OPC to try to put a zero value bit into the stream of bits to represent a white value and provide the needed 32 bit per led datastream. I also tried messing with the integer highlighted in orange in case the stream was out of phase, so to speak. I had to alter the size of the array which is created in 

      packetData = new byte[packetLen];

  It changed the colors in interesting ways, but so far unable to get it to work. I suspect there is something happening under the hood which is but specific in one of the java libraries. I'm putting this to rest for awhile...

    int numPixels = pixelLocations.length;
    int ledAddress = 7;

    setPixelCount(numPixels);
    loadPixels();

    for (int i = 0; i < numPixels; i++) {
      int pixelLocation = pixelLocations[i];
      int pixel = pixels[pixelLocation];

      packetData[ledAddress] = (byte)(pixel >> 16);
      packetData[ledAddress + 1] = (byte)(pixel >> 8);
      packetData[ledAddress + 2] = (byte)pixel;
      packetData[ledAddress + 3] = (byte)0;
      ledAddress += 4;

[Brett Renfer]

Hi! I know this is very old, but hopefully others like me that stumble upon this thread will find some use...

I have a semi-working processing sketch. It needs some <3 for addressing channels beyond 0, and could be rewritten to be faster (i.e. arrays instead of arraylist, etc) BUT it does work!

Quick sketch attached. Tried to add semi-useful comments... 

✌️

-- Brett

[Tomfoolery]

Thanks for posting this. I got into Fadecandy knowing I would have to tackle RGBW one day. That's still a little ways away but it's great to know I have something to look at when I'm there. 

Cheers!

[Leo Sauermann]

What Louis Beaudoin asked 2016 is relevant to everything coming after:

(separate) Would you want a separate color channel for the white LED, (=transport 4 Byte over from Processing to OPC to USB to the Controller)

(transparent) or for it to be transparent, so when you set RGB color {0xFF, 0xFF, 0xFF}, the controller would know to turn on the white LED and not any of the RGB LEDs?

Option "separate" means reprogramming everything: your processing/c/html sourcecode generating the animations, the USB protocol, reducing the LED length from 64 to less, etc etc.

Option "transparent" menas only  reprogramming the controller software running on the Teensy. It would take RGB values and calculate how much W to render out for this RGB value.

Here is a fork of FastLED that implemented the "transparent" approach: https://github.com/coryking/FastLED.

Option "transparent" introduces a change only in the hardware doing the "rendering of the RGB values onto RGBW hardware" and may be solves with a few clever lines. Option "separate" introduces many changes to "everything" starting with your animations programmed.

Option "separate" clearly introduces headaches and work for many people and code.

I highly recommend anyone who wants to solve it, to go for the code running on the Teensy and look into the coryking fork I linked above for inspiration. I personally don't have fadecandy hardware yet, I am planning a project and evaluating choices of hardward I can use. I found your thread here and through my research I am also aware of "what coryking did". I hope that connecting the dots helps you here. 4 years after bringing this up, it is not solved yet in the master of this project and going back to Louis' question from 2016 is relevant.

As facts I cite for motivating my recommendation I take what I see in this thread: the troubles introduced by going for option "separate" is shown in the fact that it took 2 years of thinking to get from the level of the idea up to processing sketches running one animation (but still not all animations on all source-bases):

• Colin Harington on 5.4.2016: changes to USB ... trouble!
• Colin Harington on 5.4.2016: "Due to the timing/PWM & datarate of the WS2812 style pixels using dithering means that you'll only be able to drive 48 pixels per channel instead of the 64 that you are currently able to." 
  
• Jayarama Marks on 10.5.2016: this mapping works on the hardware, but makes the whole stack of software before obsolete
• Jonathan Barki on 19.5.2017 analyzed the intricate details needed to change everything in the procotol - again not needed when going for "transparent"
• Fiid Williams on 8.3.2018 changed the OPC server to support RGBW. Again, when going to "transparent", this would not be needed.
• Brian Albrecht on 29.6.2018 finally came to the level of changing processing code to RGBW. Again, would not be needed when going for "transparent".

I may also add a personal belly-feeling: I think the RGB color model is quite dominant in how computer rendering of graphics works today, so building a stack on it is always a safer bet for compatibility than RGBW.