TM1814 support might not be working correctly

[wonderslug]

Describe the bug
When trying to run a set of TM1814 chips leds im only getting a what looks like a random pattern on the first LED and what looks like a default color cycle on all the other LEDs.

Ive been able to use a modified NeoPixelBus example to work and it seems to behave fine.

Ive noticed that one of the requirments for the NeoWrgbTm1814Feature is that the SetPixelSettings needs to be set with a NeoTm1814Settings:
strip.SetPixelSettings(NeoTm1814Settings(165,165,165,165));

I am using an ESP8266 so using pin 3 on a QuinLEd-Uno.

Ive tried to compile this into WLED myself but still get the same behaviour .

My changes to the NeoPixelBus Cylon example to get it working were only the Method and Feature def
NeoPixelBus<NeoWrgbTm1814Feature, NeoTm1814Method> strip(PixelCount, PixelPin);

A slight change to an RgbColor to an RgbwColor, and adding the above SetPixelSettings right after the Begin().

WLED version

• Board: d1mini
• Version 0.11.0
• Format Binary, self-compiled, WBLD bot compiled,

Additional context
Anything else you'd like to say about the problem?

Thank you for your help!

[esev]

I've seen the same issue. In addition to the SetPixelSettings mentioned above, it doesn't look like TYPE_TM1814 is handled in the code below:
https://github.com/Aircoookie/WLED/blob/d603a8a9be0d9d25917ab04a4f9fef5ca10c139e/wled00/bus_wrapper.h#L855-L863

I added

        case TYPE_TM1814:
          return I_8266_U0_TM1_4 + offset;

I ended up hacking a small bit of code in the create method for SetPixelSettings:
[Edit]: This is a quick hack that just worked for my use-case (GPIO2 on an ESP8266). A more complete solution is in #1847.

      case I_8266_U0_TM1_4: busPtr = new B_8266_U0_TM1_4(len, pins[0]); break;
      case I_8266_U1_TM1_4:  // GPIO2
        {
          auto* tm1814_strip = new B_8266_U1_TM1_4(len, pins[0]);
          tm1814_strip->SetPixelSettings(NeoTm1814Settings(380, 380, 380, 380));
          busPtr = tm1814_strip;
        }
        break;
      case I_8266_DM_TM1_4: busPtr = new B_8266_DM_TM1_4(len, pins[0]); break;
      case I_8266_BB_TM1_4: busPtr = new B_8266_BB_TM1_4(len, pins[0]); break;

I was able to control my TM1814 lights after making those changes.

[esev]

@wonderslug if you are still interested in this bug, could you test with #1847?

Also, just curious, in your examples you were configuring a max of 16.5 mA per LED. Was there a specific reason for that, or was this based on another example? The PR above is using 38.0 mA. I'm pretty new to WLED & LED strips in general. Just want to make sure I'm not missing something important that might break the LEDs.

[wonderslug]

Howdy @esev

I was just using that as the example from https://github.com/Makuna/NeoPixelBus/wiki/NeoPixelBus-object#tm1814-features as an example. Im actually not sure what the proper values should be.

[wonderslug]

As well I will be giving #1847 a try.

[mlangner84]

I was able to get the TM1814 string lights I'm using working on an ESP32 with multiple pins being used (following and adopting the recommendations here.)
One issue that remained for me was that the Solid "effect" won't work.
Reason: The TM1814 needs to be programmed every 500ms, otherwise the internal "auto-sequence" will get started.
I was able to resolve this by changing the return value for the mode_static(void) function (FX.cpp) to return FRAMETIME in all cases.

[wonderslug]

@mlangner84 Awesome! Can you please add them to #1847? Or put the patch here.

[Aircoookie]

@esev thank you for #1847 ! I will merge it soon.
Solid mode has that low 2fps refresh rate to limit flashing on out-of-spec installations (that are not using a levelshifter to provide the LEDs with a good 5v signal), so I would like to keep that. If the timeout for TM1814 is 500ms indeed, our refresh is just barely not in time. I would definitely be open to setting the refresh rate on Solid to 350-400ms to fix this.

One potential issue (please test if you have access to TM1814) is that LEDs are not refreshed at all when they are turned off in WLED (again, to prevent mentioned flicker problem). I know of one other LED type (I believe GS6808?) that has the same problem. We could introduce a type-dependant minimum refresh rate to prevent this sort of issue.

[mlangner84]

I agree with changing the refresh rate to 350. This will increase the update for the other LEDs a bit but should also work for TM1814. I have tested this here on my bench setup and can confirm that it is working. Will update the controller outside (with the 3 strings) later and update here, but it should be working for the TM1814 to change the 500 to 350.

