New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is the RGBW supported? #482

Open
ramkithepower opened this Issue Aug 23, 2017 · 27 comments

Comments

Projects
None yet
@ramkithepower

ramkithepower commented Aug 23, 2017

Hi there,

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

@marmilicious

This comment has been minimized.

Show comment
Hide comment
@marmilicious

marmilicious Aug 23, 2017

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

marmilicious commented Aug 23, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@coryking

coryking Aug 25, 2017

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?

coryking commented Aug 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ramkithepower

ramkithepower Aug 25, 2017

ramkithepower commented Aug 25, 2017

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Aug 25, 2017

Member

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.

Member

focalintent commented Aug 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@coryking

coryking Aug 25, 2017

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...

coryking commented Aug 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Aug 25, 2017

Member

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.

Member

focalintent commented Aug 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@coryking

coryking Aug 25, 2017

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 commented Aug 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@coryking

coryking Aug 25, 2017

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 :-)

coryking commented Aug 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Aug 25, 2017

Member

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.

Member

focalintent commented Aug 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@coryking

coryking Aug 25, 2017

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...

coryking commented Aug 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@yesyesuk

yesyesuk Aug 25, 2017

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).

yesyesuk commented Aug 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Aug 25, 2017

Member

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.

Member

focalintent commented Aug 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tombresson

tombresson Sep 25, 2017

@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!

tombresson commented Sep 25, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@seymar

seymar Oct 28, 2017

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

seymar commented Oct 28, 2017

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

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Oct 28, 2017

Member

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

Member

focalintent commented Oct 28, 2017

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

@Diaoul Diaoul referenced this issue Nov 19, 2017

Closed

Add hsv_to_rgb and rgb_to_hsv Jinja2 filters #10462

3 of 3 tasks complete
@wvdv2002

This comment has been minimized.

Show comment
Hide comment
@wvdv2002

wvdv2002 Dec 11, 2017

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.

wvdv2002 commented Dec 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@coryking

coryking Dec 12, 2017

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...

coryking commented Dec 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@aziraphale

aziraphale Jan 4, 2018

@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...)

aziraphale commented Jan 4, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Jan 4, 2018

Member

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

Member

focalintent commented Jan 4, 2018

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

This comment has been minimized.

Show comment
Hide comment
@aziraphale

aziraphale Jan 4, 2018

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!)

aziraphale commented Jan 4, 2018

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

This comment has been minimized.

Show comment
Hide comment
@coryking

coryking Jan 4, 2018

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.

coryking commented Jan 4, 2018

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

This comment has been minimized.

Show comment
Hide comment
@RickDB

RickDB Feb 5, 2018

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

RickDB commented Feb 5, 2018

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

This comment has been minimized.

Show comment
Hide comment
@Zefiro

Zefiro Mar 3, 2018

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.

Zefiro commented Mar 3, 2018

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

This comment has been minimized.

Show comment
Hide comment
@nixmeer

nixmeer Mar 16, 2018

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

nixmeer commented Mar 16, 2018

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

@garrettdowd

This comment has been minimized.

Show comment
Hide comment
@garrettdowd

garrettdowd Apr 19, 2018

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.

garrettdowd commented Apr 19, 2018

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

This comment has been minimized.

Show comment
Hide comment
@adityat90

adityat90 Apr 28, 2018

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?

adityat90 commented Apr 28, 2018

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

This comment has been minimized.

Show comment
Hide comment
@usane1

usane1 Aug 16, 2018

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.

usane1 commented Aug 16, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment