I'm using an esp32 which three strips of ws2821b strips,

Archive FastLED Archive
,
1

I’m using an esp32 which three strips of ws2821b strips, with 147 on one strip, 183 on the next and finally 220 on the last one. Since the WiFi causes flickering, and adding #define FASTLED_ALLOW_INTERRUPTS 0 made it far worse, I thought that shutting down the WiFi would help.

So I wrote a simple sketch to make sure that would work, without any FastLED stuff.

void loop()
{
if (millis() % 15000 == 0){
if (WiFi.isConnected()){
Serial.println(“Disconnectin…”);
WiFi.disconnect();
}
else{
connectWiFi();
}
}
}

Doing exactly the same thing but running a strip with FastLED caused the esp32 to crash.

Am I correct that the timing of the FastLED might potentially conflict with the WiFi? Is there a workaround for this?

2

Tried this example sketch? Works fine for me: https://github.com/FastLED/FastLED/blob/master/examples/DemoReelESP32/DemoReelESP32.ino

And I’ve been using the ESP32 a lot lately, I’m usually able to get it running fairly stable without flickering: https://github.com/jasoncoon/esp32-fastled-webserver

I’ve been dialing back the FPS to 60 with calls to delay(1000 / FRAMES_PER_SECOND); instead of FastLED.delay(1000 / FRAMES_PER_SECOND); seems to help immensely.

3

Have you been using WiFi as well? Also, I want to avoid any delay() calls altogether if possible. No idea if that’s a good or bad thing.

4

You should also make sure you have the most recent version of the library, as it’s using the RMT device on the esp32 and so doesn’t disable interrupts anymore.

5

@Dani_Epstein yes, I’ve been using WiFi. Calls to delay on the ESP32 actually internally just yield to the system for handling WiFi etc. It actually seems to perform better than calling FastLED.delay.

6

That’s because FastLED.delay is continually pushing out frames to drive dithering - which means while it will be calling yield to let wifi do things, it won’t be doing it anywhere near as frequently as the regular delay would.

7

/subscribe :slight_smile:

8

Totally awesome stuff. I have an issue with the most recent issue of FastLED which I have noted here in another post, so I’m waiting with baited breath. In the meanwhile I’m going to see what happens when I replace EVERY_N_MILLISECONDS with delays instead.

9

@Dani_Epstein I wouldn’t replace every_n_millis with delays, just replace FastLED.delay with delay, and only if you’re not using dithering.

10

@Jason_Coon this worked for me
delay(1000 / FRAMES_PER_SECOND); instead of FastLED.delay(1000 / FRAMES_PER_SECOND);