@Aircoookie If the LEDs are turned off they will go into their internal blinking mode.
Here is the part from the datasheet, so if there is no pulse on DIN for 450ms it will switch to internal controls:

So basically you would have to send an update with all colors set to 0 every 400ms when in "OFF" mode. I have only worked with your WLED code for about 4h, so I'm not sure if this can easily be done (check if TM1814 in "OFF" mode and implement it there?).

I noticed something else yesterday: There is some hiccup when adding / modifying TM1814 strings. In the end I had to basically delete all stings, restart the ESP32 and then add all 3 strings with the correct settings (number of LEDs) at the same time. If I started with one string and then modified a setting (number of LEDs or pin) it would not work / have strange results. Sorry, I didn't have time to go through this step by step to give a better explanation.
My gut feeling right now is that it has to do with how the RTM channels of the ESP are being used. I think the cleanup function is not resetting this and therefore they are getting reused.

That brings me to another point:
@esev I don't think the change to "NeoTm1814Method" will work when multiple strings will be used because they would all be mapped to the same RMT channel. I see that in #1847 you did not change this, so #1847 should work fine. I just wanted to mention this here so ppl are aware of it.

As you said another challenge is the mA settings. Reengineering the lights I'm using (logic analyzer on the original controller) I can see that the first bit of the 6 bits per channel is high. Based on the datasheet that would mean 1x 38mA + 5* 6.5mA = 70.5mA. I think that the datasheet is wrong here, because the location of the bit seems to mater and not just the number of bits that are 1:

To get the same setting that the original controller is using I have to define the max as 225. The formula is in NeoTm1814ColorFeatures.h.
When I use the NeoTm1814Settings::MaxCurrent I will get all 1s and I'm probably way overdriving the LEDs. Do you know where that MaxCurrent is defined and how the user can easily override this?

[esev]

When I use the NeoTm1814Settings::MaxCurrent I will get all 1s and I'm probably way overdriving the LEDs. Do you know where that MaxCurrent is defined and how the user can easily override this?

MaxCurrent is defined here: https://github.com/Makuna/NeoPixelBus/blob/a6da4b728b57b855d7f7e69b6140f31a2a33ad8e/src/internal/NeoTm1814ColorFeatures.h#L38

My thought was to use the max value here, since I don't see any direct way to configure it. For a LED strip that needs less current, I thought that Maximum current/Custom max. current could be adjusted in the LED settings to have the exact same effect. To be honest though, I don't have an electronics background and don't fully understand the implications of this. I just didn't want to hard-code a value that limited the brightness here.

[esev]

One potential issue (please test if you have access to TM1814) is that LEDs are not refreshed at all when they are turned off in WLED (again, to prevent mentioned flicker problem). I know of one other LED type (I believe GS6808?) that has the same problem. We could introduce a type-dependant minimum refresh rate to prevent this sort of issue.

I must have a weird variant of the TM1814. Mine don't seem to require any refresh. They don't go into a default pattern when there is no data signal. I don't have a good way to test the additional changes needed for the refresh.

I've changed #1847 so it won't close this bug. Once we figure out the correct values for NeoTm1814Settings could that one be merged and then someone work on the refresh changes independently?

[mlangner84]

That is very strange. The datasheet for the TM1814 is "interesting" in general, but that something like the internal control is wrong would be doubtful. Can you check the markings on your strip? Does it in fact say TM1814? Any chance you can read the smaller marking under it? It could be that they have different "internal control" mechanism and mine are going in this "color cycle blink" mode but yours are just staying in whatever mode they are.

[esev]

I'm having trouble getting a clear picture of it. It looks like mine says TM18148 or TM1814B / FA04-5536WT.

I still have alligator clips on the data line. If I disconnect the clip the lights just stay in their current state.

[esev]

Looks like it's TM1814B. The datasheet doesn't look like it has the same table as the TM1814 where the internal control pattern is described. So it seems like I do not have a TM1814, and luckily the TM1814B responds to the same data signals.

[mlangner84]

Ahhh, that starts to make sense now. My Chinese is not the best but I agree with you, based on the TM1814B datasheet they don't have the internal control and therefore likely just stay at whatever color they are at (like most other chipsets). So only the TM1814 (without B) need to be reprogrammed every 450ms.

Going over the TM1814B datasheet I think I also understand the what they are trying to say regarding the mA in the TM1814 datasheet. If it's all 0s then the output is 6.5mA, if its all 1s the output is 38mA. With the 6 bits you can control 64 linear levels in-between.