TM1814: Solid Effect no longer works with the release of 0.14.0

[techoguy]

What happened?

with a fresh/new install of WLED 0.14.0 the TM1814 protocol appears to not work any longer but it did with 0.13.x
In a TM1814 LED strip, all LEDs turn red and a few may flicker when using no effects regardless of what color is set in WLED.

Current work around is to uncheck “Use global LED buffer”. Once this is unchecked, the TM1814 LEDs appear to work as expected.
Not sure what this setting does.

To Reproduce Bug

using firmware 0.14.0, and TM1814 LEDs, set the LED output to TM1814 and make sure "use global LED buffer" is checked (appears to default to checked). and use solid colors (effects set to none).

my setup: 12v TM1814 puck LEDs with 20 addressable pixels and using a digiquad ESP32-ethernet bench testing.

Expected Behavior

expected the TM1814 LEDs to be controllable with WLED when LEDs configured to the TM1814 protocol.

Install Method

Binary from WLED.me

What version of WLED?

WLED v0.14.0 (build 2310130)

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

No response

Anything else?

initial discussion in the forum: https://wled.discourse.group/t/wled-v63-controller-tm1814/9649/10

I realized after more testing that if I revert back to 0.13.x TM1814 would work, but going back to 0.14.0 did not work. from other discussions about TM1814 being sensitive to other processes going on, i started looking for other settings to change and disable. So I happened to try unchecking use global led buffer and after clicked "save" the output was working again. I'm not sure what this setting does and if it was introduced in 0.14.0 or not, but it appears to be checked by default and currently causing the issue.

Code of Conduct

• I agree to follow this project's Code of Conduct

[blazoncek]

So unchecking "Use global buffer" is a workaround?

[techoguy]

@blazoncek yes, that appears to be the case.

[blazoncek]

Unfortunately I lack HW to do any testing.

[techoguy]

Is there anything specific I could try or logs maybe? Anything else I could to test that might help?

[blazoncek]

You'll need to debug busmanager.cpp and buswrapper.h files.

[khudson]

Can confirm both the bug and the workaround. It appears that constant refresh update frames aren't being sent past the initial color set (or it's sending corrupted frames), so if you have a slow-moving effect or solid color it results in the strip being unhappy. When in solid mode, the strip gets set to the right color for about a half-second, then most of the LEDs are solid red. A few blink red and the first LED in the strip alternates between red and whatever color you've set.

Fast-moving effects work normally with the buffer turned on.

[blazoncek]

If you can compile WLED, try changing line 83 in FX.cpp to read return 250; instead of return 350; and report back.
If 250 does not do it, go lower until it does.

[techoguy]

@blazoncek
I've changed FX.cpp line 83 to return 250; and return 150; and return 50;.
250 and 150 did not change the outcome.
But 50 seemed to make it work. With 50 Solid colors worked as expected.
I didn't have much time to change or test anything else but can try more tomorrow.

Is there an easy way to change the build number shown in WLED or version when I compile so I can confirm the correct firmware is compiled and uploaded on the ESP32? Or at least know which ESP32 has my custom code?
Is it just changing #define VERSION 2310130 in wled.h line 11, or is there a better way?

[softhack007]

Is there an easy way to change the build number shown in WLED or version when I compile so I can confirm the correct firmware is compiled and uploaded on the ESP32?
Is it just changing #define VERSION 2310130 in wled.h line 11, or is there a better way?

You found the right place. The build number is best to identify a modified source code.

You could

• append a digit and make the build number longer, like "#define VERSION 23101302"
• or increment the last digit, which is for the daily build; "#define VERSION 23101301"

[jg159357]

I happened across this post while trying to see if I could use the AtomiSmart LED bulbs that (I think) use the TM1814. While I was reading other pages, I also saw the TitanMicro doc with the spec (https://www.superlightingled.com/PDF/TM1814-TitanMicro.pdf).

Section 3 under Application Info (page 7-8) talks about what happens after "losing data" after the half second mentioned. Just speculating, but the note (2) from "Temporal Characteristic" on page 4 says that there should be data sent to the chips faster than 126us. This seems to match with why 150 us didn't work, but 50 did.

[blazoncek]

This seems to match with why 150 us didn't work, but 50 did.

It is ms not us.

[matajumotors]

While replacing some strips to TM1814 and using WLED on ESP8266 (and on ESP32-ETH01) I identified the same issue as Author above. If global buffer is enabled during Solid color LED's go into demo mode due to infrequent update from the controller. Disabling the Global buffer helped, but I was still getting random Red Flashes. Adjusting the code and changing 350 to 50ms seems has eliminated the problem - have not noticed red flashes so far.

[Enelar]

Sorry for late hop-in, a off-topic. I have similar issue but with DDP/UDP stream as well.
At first I had issues with solid color too, and Palette troubleshooting helped diagnose it. Thanks @blazoncek.
But after I rolled back to 0.13 and increased resistance a little it never appeared again.
But with any streaming (including my custom python script) I see these flashes from time to time.

I speculate that this is happening due overloaded 2.4Ghz channel in my area. Probably there is another bug.
I run my WLED as Christmas lights for a week now(Twinklefox), I never have these red flashes. But when I start streaming data to it, I see one or two per hour. More during evenings and almost none during nights.

I've ordered Ethernet ESP32, hopefully it will confirm my suspicions.