Aircoookie
No blue rendered on WS2814 with parallel I2S on 0.15.0
What happened?
I was having bad flickering with the RMT driver under 0.15.x, as reported in #4389, so I implemented the workaround suggested there, of creating >5 LED outputs, which forces parallel I2S on the first 8 outputs. This fixed flicker, but I then noticed that no blue is being rendered, at all, on my BTF 12V WS2814 strips. Everything is working on 0.14.4 so I've downgraded and given up on 0.15.x for now, as this Catch-22 prevents me from using it on my setup.
To Reproduce Bug
Create 6 LED outputs, configure one as an SK6812/WS2814. Set the order to BRG and Swap G for W.
Select the Solid effect, and choose blue for the color. There is no output.
Expected Behavior
Blue should be rendered.
Install Method
Binary from WLED.me
What version of WLED?
0.15.0
Which microcontroller/board are you seeing the problem on?
Other, ESP32-S2
Relevant log/trace output
Anything else?
No response
Code of Conduct
- [x] I agree to follow this project's Code of Conduct
Pretty sure when I observed this, the four phantom outputs were WS281X and were at the end of the list. I had two physical WS2814 outputs defined first.
Please use the same type for all outputs and report back.
It doesn't matter, no blue with all configured as SK6812/WS2814
This may then need @makuna 's attention. Please post your configuration (cfg.json) and /json/info and /json/state responses. Edit only to remove WiFi information and MAC address. You can also submit via PM on Discord.
Note, SK6812 & WS2814 are not the same protocol from NPB, they differ in the reset timing and pulse timing. What does WLED map them to?
Also include what Feature it gets mapped to?
WS2814 is spec'ed to have output order of RGBW. You are using BRWG? "order to BRG and Swap G for W" is what was stated.
Unfortunately, the WS2814 comes in several packages (chip alone and integrated LEDs like we are used to) and the name gets used on non-World Semi (the WS in WS2814) leds. Having a link to the actual manufacture of the strip is helpful. The chip alone version the color order is up to the strip maker on how they wire their external LEDs to the chip.
WLED does not differentiate between SK6812 and WS2814. It uses the same method for both chips. I.e. NeoPixelBusLg<NeoGrbwFeature, X8Sk6812Method, NeoGammaNullMethod>.
I do not recall any issues reported with non-parallel (single) I2S use of this method (NeoEsp32I2s1Sk6812Method or NeoEsp32I2s0Sk6812Method for ESP32 and S2 respectively) and WS2814 chips, but I do remember someone reporting missing blue when using parallel I2S.
I've found these in relation to WS2814: #3094 #2646 #3500 #3655 if they might help.
SK6812 (X8Sk6812Method) only has an 80us reset time. The WS2814 is spec'ed at a minimum of 280us. I would use the WS2812x method for WS2814 for best compatibility.
It was mentioned 6 channels/strips being defined. What were the other channels set for? Which was first?
When using parallel i2s (LED) the first channel defines the overall speed of all the other channels. So, you have to be careful when mixing different speeds together. Most of the faster speeds are compatible with the slower speeds, so make sure the first is the slowest speed. WS2805 & WS2814 are the faster ones; but the WLED mapping may not be using them. The reset time should not be an issue between channels as they try to honor the channel setting.
config.json attached.
All of the physical LED strips (two in the current config) are the same - and in the final config (four) will all be the same. These are what I have (12V, 60/m variant):
https://www.btf-lighting.com/products/ws2814-12v-24v-4-in-1-similar-sk6812-rgbw-pixels-addressable-ws2811-rgbww-rgbcw-5050-3pin-led-lights?variant=46031823438050
These require 'BRG/swap W&G' config, to get the colors right.
The other four outputs are phantom, and come last, to force 0.15.0 to use parallel I2S on all outputs. RMT in 0.15.x produces very bad flicker on this setup (DigQuad is my controller).
Everything works flawlessly on 0.14.4-audioreactive.
Any new thoughts on what causes this issue? I have provided the requested info above.
@MakerMatrix Hi! I noticed that you originally installed via a prebuilt binary, so just in case you don't have the necessary computer setup to build and test the fix yourself, you can install a prebuilt binary with the fix from here:
https://github.com/wled/WLED/actions/runs/16635392570
(scroll down to Artifacts and click the one appropriate for your board)
Please test it to see if the fix works for you. :)
Edit: Link updated to 0.15.1 release candidate build.
@blazoncek I noticed some weirdness here. Just checking...
The other code comments all refer to offset = 1 as I2S0 and offset = 2 as I2S1, which contradicts the comment you changed. Do these comments still make sense? I have highlighted the contradictions:
Edit: After searching through https://github.com/wled/WLED/blob/main/wled00/bus_wrapper.h and looking closely at every mention of I2S0 and I2S1, I think your comment is correct for all boards except ESP32-S2, and it simply seems that the meaning of offset 1 is different on different chips. It seems like 1 = I2S1 for all ESP32 models (except ESP32-S2 where it's I2S0 instead).
So it seems like all comments from the new commit are correct. They were just confusing at first glance since it wasn't totally obvious that different boards treat offset 1 as I2S1 or I2S0 depending on which chip it is. :) Nice catch!
Edit: Oh, I see that @willmmiles actually did some further fixes for I2S/RMT channel selection and comment clarification, and that this should go into 0.15.x too. Now the situation makes sense. 👍
https://github.com/wled/WLED/pull/4762
I2S0 is no longer used. It is reserved for AR. On S2 there is no I2S1 so I2S0 is used instead.
Ah that makes sense, thanks for clarifying! :) Looks good. Btw, I've tested the code now and it works for me. Test results at https://github.com/wled/WLED/pull/4763#issuecomment-3061600756.
@MakerMatrix If you have any time, it would be hugely appreciated if you can also run a test with the binary mentioned below to see if your scenario is fixed, since I don't have a strip with the reversed LED order issue:
https://github.com/wled/WLED/issues/4719#issuecomment-3059312872