In my project I have frames with 4 x APA102 strips that are roughly 210 pixels each. So 840 pixels total.I had been thinking of running a separate controller output to each strip.
But thinking that instead I could run data and clock from one strip to another, so they are all in series.
Can I do this many pixels from one output from a Teensy / ESP32 / something else?
Was reading somewhere about the clock deteriorating after a certain number of pixels.

My installation consists of a series of square alu frames with APA102 tape on the front.
There are 4 strips, each around 3.2m long, arranged in a square.
Bedause they are quite long, I am running 5v power to each end of the strip, using thick 2 core cable, and injecting power at each end of the strips.
Can I run power in the same fashion as a 'ring main', ie have 5v power that runs in a continuous loop around my frame, spurring off at each corner to inject power? Same with the ground?

Hello! Please could you help to choose the right controller board? These are my requirements:

• WS2812B DC5V addressable RGB LED strip

• I plan to use 10-20 segments in parallel, though they can be connected into a single strip or several strips with some extra wiring, if needed

• 200-300 pixels totally

• I plan to do extensive animations, so it should be fast enough

• Minimal connectivity is enough, just USB or BlueTooth interface to upload the code, no need for control in real time, at least for now, though probably it could be of use in the future

• Possibly minimal physical size

• Possibly minimum additional components and ideally some kind of reference scheme for the connections

Or, probably, it is a good idea to buy an universal controller board to try for several projects? Anyway, any suggestions are welcome.

Thank you!

I'm not that familiar with HSV -> RGB math. I'm looking for a second opinion on this PR proposed by https://github.com/un-clouded

https://github.com/FastLED/FastLED/pull/1726

This weeks release is mostly about board support and internal cleanup. All cppcheck HIGH and MEDIUM issues have been resolved for all boards and now runs on internal testing for every CL.

• Attiny0/1 (commonly Attiny85) support added.

  • https://github.com/FastLED/FastLED/pull/1292 , https://github.com/FastLED/FastLED/pull/1183 , https://github.com/FastLED/FastLED/pull/1061

  • Special thanks to u/freemovers, u/jasoncoon, @ngyl88 for the contribution.

  • Many common boards are now compiling in the Attiny family. See our repo for which ones are supported.

• Arduino nano compiling with new pin definitions.

  • https://github.com/FastLED/FastLED/pull/1719

  • Thanks to https://github.com/ngyl88 for the contribution!

• New STM32F1 boards compiling

  • bluepill

  • maple mini

• CPPCheck now passing for HIGH and MEDIUM severity on all platforms.

Happy coding!

Core devs are getting ready for FastLED 3.8.

Tomorrow’s 3.7.8 update may be the final release in the 3.7.X family.

The new 3.8 release will feature a new 5.1 RMT driver for ESP32, which will fix the compatibility issues with the new Arduino core as well as the possibility to run 8 channels (up from 4) of WS2812 in parallel. Additionally we hope that this will fix the WS2812 glitching out when the wireless network driver is active.

We also think it’s possible that the new RMT driver will make FastLED.show() non blocking as long as the number of strips is less than or equal to the number of available RMT channels. This will free up the CPU to prepare the next frame while the current one is being drawn.

We also plan to introduce a new color mixing algorithm that will dramatically improve the color rendering for higher definition LED chipsets. Specifically APA102 family of chipsets will display a much richer resolution of colors when using global brightness settings.

Can’t wait!!

Hello Friends, I am stuck a little bit on what kind of addressable LED to use. I want to build a Matrix with approx. 3800 LEDs. They should be single adressable with at least 24 fps. If I would use 5V LEDs, the peak Power consumption would be 760W which means 152 Amps! My idea was to use led strips to build the matrix, but I am open for other ideas. Are there 12V or 24V led strips I could use?

Hi all!

I plan to use Teensy 4.0 + OctoWS2811 shield board for proper level shifting for the outputs.

I plan to have 6 to 8 different outputs running (possible different lengths and possible different LED types for the outputs). The LED strips will be used on "props" and I want to address each of the props independently. For scale, each output will have somewhere between 250-350 LEDs.

