-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
SK6812 RGBW colors broken in 0.15.0 on ESP32, not ESP8266, works in 0.14.4 #4380
Comments
Try checking the brightness limiter settings. Also, if you can, please post the config from your 0.14 system; it sounds like there's either (a) a bug in the upgrade path, or (b) a setting that was previously ignored is now being correctly applied; I'd like to poke the config and see if I can work out what it is. |
Will have a fiddle with the settings tomorrow The animation/effect seems to be working properly, its just the "color" thats wrong. Will try and be more descriptive tomorrow Config exported from 1.14.4:
|
And this is the config from the ESP8266 device which works on 0.14.4 and 0.15, just in case its a config issue rather than a hardware-specific bug
|
I was having a similar problem, but my esp8266s weren't changing colors and my esp32s were fine. Rolled back the 8266s to 0.14.4 and now color changing works. 0.15.0 also knocked a couple of my esp8266s offline and they had to be reflashed via serial, but that's a different issue. |
So, automatic brightness limiting had been turned on, turning that off solves it. However the effects wrt segments is screwy, like its sped up. Segment 1 is ok, but the rest are not I have a vid but cant post it here. Can DM/email |
It looks like the blue channel just doesn't work for me with 15.0. I rolled back to 14.4 and it's fine. |
0.15 now seems completely broken for me, and I can't roll back to 0.14.4. I provide the binary and seems to apply the update, but it doesnt. Will have to get the ladders out and flash it directly I guess |
I updated (OTA) 5x ESP8266 (d1 mini) with an almost identical SK6812 setup (except for the switch type). Here is the result:
|
Same for me. For SK6812 strips I cannot get any blue to show up. Not even when intentionally switching color order. Affected binary: WLED_0.15.0_ESP32_Ethernet.bin Upgrade performed via Home Assistant. |
@nomonkeynodeal @Deretour How many channels are you using? I think this is the same bug as reported in #4384 |
By freak coincidence, my PSU died of a faulty adjuster pot at exactly the same time. So 0.15 is not "completely broken" but the color/brightness and rollback issues are real |
Maybe. I am using four channels, but the white channel definitely worked for me. |
Sounds familiar indeed. Except for blue instead of white. But besides that it seems exactly the same issue. additional info: I‘m running a quinled dig octa. |
@Deretour try something. Delete a channel, any channel, so you have a max of 5 channels on your Octa. Do the other strips start behaving properly when there are only 5 channels? |
I‘ll definitely give that a try! |
OK, I couldn't wait. :) Gave it a try and it's exactly as expected: deleting one channel brings back blue for the remaining sk6812 channels. I hope the test result helps narrow down the issue and it can be resolved in an upcoming release as there are definitely features in 0.15 that I'm looking forward to. |
@Deretour that’s what I figured. This is def a bug. I’m looking into it now too but not seeing anything glaringly obvious… I’m sure @Aircoookie will have this knocked out soon. |
Additional note for completeness: |
From my limited understanding I'd assume a memory/buffer/array-size limitation. |
For anyone having issues with mixed LED types and multiple outputs (>5) please try the following:
Report back with detailed findings. (Reposting from #3484 and BTW @Aircoookie is taking a break from WLED as should I) |
@blazoncek thanks so much for looking into this. I can report that decreasing channel count to 5 or less and everything works perfectly. I haven’t tried increasing to 300+ on a channel. I’ll do that in a few hours and report back. |
@blazoncek I set one of the existing 5 channels to 301 LEDs and then added a 6th, 7th, and 8th channel. Everything is now working properly! I get all 4 colors and where behavior I previously reported is gone. I cannot tell you how much I appreciate your input. Can I test anything else for you to help further? |
@ijspear please reorder outputs so that 1st has SK6812. You should also reduce LED count below 300 on each output. |
@blazoncek actually all of my outputs are SK6812. Now that I have all 8 channels configured, when I reduce Channel 2 to the previous value (74) the behavior returns immediately when I click save. When I set channel 2 back to 301 things start behaving normally again. Thank you again! |
Now that's odd. In such case parallel I2S should work normally except if there is a bug in low level driver. |
If anyone can compile on their own, try replacing version number in |
@blazoncek i’ve never compiled on my own before but I’ll try to figure it out. Thanks for the suggestion! |
There are CI build artefacts of my fork here: https://github.com/blazoncek/WLED/actions/runs/12611034886 |
@blazoncek i know this is a super noob question - which file should I use for the digi-Octa? |
ESP32 as it is the only chip with issues. |
@blazoncek so esp32_eth would be the one to try? |
IDK, if you need Ethernet then yes. But for WiFi plain will do, |
Anyone facing this issue, if you have logic analyser please capture a frame on a 10 pixel output (solid color). |
as requested by @Makuna: I could not set distinct hex values so I set all four channels to about 80%. I set the first output to 1 pixel, the others to 10. With I2S parallel output, the white channel outputs zero: setting one of the outputs to 400LEDs to enforce RMT it looks correct (and white LED is on): |
Things of note, the color channels have different values even though they were set to the same (225, 223, 220)? Should be unrelated as the RMT shows the same values. What versions of NeoPixelBus are being used with working and no-working versions of WLED? I will investigate. |
@Makuna I set the color to "approximately" the same value, it was just a quick test early this morning. The take-away is: RGB output is the same for I2S and RMT, white is not. |
can confirm the behaviour is the same with NPB 2.8.3 |
@DedeHai just to clarify - using 2.8.3 can you add a 6th channel and make sure each channel is set to less than 300 pixels? |
@ijspear 2.8.3 with the (preliminary) implementation in WLED is still 5 channels max. |
Just for clarification: |
The big change was to move to the 3Step Cadence to save memory. It still supports 4Step Cadence, but it requires a compile time flag (NPB_CONF_4STEP_CADENCE). Does WLED use 4 or 3 step? |
@Makuna, @blazoncek When I try to use this exact configuration here is the behavior using the color wheel: When I change the pixel count to any of the channels (I chose ch2) to 300 or more, normal behavior is restored to all the strips. I also tried a version with NPB 2.8.3 and the behavior was exactly the same. |
@ijspear no need to explain, I am well aware where the issue lies. |
@blazoncek awesome! Sorry to be redundant. Super thankful to have folks like you as contributors to the project. Anything else I can help test to push the ball further? |
Anyone experiencig this issue (no white channel on SK6812 LEDs when using more than 5 outputs) please use the following workaround until this is fixed:
Any extraneous LEDs can be hidden by adjusting segment size. |
- Implement vector in bus manager - Memory calculation according to explanation from @Makuna - Prefer 8 RMT before 8 I2S on ESP32 (fixes Aircoookie#4380) - speed improvements in ABL - verbose debugging - get bus size from NPB (prototype) - Parallel I2S output bugfix - automatic selection of appropriate I2S bus (`X1xxxxxxMethod`) - removed I2S0 on ESP32 (used by AudioReactive) - renumbered internal bus numbers (iType) - added buffer size reporting
What happened?
I have two strips of SK6812s RGBWs, one lot attached to an ESP32 and one to an ESP8266
Updating to 0.15 from 0.14.4 breaks the ESP32 colors but not the ESP8266 colors
I've reverted to 0.14.4 so cant debug further at this moment but can do later
To Reproduce Bug
SK6812s RGBWs in GBR mode on an ESP32, the colors are the wrong. They are very dim, the hue isnt far off or might be right (havent fully debugged, had to quickly revert before the kids came home to see no xmas lights!)
Expected Behavior
Colors to be correct ;)
Install Method
Binary from WLED.me
What version of WLED?
0.15.0
Which microcontroller/board are you seeing the problem on?
ESP32
Relevant log/trace output
Anything else?
Can debug further later, thought Id get this raised for everyones sake
Code of Conduct
The text was updated successfully, but these errors were encountered: