I had posted this originally on Github, but I figured I’d post here too, since there seems to be a lot more discussion.
Some newer LED chips (GS8206/8208) have a feature where they will display their own patterns in the absence of a data signal. The timeout seems to be under 1 second. They will actually run their patterns with only a power supply connected.
This becomes an issue when turning off the “power” in WLED, which I’m assuming sets the strip to black and then stops sending data. This then triggers the pixels to go into internal display pattern mode. Some effects which use a pause also cause this problem, most noticeable being the lightning and ICU effects.
The only workaround to be able to turn these pixels “off” in WLED is to set them to black (or just kill all power). Setting the strip to any solid color does not cause this problem. If I want to use the lightning effect (seriously one of my favorites) I need to jack up the speed to serious lightning storm so it doesn’t trigger the timeout on the strips.
My thoughts for a permanent fix would be to create a “send continuous data” option in WLED where it would just send all black during effect pauses and when the “power” is turned off.
Anyone have thoughts on this or experience with this type of LED chip?
This is probably dead wrong, but what about a macro that basically toggles from lightning effect to single color effect with primary color RGB=0x010101, and immediately back to lighting effect.
Not sure how that would look.
Maybe a usermod that does something like this.
Counts frames. When frame count = 30, save current effect settings, switch effect to solid color, with intensity = 1, brightness = 1, RGB color = 0x010101, and then reset count.
When count = 1, restore saved effect settings.
The problem is (and I’m speculating here) the lightning effect uses delay(), so the ESP will pause and not send any data. This is enough to trigger the LED chip’s internal mode. Depending on how lightning and the other effects are written they may need a re-design or a function to replace delay() with one that continues to update the pixels.
I did take a look at relay support and will be giving that a try as another workaround for the power off issue.
Having seen how WLED effects work, most likely the strip compares the current data and if it gets stale and happens to be black, no matter how much it is refreshed, it is still black and unchanging.
That’s why I suggested tossing in a random white flash of brightness 1 (out of 255). That might interfere with the lightning effect if 1/30th of a second flash of very dim white is noticeable.
Oh, didn’t read that it affects some effects as well. But that makes sense, these seem to revert to their test pattern after no signal for somewhere between 500 and 1000 ms (Solid mode refresh rate is every 500 ms). Effects will require a per-effect fix that makes sure the refresh rate stays at least twice a second even though nothing is actually changed.
A test pattern is a good feature to test the LEDs without having to hook up a control MCU, but I don’t get why it isn’t disabled until the next powerup once data is received. That’s quite a bad design choice, what if the host MCU is busy for a sec or two with network tasks or something… Well nothing we can do about it other than make sure these get their data on time