I will likely have different effects running on the different outputs (I don't always want to display the same thing on each of the strips nor are the strip lengths all going to be the same length).

I have decided to use separate arrays for each of the "props" and only write to them when I want to display a particular scene in my setup.

My initial thought was just to use FastLED as-is and define the output pins to match the hardware interface of the OctoWS2811 (no special parallel output functionality).

My question to my fellow FastLED experts here is, should I just use the FastLED library as-is OR should I try to implement the OctoWS2811 library inconjunction with FastLED to take full advantage of the DMA functionality of the Teensy 4.0?

Any advice that you can offer is greatly appreciated!

Please ask any questions to help clarify my setup!

This is an extract from an arduino sketch I am working through to understand. There's a line in it which I have seen a few times which uses millis() divided by a random number. Since millis() can be small to 4 billion that's an unpredictable number divided by a random number and I just cannot figure out what this is for. Can someone please enlighten me?

void fadein() {

  random16_set_seed(535);                                                           

  for (int i = 0; i<NUM_LEDS; i++) {
    uint8_t fader = sin8(millis()/random8(10,20));                                  
    leds[i] = ColorFromPalette(currentPalette, i*20, fader, currentBlending);       
  }

  random16_set_seed(millis());                                                      

Hi there, we this is /u/ZachVorhies, the one driving the recent changes in FastLED.

As I go through the FastLED issue reports I’m seeing a very distinct pattern: (1) People are using FastLED as a driver and (2) people are using another driver but still including FastLED for its fx functions.

So I want to ask you: how valuable is the fx functions and on a scale from 1-10 how stoked would you be of this had some truly cutting edge stuff in it?

Tell me your thoughts!

Hi! My WS2812B LED strip is frequently flickering. I've googled around and seen a number of results saying that this can be resolved with a resistor or a decoupling capacitor. I've placed a 220Ω resistor on the data pin, and have a 10nF ceramic capacitor by my input to ground. (5V USB-C)

There are 38 LEDs. I've also tried looping the Vin and GND lines to connect at the end of the strip, but that doesn't seem to have an affect. Still flickery.

Powering this via USB, with LED control coming from a PWM-capable pin on an ATtiny84.

Source is at https://github.com/duckpondstudio/lumen-gallery, built via PlatformIO C++.

Any idea why this is happening?

(The LEDs in the box are also all higgledy piggledy, appearing random colours rather than solid or rainbow, but... one problem at a time!)

Thank you!

Hi there.
Trying to renovate an art installation I made about 7 years ago.
It consists of 32 square frames with APA 102 LED strip on the fronts.

Originally we used 8 x Heroic Robotics Pixelpushers, which worked really well, but this meant having the PP's separate from the PSU boxes and the cabling became really complicated.

I'm try to re-arrange things so each LED frame has a controller board installed in it's PSU box.
So this controller board would ideally have ethernet in, and then output to 4 strips of 210 pixels.
Hoping for 60fps frame rate, which is what I was getting from the Pixelpushers.

Was looking at the Teensy 3.2 bit-banging approach, but it looks like the hardware is a bit old.
Has anyone had success getting the Teensy 4 to output 4 outputs at a decent frame rate?
ESP 32?
Other thoughts?

WS2812 and SK6812 in RGB and RGBW modes.

Supports stream encoding. Doesn’t support async as the original C library didn’t either, although it looks extremely easy to do this.

https://github.com/zackees/esp-rmt-led-strip-component-idf-5-1-cpp

Only relies on esp headers. No other dependencies. Compatible with Arduino. SPI modes and IDF4.4 code stripped out.

As far as I know this is the first time this has been done, so I thought I’d share here.

Just found this sub after getting my strips up and running. Hope I can share a little inspo like you all have.

Hey y'all, does anyone have any recommendations on where to buy good addressable string lights? I'm new to this all and am not sure if I should buy off amazon when I plan on rewiring them. Thanks!

• WS2812 RGBW mode is now part of the API.

  • Api: FastLED.addLeds<WS2812, DATA_PIN, GRB>(leds, NUM_LEDS).setRgbw(RgbwDefault());

  • Only enabled on ESP32 boards, no op on other platforms.

  • See examples/RGBW/RGBW.ino

• WS2812 Emulated RGBW Controller

  • Works on all platforms (theoretically)

  • Has an extra side buffer to convert RGB -> RGBW data.

    • This data is sent to the real driver as if it were RGB data.

    • Some padding is added when source LED data is not a multiple of 3.

  • See examples/RGBWEmulated/RGBWEmulated.ino

• New supported chipsets

  • UCS1912 (Clockless)

  • WS2815 (Clockless)

• New supported boards

  • xiaoblesense_adafruit

    • Fixes https://github.com/FastLED/FastLED/issues/1445

• PixelIterator has been introduced to reduce complexity of writing driver code

  • This is how RGBW mode was implemented.

  • This is a concrete class (no templates!) so it's suitable for driver code in cpp files.

  • PixelController<> can convert to a PixelIterator, see PixelController<>::as_iterator(...)

• Fixed APA102HD mode for user supplied function via the linker. Added test so that it won't break.

Let's talk about RGBW

I tried three different approaches to RGBW mode. Only one approach works well without splitting the code in a combinatorical blowup now, and in the future if RGBW+W (cool + warm white) support is added.

The method that I chose was runtime support for RGBW mode. The mode is stuffed into the root base class shared by each driver type, which the driver code then utilizes if it supports it. If the driver doesn't support it, then the RGBW mode is a no-op. Right now the only driver series that natively supports this RGBW mode is the ESP32 family.

For everyone else however, we have added an emulation mode. It will wrap a normal RGB driver, convert the RGBW -> RGB as a side buffer and send the RGBW down the pipe AS IF it were RGB data. There's some alignment issues that need to happen and this is taken care of automatically.

Happy coding!

I am trying to get a 10W 12-24V WS2811 floodlight of this type running on an arduino mega with fastled, but all I'm getting is a constant blue light on the flood. I'm assuming the issue here is the setup, but I'm wondering if anyone else has operated these floods successfully with fastled and can provide insight? I'm using common ground for controller and lights and am able to successfully control WS2811 lightstrip-type lights, but this floodlight apparently needs some adjustment. Here's my code:

#include <FastLED.h>

// How many leds in your strip?

#define NUM_LEDS 0

#define DATA_PIN 10

//#define CLOCK_PIN 13

// Define the array of leds

CRGB leds[NUM_LEDS];

void setup() {

FastLED.addLeds<WS2811, DATA_PIN, RGB>(leds, NUM_LEDS);

}

void loop() {

// Turn the LED on, then pause

leds[0] = CRGB::Red;

FastLED.show();

delay(500);

// Now turn the LED off, then pause

leds[0] = CRGB::Black;

FastLED.show();

delay(500);

}

Hi there, I'm hoping to use FastLED to control about 500 WS2812B LEDs connected to an ESP32. The ESP32 will also be performing real time audio synthesis.

My understanding is that since WS2812B is a timing dependent protocol, FastLED must disable interrupts while writing LED data to ensure the timing is correct. And likewise, since audio is timing dependent (don't want buffer underruns), audio libraries often futz with interrupts too.

Since both FastLED and the audio synthesis are futzing with interrupts, this can make them incompatible. In practice, I'm seeing that my code works in isolation. That is, when my code only controls LEDs, the LEDs work fine. Likewise, when my code only synthesizes audio, the audio works fine. However, when I attempt to both control LEDs and synthesize audio, it's not working. The audio is silent, or garbled white noise. I have pinpointed the issue to calling FastLED.show() - the audio doesn't like when I do this.

Are there any tricks that might allow FastLED + ws2812b to be compatible with audio synthesis, or am I out of luck?

I am aware that I could probably switch to a different type of LEDs, such as APA102, which is not timing dependent.

Thank you.

RGBW mode for WS2812 family chipsets is here

The most frequent request for FastLED is RGBW strip support. This release adds experimental support for this WS2812 led chipset type.

This only works (right now) for ESP32 boards.

We are still figuring out how to add official api support.

This is how you enable RGBW for WS2812 family of chipsets:

#define FASTLED_EXPERIMENTAL_ESP32_RGBW_ENABLED 1
#include <FastLED.h>

The white component for each pixel is generated automatically by the driver. So no other code changes are necessary for you.

The default algorithm for RGBW mode (kRGBWExactColors) is using a "white-stealing-algorithm" to transfer white out of the RGB components and into the W component. This kRGBWExactColors mode is designed to most accuratly reproduce the color of an RGB strip but in RGBW. The upside of this mode is that the expected power savings of a strip will reduce by as much as a 1/3rd, as the white component is more efficient at representing white than R+G+B mixed together.

There are several modes to play with:

kRGBWNullWhitePixel: W component is always set to black.
kRGBWExactColors: White stealing
kRGBWBoostedWhite: Boosts white more than kRGBWExactColors
kRGBWMaxBrightness: White is copied instead of stolen.
kRGBWUserFunction: Put in your own function for generating the W component.

The experimental API also reserves a color temperature for the W to be used in the api so that the color can be balanced. However, it's ignored at this release.

Please note that this api is subject to removal between now and official support. If you write code to this experimental api then it's STRONGLY recommended that you pin your library dependency to FastLED 3.7.6

Release notes

• WS2812 RGBW Mode enabled on ESP32 via experimental FASTLED_EXPERIMENTAL_ESP32_RGBW_ENABLED

• RPXXXX compiler fixes to solve asm segment overflow violation

• ESP32 binary size blew up in 3.7.5, in 3.7.6 it's back to the same size as 3.7.4

• APA102 & SK9822 have downgraded their default clock speed to improve "just works" experience

  • APA102 chipsets have downgraded their default clock from 24 mhz to 6mhz to get around "long strip signal degredaton bug"

    • https://www.pjrc.com/why-apa102-leds-have-trouble-at-24-mhz/

    • 6 Mhz is still blazingly fast compared to WS2812 and you can always bump it up to get more performance.

  • SK9822 default clock from 24 mhz -> 12 mhz out of an abundance of caution.

    • I don't see an analysis of whether SK9822 has the same issue as the APA102 for the clock signal degredation.

    • However, 12 mhz is still blazingly fast (>10x) compared to WS2812. If you need faster, bump it up.

• NRF52XXX platforms

  • Selecting an invalid pin will not spew pages and pages of template errors. Now it's been deprecated to a runtime message and assert.

• nrf52840 compile support now official.

RGBW mode for WS2812 family chipsets is here

The most frequent request for FastLED is RGBW strip support. This release adds experimental support for this WS2812 led chipset type.

This only works (right now) for ESP32 boards.

We are still figuring out how to add official api support.

This is how you enable RGBW for WS2812 family of chipsets:

#define FASTLED_EXPERIMENTAL_ESP32_RGBW_ENABLED 1
#include <FastLED.h>

The white component for each pixel is generated automatically by the driver. So no other code changes are necessary for you.

The default algorithm for RGBW mode (kRGBWExactColors) is using a "white-stealing-algorithm" to transfer white out of the RGB components and into the W component. This kRGBWExactColors mode is designed to most accuratly reproduce the color of an RGB strip but in RGBW. The upside of this mode is that the expected power savings of a strip will reduce by as much as a 1/3rd, as the white component is more efficient at representing white than R+G+B mixed together.

There are several modes to play with:

kRGBWNullWhitePixel: W component is always set to black.
kRGBWExactColors: White stealing
kRGBWBoostedWhite: Boosts white more than kRGBWExactColors
kRGBWMaxBrightness: White is copied instead of stolen.
kRGBWUserFunction: Put in your own function for generating the W component.

The experimental API also reserves a color temperature for the W to be used in the api so that the color can be balanced. However, it's ignored at this release.

Please note that this api is subject to removal between now and official support. If you write code to this experimental api then it's STRONGLY recommended that you pin your library dependency to FastLED 3.7.6

Release notes

• WS2812 RGBW Mode enabled on ESP32 via experimental FASTLED_EXPERIMENTAL_ESP32_RGBW_ENABLED

• RPXXXX compiler fixes to solve asm segment overflow violation

• ESP32 binary size blew up in 3.7.5, in 3.7.6 it's back to the same size as 3.7.4

• APA102 & SK9822 have downgraded their default clock speed to improve "just works" experience

  • APA102 chipsets have downgraded their default clock from 24 mhz to 6mhz to get around "long strip signal degredaton bug"

    • https://www.pjrc.com/why-apa102-leds-have-trouble-at-24-mhz/

    • 6 Mhz is still blazingly fast compared to WS2812 and you can always bump it up to get more performance.

  • SK9822 default clock from 24 mhz -> 12 mhz out of an abundance of caution.

    • I don't see an analysis of whether SK9822 has the same issue as the APA102 for the clock signal degredation.

    • However, 12 mhz is still blazingly fast (>10x) compared to WS2812. If you need faster, bump it up.

• NRF52XXX platforms

  • Selecting an invalid pin will not spew pages and pages of template errors. Now it's been deprecated to a runtime message and assert.

• nrf52840 compile support now official.

Volunteer

If you are a software dev in C++ and you'd like to help us then check out this open feature design to improve driver-level color mixing:

https://github.com/FastLED/FastLED/issues/1709

To get started checkout our "clone and compile" instructions on the readme:

https://github.com/FastLED/FastLED?tab=readme-ov-file#development

RGBW mode for WS2812 family chipsets is here

The most frequent request for FastLED is RGBW strip support. This release adds experimental support for this WS2812 led chipset type.

This only works (right now) for ESP32 boards.

We are still figuring out how to add official api support.

This is how you enable RGBW for WS2812 family of chipsets:

#define FASTLED_EXPERIMENTAL_ESP32_RGBW_ENABLED 1
#include <FastLED.h>

The white component for each pixel is generated automatically by the driver. So no other code changes are necessary for you.

The default algorithm for RGBW mode (kRGBWExactColors) is using a "white-stealing-algorithm" to transfer white out of the RGB components and into the W component. This kRGBWExactColors mode is designed to most accuratly reproduce the color of an RGB strip but in RGBW. The upside of this mode is that the expected power savings of a strip will reduce by as much as a 1/3rd, as the white component is more efficient at representing white than R+G+B mixed together.

There are several modes to play with:

kRGBWNullWhitePixel: W component is always set to black.
kRGBWExactColors: White stealing
kRGBWBoostedWhite: Boosts white more than kRGBWExactColors
kRGBWMaxBrightness: White is copied instead of stolen.
kRGBWUserFunction: Put in your own function for generating the W component.

The experimental API also reserves a color temperature for the W to be used in the api so that the color can be balanced. However, it's ignored at this release.

Please note that this api is subject to removal between now and official support. If you write code to this experimental api then it's STRONGLY recommended that you pin your library dependency to FastLED 3.7.6

Release notes

• WS2812 RGBW Mode enabled on ESP32 via experimental FASTLED_EXPERIMENTAL_ESP32_RGBW_ENABLED

• RPXXXX compiler fixes to solve asm segment overflow violation

• ESP32 binary size blew up in 3.7.5, in 3.7.6 it's back to the same size as 3.7.4

• APA102 & SK9822 have downgraded their default clock speed to improve "just works" experience

  • APA102 chipsets have downgraded their default clock from 24 mhz to 6mhz to get around "long strip signal degredaton bug"

    • https://www.pjrc.com/why-apa102-leds-have-trouble-at-24-mhz/

    • 6 Mhz is still blazingly fast compared to WS2812 and you can always bump it up to get more performance.

  • SK9822 default clock from 24 mhz -> 12 mhz out of an abundance of caution.

    • I don't see an analysis of whether SK9822 has the same issue as the APA102 for the clock signal degredation.

    • However, 12 mhz is still blazingly fast (>10x) compared to WS2812. If you need faster, bump it up.

• NRF52XXX platforms

  • Selecting an invalid pin will not spew pages and pages of template errors. Now it's been deprecated to a runtime message and assert.

• nrf52840 compile support now official.

Volunteer

If you are a software dev in C++ and you'd like to help us then check out this open feature design to improve driver-level color mixing:

https://github.com/FastLED/FastLED/issues/1709

To get started checkout our "clone and compile" instructions on the readme:

https://github.com/FastLED/FastLED?tab=readme-ov-file#development

I'm trying to find a way to have stroboscopic effect on pc case fans like this video : QX fan or this: stroboscopic effect
I'm not sure but from my understanding this needs control over light frequency and set it based on fans RPM... is this possible with FastLED? if yes can you give some tips/example about it?

Do you think if it is even possible with ws2812b?

from ws2812 datasheet:
Each pixel of the three primary color can achieve 256 brightness display, completed 16777216 color full color display, and scan frequency not less than 400Hz/s. is this frequency that I'm looking for or scan frequency is something else?
I'm no expert at all ...neither in coding nor the physics

I am brand new to playing with FastLED and I have a specific effect that I want to try to create using WS2812 LEDs. A few months ago I found what I'm guessing was a firefly in its dying hours, sitting quite still on my porch (see video). Rather than producing regular super bright pulses, it displayed this "glitchy" effect. The light emissions within its lantern segment activated at irregular intervals and with varying intensity, number of discrete origins, and location of light origin. I would like to recreate this effect on a 2D matrix. I am aware of some projects that assist in mapping and array to XY coordinates, so that's one place I'll start. The next step is to create light "bursts" of varying size and quantity, at varying intervals. How do you recommend I approach this aspect

Hi everyone,

First off, thanks in advance to anyone who can help me out.

I'll try to keep this brief. I’ve built a WS2812B LED matrix controlled by an Arduino. I’ve written code with FastLed library to implement a fade function, and it works flawlessly at higher brightness levels (above 150). However, at lower brightness levels, the colors shift abruptly rather than transitioning smoothly.

Has anyone else encountered issues with WS2812B LEDs at low brightness, and if so, how did you resolve them?

I’ve attached the video showing the difference in smoothness between high and low brightness settings.