Fastled: Is the RGBW supported?

[ramkithepower]

Hi there,

I would like to know if the RGBW is supported by fastLED?

[marmilicious]

@ramkithepower Currently RGBW pixels are not supported by FastLED. It is on the list for a future update (time frame unknown at this time).

[coryking]

I just picked up a reel of SK6812 RGBW led's and I'm not looking forward to porting my stuff over to the neopixel library. There is a lot of features that FastLED supports that isn't in the neopixel library (eg: the power management stuff, all of the effects, etc...)

I know that adding this support will require digging deep into the bowels of the library. Has any work on this started that can be picked up and ran with?

[ramkithepower]

Does neopixel support this natively.

On Aug 25, 2017 19:03, "Cory R. King" [e-mail] wrote:

I just picked up a reel of SK6812 RGBW led's and I'm not looking forward
to porting my stuff over to the neopixel library.

I know that adding this support will require digging deep into the bowels
of the library. Has any work on this started that can be picked up and ran
with?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/FastLED/FastLED/issues/482#issuecomment-324995587,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AdWADf_FSLaaCHkWepjNGEQBJj-fVuwFks5sbwxzgaJpZM4PAFfR
.

[focalintent]

I am in the middle of a complete rewrite of the library to support RGBW -- unfortunately, it is currently in a non-building state, and half the rewrite only exists as scribbled notes in a notebook here -- it is one of the first things that I will start working on again when I come back to working on the library.

[coryking]

Is there an intermediate "less perfect" step that could be taken? In another thread you linked to a patch that at least got the controller to spit out the "W" in RGBW--even if it is always zero.

Can something be done at that layer to take an RGB block and get it to start using the white pixel?

I'm thinking like pull out the "saturation" (i.e. lowest of the R, G and B values) and shove that into the white pixel. Then subtract out that saturation value from the R,G and B values and use those for the RGB channels. Something like this.

It wouldn't be perfect as it would probably mess with all the dithering and power consumption stuff built in and it might not be fast, but it could at least get the library to start making use of the "W" in RGBW without messing around with the higher layers in the library...

...I'm kinda tempted to give that a shot right inside clockless_esp8266.h and see what happens. The only issue I see is that it loads the first pixel outside of the while(pixels.has(1)) { loop, making my hackjob a bit more hacky...

[focalintent]

Right now even most of the hacky solutions fall outside of the time/scope I have to give to the library right now -- if someone wants to fork and maintain a hack on said fork, i'm happy to point people at it.

[coryking]

Thanks @focalintent,

Am I on the right track? Is there a slightly higher level I could do it so it doesn't pinpoint just my specific setup (esp8266)?

[coryking]

Also, I'm assuming that the SK6812 is just some kind of variant of the WS8212b (or whatever) that just has an extra pixel per channel... I haven't actually got my reel yet to find out... amazon has it on a truck to my house today :-)

[focalintent]

No - there isn't a higher level that it can be done at, yet -- that's why it's an almost entire re-write of the library. So much code is dependent on the structure of CRGB -- making all of that be dynamic based on whether the pixel class has 3 bytes or 4 (rgb or rbgw) or even 6 (rgbwww or other combinations that exist out there) and whether the bytes are 8-bit or 16-bit is taking a lot of overhauling pretty much everywhere.

[coryking]

Just a thought but what if the native pixel was defined using HSL and then knocked into RGB / RGBW / RGBWhatever right at the end on the way out to the actual LED strip?

Basically, make a simplifying constraint that says "when you interact with this library you are gonna use HSL -- all palettes, blends, fills, whatever are all done with HSL". Only let the lowest levels of the library care what the native pixel format of a device is.

.... course some of these controllers have very limited memory and CPU and ideally you'd want 16-bit HSL values (or, haha, floating point HSL values, haha yeah right...).

Anyway... I'll fiddle with my idea for deriving the "W" from "RGB" in a fork of the repo and see what happens...

[yesyesuk]

I have my own controllers for RGBW LEDs (non-addressable). What I have done is (as a configurable option) to derive W from RGB so that if R == G == B (i.e a greyscale value), then use the White LEDs, otherwise use the RGB LEDs.

