Repository navigation
LED data corruption with RMT driver #4389
Description
Activity
GPIO 1 & 16 will use RMT. RMT is susceptible to flickering in some circumstances.
0.15 added a lot of code that may make those circumstances more frequent.GPIO 3 uses I2S.
If you want to test (and help with resolving) set up more than 4 outputs with less than 300 pixels each and report.
I encountered the same issue after upgrading to 0.15.0. There are 182 LEDs on GPIO 16, which are set to a solid orange-ish RGB[115,74,0] color. It's not apparent on solid white. I have a couple of dig2analog on GPIO 3, but I did not test whether the issue is also there. After downgrading to 0.14.3, the random flickering (every 30-60 seconds) issue is gone.
Periodic issue leads me to believe this may be network related.
Reacted by designgearsSame issue from me and similar setup as original reporter
If needed I can build a quick test setup and can troubleshoot on Discord too, apologies this made it through the beta somehow, I had not noticed in on any testing setups I had before. Let me know if you need anything!
Reacted by Kyle WIlliams and designgearsPlease test a set-up with at least 6 outputs (WS281x). You do not need to have actual LEDs connected or GPIOs attached. It is important to have GPIO 1, 3 & 16 as first 3 outputs and each output must not exceed 300 LEDs
Reacted by Kyle WIlliamsI had exactly the same problem on my digquad pushing 824 seedpixels per channel.
Went back to 14.3 and all was good
Same issues with the Quad and 12V WS2815 on version 0.15 : heavy noises and flickering with effects such as Dancing Shadows.
GPIO 3 - 152 LEDs (60/m)
GPIO 16 - 356 LEDs (144/m)
GPIO 15 - RelayI have a 5V PS for the relay and the Quad board and 12V for the LEDS through the board.
And I was not able to use the relay (GPIO 15) since it was taken by the I2S audio interface.
I have 2 GLEDOPTO GL-C-015WL-M controllers that have no issues with the 0.15 release. I went back to 0.14.3 for now, was scared to damage the LEDs
I ran into what this sounds like with one of my digunos. I'm currently running 3 digunos and one digquad, but only saw this on one diguno and was able to fix it by swapping the esp from a spare diguno.
A detail that I noticed was unique on that instance was that I had the output order switched around so that the first output was mapped in wled as gpio 3 and the second to gpio 16 instead of the other way around, for whatever reason.
I imagine swapping the esp worked in my case only because that one had the outputs orders as gpio 16 then 3.
I'm dealing with this same issue, except it's on a single ESP32. There are 260 LEDs in this configuration, all of which are in GPIO 16.
it's only the last section where I'm adding power back in after a split and it's after that point that the LEDs are misfiring. I've posted video of it flashing blue and red after a few minutes in the discord channel. It was working fine in 14.4. I'm not sure if I'm sending too much power and the additional power is fucking with it or something. Let me know if there's anything you need me to do.
Reacted by Kyle WIlliamswith 6 outputs or more, 1st 8 are using I2S (parallel) with 5 or less, 1st is using I2S (single) and 4 are using RMT. may notify @Makuna if he has any clue what's different in NPB 2.8.0 compared to 2.7.4 in 0.14.4 regarding RMT
The only real change with RMT between those versions is the ability to compile using IDF5. This was just some minor headers include changes to react to the IDF change but still outputs warnings about deprecated API use.
Did you turn on ESP32 core debug errors/warnings/info level to see if anything shows up in the debug output?Reacted by Blaž Kristan70 remaining items
- Great news!…On Sun, Aug 3, 2025 at 2:21 PM intermittech ***@***.***> wrote: *intermittech* left a comment (wled/WLED#4389) <#4389 (comment)> Just to chime in, I've been testing a build provided by @willmmiles <https://github.com/willmmiles> that has the RMT bug fix on top of WLED v0.15.1 and that's been working excellent for me on a QuinLED Dig-Quad! So there are 2 fixes available then, using Parallel I2S (which has some limitations) and "fixed RMT" which works well for me and allows mixing of LED types over various channels and such again (I setup a test with 2x 300 ws2812b, 1x 300 sk6812 and 1x ws2812 500 LEDs) and all flickering is gone (in any GPIO order)! So a fix is close to this issue and then everyone can upgrade to v0.15.1 without worry! — Reply to this email directly, view it on GitHub <#4389 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJQ3NWLVPECXS5JYK4SWA5T3LZOLZAVCNFSM6AAAAABTSNATPSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCNBYGY2DMNJQGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>
- marked Data corruption when enabling multiple channels #4922 as a duplicate of this issue
on Sep 12, 2025 For people who want to test the RMT High Priority Interrupt Driver, it's integrated into the recently released WLED v0.15.2-beta1! The WLED github doesn't have pre-compiled binaries right now it seems but we have made some for the QuinLED boards (or generic, the binaries are just pre-configured) if you want to give it a try!
Reacted by eMeF1For people who want to test the RMT High Priority Interrupt Driver, it's integrated into the recently released WLED v0.15.2-beta1! The WLED github doesn't have pre-compiled binaries right now it seems but we have made some for the QuinLED boards (or generic, the binaries are just pre-configured) if you want to give it a try!
I went from 13 to latest beta release and immediately had the flickering. Checked everything before googling and arriving here. I also tried precompiled binaries from you, but it's the same thing with the flickering.
Note, I also tried 33ohms switches.For people who want to test the RMT High Priority Interrupt Driver, it's integrated into the recently released WLED v0.15.2-beta1! The WLED github doesn't have pre-compiled binaries right now it seems but we have made some for the QuinLED boards (or generic, the binaries are just pre-configured) if you want to give it a try!
I went from 13 to latest beta release and immediately had the flickering. Checked everything before googling and arriving here. I also tried precompiled binaries from you, but it's the same thing with the flickering. Note, I also tried 33ohms switches.
Have you tried with I2S parallel too?
For people who want to test the RMT High Priority Interrupt Driver, it's integrated into the recently released WLED v0.15.2-beta1! The WLED github doesn't have pre-compiled binaries right now it seems but we have made some for the QuinLED boards (or generic, the binaries are just pre-configured) if you want to give it a try!
I went from 13 to latest beta release and immediately had the flickering. Checked everything before googling and arriving here. I also tried precompiled binaries from you, but it's the same thing with the flickering. Note, I also tried 33ohms switches.
Have you tried with I2S parallel too?
I use pin 16, 3 and 4 in that order.
Each pin consists of 384 leds.
And I use the audiomicrophone as well.
The dig-quad is behind a barrier and for me to get in there to change physical pins is not something I'd rather do unless this is the only solution.
As of now, 14.3 works fine so I'll keep it until issue is resolved by all you smart people :)Reacted by ThorstenI reassigned the I2S pins according to this reddit comment and it worked: https://www.reddit.com/r/WLED/comments/1hbsc2u/comment/m1r64cz/
I2S SD to port 17, I2S WS to ports 32 and I2S SCK to port 33
For people who want to test the RMT High Priority Interrupt Driver, it's integrated into the recently released WLED v0.15.2-beta1! The WLED github doesn't have pre-compiled binaries right now it seems but we have made some for the QuinLED boards (or generic, the binaries are just pre-configured) if you want to give it a try!
I went from 13 to latest beta release and immediately had the flickering. Checked everything before googling and arriving here. I also tried precompiled binaries from you, but it's the same thing with the flickering. Note, I also tried 33ohms switches.
Have you tried with I2S parallel too?
I use pin 16, 3 and 4 in that order. Each pin consists of 384 leds. And I use the audiomicrophone as well. The dig-quad is behind a barrier and for me to get in there to change physical pins is not something I'd rather do unless this is the only solution. As of now, 14.3 works fine so I'll keep it until issue is resolved by all you smart people :)
Actually something you could try is changing that order, make GPIO16 not the first in the list, it would be interesting to see what that changes, if you are up for a bit of experimenting!
For people who want to test the RMT High Priority Interrupt Driver, it's integrated into the recently released WLED v0.15.2-beta1! The WLED github doesn't have pre-compiled binaries right now it seems but we have made some for the QuinLED boards (or generic, the binaries are just pre-configured) if you want to give it a try!
I went from 13 to latest beta release and immediately had the flickering. Checked everything before googling and arriving here. I also tried precompiled binaries from you, but it's the same thing with the flickering. Note, I also tried 33ohms switches.
Have you tried with I2S parallel too?
I use pin 16, 3 and 4 in that order. Each pin consists of 384 leds. And I use the audiomicrophone as well. The dig-quad is behind a barrier and for me to get in there to change physical pins is not something I'd rather do unless this is the only solution. As of now, 14.3 works fine so I'll keep it until issue is resolved by all you smart people :)
Actually something you could try is changing that order, make GPIO16 not the first in the list, it would be interesting to see what that changes, if you are up for a bit of experimenting!
That's the least thing I can do!
I changed and set the order with 16 being in second or third "place". Unfortunately still issues.
Downgraded again.For people who want to test the RMT High Priority Interrupt Driver, it's integrated into the recently released WLED v0.15.2-beta1! The WLED github doesn't have pre-compiled binaries right now it seems but we have made some for the QuinLED boards (or generic, the binaries are just pre-configured) if you want to give it a try!
I went from 13 to latest beta release and immediately had the flickering. Checked everything before googling and arriving here. I also tried precompiled binaries from you, but it's the same thing with the flickering. Note, I also tried 33ohms switches.
Have you tried with I2S parallel too?
I use pin 16, 3 and 4 in that order. Each pin consists of 384 leds. And I use the audiomicrophone as well. The dig-quad is behind a barrier and for me to get in there to change physical pins is not something I'd rather do unless this is the only solution. As of now, 14.3 works fine so I'll keep it until issue is resolved by all you smart people :)
Actually something you could try is changing that order, make GPIO16 not the first in the list, it would be interesting to see what that changes, if you are up for a bit of experimenting!
That's the least thing I can do! I changed and set the order with 16 being in second or third "place". Unfortunately still issues. Downgraded again.
Interesting, this seems to be a different kind of bug/issue then since before that would resolve or at least move the issue. Hmm...
Still experiencing this issue on 0.15.3 with a specific configuration:
Hardware: QuinLED Dig-Uno (ESP32) with WS2812B 100-LED fairy lights
Configuration that causes flicker:Single output on GPIO 16
Integrated with Home Assistant (WLED integration) and LedFX (UDP)
Flicker appears as random multicolored pixels, even on solid color presetsWhat I've ruled out:
Not hardware — tested multiple power supplies, re-wired connections
Not the GPIO pin itself — same flicker follows when switching to GPIO 3 as sole output
Not the presets JSON — deleted all presets, flicker persistsWorkaround that works:
Adding a dummy output as output 1 (GPIO 16: Length 1, Skip 1) eliminates the flicker entirely on output 2.
With two outputs configured, the actual LEDs on GPIO 3 work perfectlyKey observation:
The flicker only occurs when using a single output configuration (and possibly combined with external integrations (HA polling + LedFX UDP streaming)). Adding any second output — even a dummy one — resolves it completely.
This suggests the RMT/I2S driver selection or buffer handling behaves differently with single vs. multiple outputs, and the single-output path still has issues under network load.This comment was drafted with assistance from Claude AI, with human oversight and review.
@Jivemofo this is not related to this issue, the first output uses I2S which is not influenced by network traffic. What this does show however is the core of most if not all reported flickering issues with 0.15.3 and 0.16: the timings of I2S and RMT are not identical. While both are well within specification of most LEDs, adding cables and a whole bag of LED revisions, manufacturers and production tolerances can make I2S or RMT a better timing choice, fully depending on the specific setup. This is an unsolvable issue without adding more bus types with different timing options. What those options should be is still not entirely clear to me as there are just too many contradicting reports. I may just take a stab at it at random.
Reacted by Jivemofo
What happened?
After upgrading a QuinLED-Dig-Quad to WLED 0.15.0, LED segments on GPIOs 1 and 16 experience significant noise and flashing. An LED segment on GPIO 3 operates fine without any issue.
Segment 1 GPIO 3 - 629 LEDs
Segment 2 GPIO 1 - 161 LEDs
Segment 3 GPIO 16 - 171 LEDs
This particular setup has been running flawlessly for just over 3 years. The issue was immediately resolved by downgrading to WLED 0.14.3.
To Reproduce Bug
Expected Behavior
Install Method
Binary from WLED.me
What version of WLED?
WLED 0.15.0 2412100
Which microcontroller/board are you seeing the problem on?
ESP32
Relevant log/trace output
I don't have any logs at the moment, I have since downgraded to WLED 0.14.3. However, I would be more than happy to re-upgrade and capture any logs/traces/configs that would aid in troubleshooting.Anything else?
This appears to be similar to report #3976. That was submitted for 0.15.0b2 and not the full release however.
Code of Conduct