Aircoookie
LED data corruption with RMT driver
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
- Upgrade a QuinLED-Dig-Quad to WLED 0.15.0
- Activate any preset or animation
- Flashing/Noise is prominent on LED segments on GPIO 1 and 16
Expected Behavior
- No noise/flashing on any LED segment
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
- [X] I agree to follow this project's Code of Conduct
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.
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!
Please 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
I 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 - Relay
I 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
with 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
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.
FWIIW I'm using Dig-Quad with 16 (465), 1 (270), 3 (15) - in that order - with no flickering whatsoever. Using generic ESP32 in Wemos D1 Mini size packaging from aliexpress.
EDIT: If anyone wants to test, here is my build with newer NPB 2.8.3.
with 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?
I'm also having this issue with a set up I am testing. Let me know if you want me to test any bins. Working in 14.4 but not 15.0.
My outputs pins are (33,17,5,2,4,12,14,15) with 300 pixels per output using WT32-ETH01 esp32
Hey there, I have the same problem on my 3 PWM strips. When I cut the transitiontime it is gone - with transition it flashes when turning on before dimming up and when turning off while dimming down a flash and dimming further down.
I added a small video of the current situation. https://github.com/user-attachments/assets/f6009672-1853-451c-b2fd-f404a0fe5acc
Hi All,
I have the same problem in my Chrismas tree. This is a Quinled Dig uno v3 like this: https://shop.allnetchina.cn/products/quinled-dig-uno-v3r7-digital-led-controller
It feeds 2 strings starting from the middle and string 1 is the upper one and 2 is the lower one. Using the latest v14.4 I have zero problem, upgrading to v15 gives the first 20 leds a noicelike color and keep flikkering, even in solid mode, but faster when an effect is activated.
Output 1 is using gpio 1, and also tried 16, both same flickering. Output 2 uses gpio 3, close to 0 problems.
Limiting the brightness seems to help, but this is brightness at 10% and problems still are like 50% more or less.
V14.4:
V15:
With effect: https://github.com/user-attachments/assets/ef06e29d-556d-4a89-9d80-b0d910aa616f
Solid color: https://github.com/user-attachments/assets/e6309d58-4a9c-48f4-b7d0-670ef472287c
If anyone needs more info, ask ;-)
Hope this helps, Wouter
same problem here. using 699 LED's on an AZDelivery ESP32 on GPIO 16. LED's are usually dimmed to about 10% on a solid color, after the update i get basically random color flashing everywhere.
By dimming the Power above about 50% the random color flashing stops but there is still some flickering everywhere (at least in the right color)
sadly a downgrade seems not to work because after that the ESP seems to crash after a few minutes.
I also have this issue, asked about it on the Quinled discord and they said to check here.
I was thinking of using ESP32-WROOM-32U pins 2, 4, 12, 16.
If I understand correctly, ESP32 has a library called "RMT" which is for controlling LEDs.
Is that library only being used with certain output pins, or certain combinations? Seems like WLED uses different techniques for generating the LED data signals depending on which output pins are being used.
Unfortunately it's not fully clear to me if my pin choices will be affected by this situation. Is 16 the only affected pin in my list?
Either way, it seems like it would be solvable by offering a per-GPIO-output "compatibility fallback" checkbox which tells WLED to use the old data output method instead of the faster but flickery "RMT" method. Or, figuring out why the RMT library flickers and whether it's solvable (but I guess that would be fixed long ago if it was something easy).
ESP32 has a GPIO muxer. Any pin can be anything: PWM, I2S, I2C, RMT etc. BTW RMT is not a library. It is a DMA HW driver.
Same issue here. Recent model dig-Quad running two strands of 12V BTF WS2814 (128 and 169 logical LEDs). LED data pins 1, 3, and 4 (GPIO 16, 1, and 4 respectively) all flicker badly on 0.15.0. Moving the data pins around and swapping strips in and out shows that the issue is coming from the controller itself and not the LEDs or my wiring.
0.14.4 Audioreactive works very cleanly on all outputs.
Is this issue explained yet, if not fixed in 0.15.1 RCs?
I believe it's fixed in v0.15.1-beta2, could you give that one a try @MakerMatrix ?
@MakerMatrix yes it was explained (elsewhere). GPIO don't matter but number of LEDs do. If you use more than 300 LEDs per output, WLED will use RMT peripheral for output instead of I2S (behaviour from 0.14).
No. That's for currently released 0.15.0, for 0.15.1 you'll need to check the changelog. To overcome the issue on 0.15.0 set last output to contain more than 300 LEDs. This will force 0.14 behaviour.
@MakerMatrix yes it was explained (elsewhere). GPIO don't matter but number of LEDs do. If you use more than 300 LEDs per output, WLED will use RMT peripheral for output instead of I2S (behaviour from 0.14).
300 logical LEDs or 300 physical? My longest strip has 169 pixels/507 leds.
I'll give -beta2 a try and report back.
I am sorry to report that 0.15.1-beta2 does not fix the problem I am hitting. The "blends" effect makes the flickering most readily and immediately apparent.
OK I see it in the changelog for 0.16-alpha (the nightly build) so let's get that mentioned in here too.
WS281x leds flickering every firmware after WLED 0.15.0-b3 https://github.com/wled/WLED/issues/4211