This might be an easy hack for this library as well as it does not require a separate W value.

In the longer run I'm also looking forward to full RGBW support in this library for my addressable controllers (currently using the Adafruit neopixel libraries).

[focalintent]

Just a thought but what if the native pixel was defined using HSL and then knocked into RGB / RGBW / RGBWhatever right at the end on the way out to the actual LED strip?

Because the conversion from HSV to RGB is too expensive to do inline with the WS28xx timings (also - there really isn't, yet, a good definition from HSV to RGBW -- though @kriegsman and I will be working on that). Also - not every one works in HSV at a high level -- this is part of why the library, at a low level talks RGB (and eventually, RGBW) to the chipsets that it writes out to (since all of those chipsets want RGB data anywy), and higher levels of the library provide things like HSV (and soon, 16-bit HSV) and conversion and such. There is method to the madness when it comes to what formats are handled at what layers.

When the rewrite is done, you'll be able to work at a high level how you'd like, define your leds array as RGB, RGBW, RGB16, RGBW16, and then when the led data gets pushed out to the strip it will be converted/adjusted on an as-needed basis (e.g. if your led array is defined as RGB and you're pushing out to RGBW strips, W will just be 0'd - or if your led array is defined as RGB and you're writing tou an led strip that is 16-bit RGB, then the data will be shifted/scaled appropriately, etc... etc... ).

For environments that have enough ram to spare, I'm also going to be putting in support for a sort of backing buffer that's in the native output format of the leds being written to (I already have something like this for, say, the OctoWS2811 output -- this is also something that will be needed for more aggressive support of DMA style options in environments where that's available) - which would allow doing everything in HSV at the high level, and then show, at a high level, will convert from HSV to the appropriate RGB/RGBW/RGB16/etc... before calling the controller level show.

The reason why I'm not accepting hacks for RGBW support into the library here at the moment is because a) they will always be hacks and limited and trying to juggle/support those limitations is not something I want to deal with (if you do it in a fork - you're more than welcome to deal with that support!) and b) even quick hacks take time, and what little time/space i have for working on the library I want to put into the full support/work.

[tombresson]

@focalintent, just wanted to say that all your hard work in rewriting this library is appreciated. Thank you and keep kicking butt! Can't wait to try it out!

[seymar]

I found a great article that could help with implementation of RGBW:
http://blog.saikoled.com/post/44677718712/how-to-convert-from-hsi-to-rgb-white

[focalintent]

The conversion from hsv to rgbw will be the simplest part of supporting rgbw strips.

[wvdv2002]

For now, what I did is use the great fastled library for all led effects and use the Neopixel library to output the RGB + W (settable by an extra slider) to the SK6812. This can be considered a working hack. It makes everything a tad more CPU intensive though, but an ESP8266 still has enough power to drive 240 SK6812 leds in this way. You can find a working example in my ESP8266-LED-Websockets repository.

[coryking]

I've added support for RGBW, as well as DMA on the ESP8266 chipset in my own fork of FastLED:
https://github.com/coryking/FastLED

My RGBW stuff will use the white LED and looks pretty damn sweet. For RGBW, you'll have to:
#define FASTLED_RGBW

For DMA:
#define FASTLED_ESP8266_DMA

Note that DMA only works on GPIO pin 3 (which seems to be the "RX" pin on a lot of dev boards in the wild). It won't work with FastLED's multiple strip feature...

[aziraphale]

@coryking Any idea how much work it'd be to port your RGBW+ESP8266 work to Arduino? ESP8266 will be useful for me in the future, I'm sure, but right now I need a standard Arduino Nano module to support a couple of SK6812 RGBW strips (well, one strip and one ring). My C/C++ knowledge is extremely thin, but I'm happy to throw a bit of £ at someone in exchange for their time implementing this, if that helps :)

(I'd love to help in a more direct way, but figuring out C/C++ and the FastLED code is a bit beyond me and my free time right now...)

[focalintent]

The Arduino code that needs to be changed isn’t even C/C++ - it’s pretty tightly written asm code, and needs a pretty significant rewrite to fully support rgbw

[aziraphale]

Damn, okay, fair enough - worth a try :)

Out of interest, what happens if you try driving RGBW strips with the existing code? Does it completely mess up like I've seen from other libraries that aren't expecting RGBW, or do you get nice clean RGB, but with the W channel left idle? I'd be happy with just RGB working (having RGBW was supposed to give me more flexibility, not make things this much harder!)

[coryking]

Each pixel on an SK6812 RGBW strip expects an extra byte (the white byte). If your driver doesn't spit out that extra byte everything is going to look very messed up... and by "messed up" I mean like "looks like random noise" kind of messed up, not "kinda-sorta looks like what the colors should be" messed up :-)

I have no clue how the ASM stuff works for the Arduino, but a quick hack would be to get it to just push an extra byte out per LED just so you aren't getting "messed up" output. It won't use the white pixel though, so at that point you might as well just use an RGB strip anyway.

[RickDB]

Just got a sample of TM1814 12V RGBW leds, anyone knows if these are supported by forks or backwards compatible with another chip defintion?

[Zefiro]

For a quick test of the power consumption of a 5m GRBW strip I used this hack:

#define NEOPIXELS_NUM 300
#define NEOPIXELS_NUM_CONVERTED ((NEOPIXELS_NUM * 4 + 2) / 3)
#include<FastLED.h>
CRGB leds[NEOPIXELS_NUM_CONVERTED];

void setup() {
  FastLED.addLeds<WS2811, NEOPIXEL_PIN, RGB>(leds, NEOPIXELS_NUM_CONVERTED);
}

void setPixel(int idx, byte red, byte green, byte blue, byte white) {
  int idx2 = (idx * 4) / 3;
  int sub = (idx * 4) % 3;
  leds[idx2].raw[sub] = green;
  sub = (sub + 1) % 3;
  idx2 += (sub == 0) ? 1 : 0;
  leds[idx2].raw[sub] = red;
  sub = (sub + 1) % 3;
  idx2 += (sub == 0) ? 1 : 0;
  leds[idx2].raw[sub] = blue;
  sub = (sub + 1) % 3;
  idx2 += (sub == 0) ? 1 : 0;
  leds[idx2].raw[sub] = white;
}

This totally ignores any magic or helper functions FastLED might have and just distributes the 4-colors into the 3-colors array.

PS: Turned out I saturated the PCB with 5.2 Amps (~30 Watt), the leds getting noticably dimmer towards the end. Powering from both sides would be recommended.

[nixmeer]

@focalintent Is there any time frame you can tell for RGBW support? Like 2 months or the end of 2018?

[garrettdowd]

Just my two cents. I have a 2,400 piece RGBW SK6812 LED installation for home automation. I am currently driving it with my own library based on the Adafruit Neopixel RGBW library. My current library is blocking so I rarely play around with animations. I am thinking of rewriting my entire library to be non-blocking, but I would really rather use FastLED.

I am just a hobbyist so I am pretty sure I can't write production quality code, but FastLED RGBW support would be a great birthday present ;) If there is anything I can contribute to let me know.

[adityat90]

Hi. I too would like this functionality. Is there anyway that we can contribute to this? If there is a branch where we can send PRs to?

[usane1]

Hi!

Have anyone experienced a minimum dimmable condition with sk6812rgbw?
I ordered few strips from aliexpress and just found out the minimum brightness is at 64. Below this the leds arent light.

[CWempe]

fyi:

Problem

Looks like older versions of FastLED (including https://github.com/coryking/FastLED) are not compatible with newer versions of the espressif8266 platform.
The device keeps rebooting (wdt reset).

platformio.ini:

[env:d1_mini_pro]
platform = [email protected]
board         = d1_mini_pro
framework     = arduino
monitor_speed = 115200

lib_deps =
     [email protected]
     ; or [email protected]:coryking/FastLED.git
     [..]

Workaround

My workaround is to use an older version of espressif8266 (tested 2.1.1) if you want to use an older version of FastLED (or FastLED for RGBW from @coryking)

platformio.ini:

platform = [email protected]
[..]

Or use the latest FastLED version. *duh*

Solution

Maybe someone can create a new (inofficial) RGBW-version based on the latest FastLED code.