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.

[esev]

For the constant current value, I don't fully know what the right setting is. Please correct me if I'm wrong here - I want to learn....

What I'm assuming is that the value provided for the constant current is used to scale the brightness data settings for the individual colors. As an example, let's say WLED is set such that all LEDs should have full brightness (255 - or all 1's). I'm guessing that the constant current scales this value by some percentage. So when 38mA is chosen you get full brightness (255) but when 6.5mA is chosen you get a smaller value (say 65 for example).

I think this is the exact same thing that is happening in the WLED software when the Maximum current/Custom max. current settings are adjusted. That's why I was thinking that the best setting for WLED is to use 38mA for NeoTm1814Settings and then just let the built-in software handle the scaling within WLED.

However, if the TM1814 also uses the constant current value when it goes into it's internal control mode, then I think we have a problem. At that point WLED isn't doing any software scaling and it's up to the TM1814 chip alone to set the values correctly.

I don't know how to set the NeoTm1814Settings based on a configuration option. But I'd be happy to use a lower default constant current value in the code to account for this. The only downside is that some strips might not ever come to full brightness with a lower value. I'm personally okay with that as I'm not setting the brightness on mine any higher than 50% (127) anyway. Others can always modify the constant and compile with a different value that makes more sense for their LED strip.

@mlangner84 do you know how many mA your lights can handle (maybe the sum if several are controlled by the same chip)?

[mlangner84]

In my case each TM1814 is driving 3 RGB LEDs in series and one white LED. (There is a small PCB inside every light bulb of the string lights.) To my understanding the current that is being used depends on the type of LEDs that are being used. The TM1814 is a constant current driver, so the current (in A) to the LEDs will be kept constant by the TM1814, independent of the environment (mostly heat). This article should help with the basic understanding (as I'm for sure not an expert in this :) ): https://www.ledsupply.com/blog/constant-current-led-drivers-vs-constant-voltage-led-drivers/ So your statement is correct, that higher current will make the LED brighter, but if you would use the current to control the brightness it would go south (= LED burns up) very quick. This is where the constant current driver come into play. The brightness in this case is controlled via PWM (technically means Pulse Width Modulation, meaning it is controlled how long the LED is on in a certain time frame. The TM1814 supports ~1000Hz = 1000 cycles per second, Now it depends a bit on how this is implemented, to achieve 50% brightness you could for example turn the led 500 times on and off in the 1000 cycles or you could turn it on for 500 cycles and then turn it off for 500 cycles (or anything in-between, as long as it is on 50% of the 1000 cycles). The latter would lead to flicker (0.5s is something a human can see), so I'm pretty sure they are going with the fast on/off approach). How often the LED is being turned on will determine the brightness. So instead of changing the brightness via the current, you set the current to a fixed value and then turn the LED on and off very quickly to make it seem brighter (more or longer on cycles) or darker (less or shorter on cycles). This is what is controlled with the R G B values in the data stream.

I basically reengineered the value for my LEDs because I connected a logic analyzer to the original controller and looked at the data that was sent to the LEDs. In my case the current is configured as 0x20 0x20 0x20 0x20 (if you look into the datasheet, that is the C1 data word that is being send before the D data that contains the R G B values. Via the logic analyzer I confirmed that this value never changes, independent of the brightness that I'm setting using the original controller. In my case this translates to a value of 225 for the NeoTm1814Settings (=22.5mA). The calculation that they are doing is based on the way the C1 data format is defined in the TM1814 datasheet: You have one byte per white, red, green and blue. The first two bits of each bit are fixed to 0. This leaves you 6 bits for setting the value (64 different possible values). If all 6 bits are '1 then the current will be 38mA, if all bits are '0 the output will be 6.5mA. (This also shows that you can't use these values to control the brightness, you would never be able to turn it off completely because the TM1814 will always drive with at least 6.5mA.) So the calculation with Settings.Current - MinCurrent / 5 is basically mapping the customer input (in mA * 10) into the correct format.

I have to admit that I have absolutely no idea what value the TM1814 is using when it goes into the "internal control" mode. Based on what I see with my LEDs I assume that they are either using some value between 22mA and 38mA, or just the max (=38mA). Because the "internal control mode" is a blinking with different colors this doesn't matter too much, because the LEDs are not being driven 100% of the time and therefore shouldn't take any damage, even if driven with higher mA then they are supposed to.

To implement this in a generic way the user would need to have a way to define the mA his specific LEDs are using. There is the option for a "Custom LED" in the LED Settings Config, but I think that is more for the overall power consumption calculation. The bigger question for me is if the user has this information available. I was not able to find this information for yours, nor for mine LEDs. And I doubt that most users have a logic analyzer at home to find out by decoding the data from the original controller (if there even is a original controller).

[esev]

@mlangner84 sorry it took a bit to get back to you on this. Using the Custom max. current per LED works for me. Good suggestion. #1905 allows the constant current setting to be configured in the web UI. This allows both the overall power consumption logic, and the TM1814 constant current to be set in one place.

Edit: I gave up on this approach. It doesn't work well with the power computations in WLED.

[esev]

The bigger question for me is if the user has this information available. I was not able to find this information for yours, nor for mine LEDs.

I agree. I think you'd need to look at the datasheet for the LED itself and find the continuous current value. Ex: https://www.smdledlamp.com/product/product-43-322.html

Unfortunately I don't see any markings on my LEDs indicating the part number.

It seems like maybe we can calculate it by the max wattage listed for the strip? Mine is a 24v strip with 300 LED modules per strip. Each LED module has 4 LEDs (RGBW). If the max wattage is 72 then I think you can calculate the max per LED as 72(watts) / 24(volts) / (300 modules) / 4 (LEDS/module). This comes out to a very small value for mine though (3.75 mA) so I suspect either my math is wrong or the max wattage listed is incorrect.

[mlangner84]

Sorry for the delay, I had to focus on some other project for the last few days, always something...

I think your approach with the 22.5mA as default is fine. I doubt that will overdrive the LEDs that are usually used (the Costco Light String seems to use the same than mine, just a different shaped diffusor plastic), and if it's too dim than ppl can recompile it with a different value (if they are able to find it). I have completely given up on using the advertised watt. This seems to be completely off most of the time. It can also be possible that the white LED has a different current rating than the colored LEDs, so you would be back at "guessing".

Let's use the 22.5mA, I think that's the best approach for now.

[Legsmaniac]

so you would be back at "guessing"

You could always use a MultiMeter and measure the actual current rather than guess.
They're cheap enough now, after all, if you don't have one. (And an essential piece of kit too!) 😊

[mlangner84]

Yes and no... If you have just a strip, without a controller, there is nothing you can measure without programming first :) In case of the string lights they have small PCBs inside. In my case you will find 3 RGB LEDs and one white LED. In case of the Atomi Stings they seem to have one RGB LED and one white LED. So you have to at least open up the LED lights and verify how your LEDs are arranged and then you have to run multiple tests to determine the mA for R/G/B and W as they don't have to be the same.

[Legsmaniac]

Yes and no... If you have just a strip, without a controller, there is nothing you can measure without programming first :)

Well yes. And yes. All you need to do is max out each colour in turn and measure the current draw. This will then be the max draw which is what is controlled by the brightness setting in Settings. In the case of RGBW, it's slightly different of course since you wouldn't be using RGW for white but at the end of the day, the max is only a guide since most effects (bar solid) only use an average of around a third of the max potential current. Anyway, my point was by using a MultiMeter you can get an accurate max current draw for each LED rather than just "guess" 22.5mA.

[esev]

Pardon my lack of knowledge here. Is it possible to supply too much current to the LED? The TM1814 has a configurable constant current level - it isn't a fixed current for the strip. So if we configure the TM1814 chip's constant current value larger than the LED circuit can handle and set the brightness to max, won't that risk shortening the lifespan of the LED?

Rephrased: If I configure the TM1814 to use 38.0 mA when the LEDs were only designed for 22.5 mA, does that risk damaging the LED? And if I configure the TM1814 chip's constant current value for 38.0 mA (even if the LED circuit was designed to only handle 22.5 mA) would we expect a multimeter to show 38.0 mA, or would it show the designed max for the LED?

Note: I bought a LED strip reel, without a controller. Is there a good way for me to determine the proper setting for the TM1814 constant current value for the LED, or the max current for the strip?

[Legsmaniac]

Yes, totally impossible. Unlike voltage, current is drawn by the equipment/appliance in question. Take a 2kW electric fire for example. It will draw a maximum of 2kW no matter how much current you throw at it. For this reason, you need to provide a supply of at least 2kW in order to get the maximum heat the 2kW fire will provide you. For example, if you only have a power supply giving you a maximum of 500w then the 2kW fire will only be able to make use of that 500w, a quarter of the power the fire is designed to operate at and so effectively you only get a quarter of the heat. On the other hand, if you were to provide a power supply of 10,000kW, the 2kW fire will still only draw 2kW of the available possible 10,000kW. The same with LEDs, they are rated a possible maximum, for example, 22.5mA per LED at it's given operating voltage. You can supply more voltage and then yes, you would blow it up but you cannot "supply more current".

The purpose of the brightness controlling setting in LED Preferences is that you can limit the amount of current to the LED and thus control the brightness. Like with the electric fire example above, if you limit 500w, you get a quarter of the heat. So by limiting the permissible maximum current to the LEDs you can control how bright they are. If you set this setting to 30A and your power supply could only give a maximum of 10A, the LEDs would only get a maximum of 10A to run on. On the other hand, if you set this limit to say, 2A and the LEDs can draw 10A and the power supply is capably of 10A, only 2A will be provided to the LEDs, a 5th of its potential and so a 5th of its brightness. If the power supply were able to supply 50A and the setting was set to 20A and the LEDs could only draw a maximum of 10A then a maximum of 10A is all they will draw, no matter how much you throw at it.

[esev]

Thanks @Legsmaniac! If you have the time, could you help me understand a bit more? I'm a software guy, and I want to make sure I'm doing the right things for the TM1814, but I'm concerned I might not know enough about the electronics side and want to make sure I don't write code that damages something. I'd like to understand the math/physics involved so that I can understand how to compute the values for different scenarios.

It's difficult for me to see the traces on the LED strip, but there are resistors labeled RR, RG, RB, RW on mine. I assume those resistors are in series with the Red/Green/Blue/White LEDs inside the 5050 LED component. I don't know which 5050 is used on my strip, but taking this one as an example, and focusing specifically on the Red LED, it says the Continuous Forward Current is 25 mA and the Forward Voltage should be between 1.8V & 2.4V.

My LED strip operates at 24V, and the RR resistor reads 561, which I take to mean 560 Ω. For each TM1814 chip there are 6 LEDs (I'm going to assume they are in series). My assumption on wiring is that the circuit is constructed like this 24V -> TM1814 -> RR 560 Ω resistor -> Red LED -> Red LED -> Red LED -> Red LED -> Red LED -> Red LED -> Ground.

My understanding from this comment was that the TM1814 tries to hold the current constant and varies the voltage with a PWM signal. If we set the constant current value to 38 mA and PWM to the max (255) for the red LED, it'd expect there to be a 24V/38mA supply out of the TM1814. Is my understanding correct on this so far?

With those settings, I'd like to calculate the voltage supplied to each of the 6 red LEDs. I'm not confident in my ability to do this. Is there a way calculate the voltage and verify that it isn't beyond the specifications for the LED?

[mlangner84]

@Legsmaniac: I in general agree with your description, but LEDs are different.

@esev: Here is another good starter article about this: https://learn.sparkfun.com/tutorials/light-emitting-diodes-leds/all Just to quote from this article: "If you connect an LED directly to a current source it will try to dissipate as much power as it's allowed to draw, and, like the tragic heroes of olde, it will destroy itself. That's why it's important to limit the amount of current flowing across the LED." That's were serial resistors or constant current supplies (like the TM1814) come into play.

As I mentioned before: When I change the brightness with the original controller the bits that control the current of the TM1814 will not change. The brightness is only controlled via the 4 bytes that control the R/G/B/W values.

[Legsmaniac]

Just to quote from this article: "If you connect an LED directly to a current source it will try to dissipate as much power as it's allowed to draw, and, like the tragic heroes of olde, it will destroy itself

No, sorry, that's not quite correct. You also missed out the rest of the article where it says - That's why it's important to limit the amount of current flowing across the LED. For this, we employ resistors. Resistors limit the flow of electrons in the circuit and protect the LED from trying to draw too much current. So you can have a power supply which has a maximum output capability of 100A, the LED will not draw 100A and will not die. Trust me, I'm an electronics technician.

@esev That's quite a request you have posted up. Rather than reply here I think it may be better if you were to email me legsmaniac69@gmail.com to avoid taking up this thread and to avoid other wannabe hobbyists chiming in confusing the issue for you. I will be happy to help where I can.

[mlangner84]

As a wannabe hobbyist I always try to learn. And I agree with you on the resistors (see above: "That's were serial resistors or constant current supplies (like the TM1814) come into play."

My understanding so far is that this is an either or. You can either use resistors to control the A or you use a constant current supply like the TM1814 to avoid having additional resistors that are creating heat. If this understanding is wrong I would appreciate if you could let me know what exactly the constant current supply is for and why the A for each channel can be controlled with the TM1814. If you are using a resistor to limit the A then I don't see why a constant current driver is needed.

@esev: I do agree that we are drifting of topic, but for all the other hobbyists it would be good if you could post the final result of your question / calculation, so that everyone can learn from it.

[Legsmaniac]

The TM1814 isn't a Constant Current Supply but an Addressable Pixel RGBW chip. The chip is controlled by PWM signals which the chip decodes and opens the gates of each RGBW to Ground as required, passing on the signal to the next TM1814. Perhaps this is why you are confused? The resistors on the strip limit the current and therefore reduces the voltage required for the LEDs and the TM1814.

My reply to esev's questions is rather long so I'll not post it here but I have replied to his email. It's also going off topic and no longer pertaining to WLED so it is unfair on Aircookie and the team to continue off topic on here.

[mlangner84]

@Legsmaniac, please correct the hobbyist, but I think the truth is a mix of everything. To clear things up for everyone who is following this thread (and again, please feel free to correct if anything is wrong) and bring this to a conclusion that actually will effect the WLED library:

The TM1814 has the capability to regulate the mA for the R/G/B/W connection, this is controlled by the C configuration data word that is sent before the R/G/B/W value. This value allows global control of the maximum mA in the range of 6.5 to 38mA. This makes it technically a constant current supply. This is also the title in the data sheet: That the TM1814 in fact regulates the mA is proven by the implementation in Neopixel (function that adds the C data word is required to get LED strips/strings working at all), different YouTube videos that work with TM1814 (I'm not going to link those as they are not all using WLED) and my own experiments of using different values for C and seeing the LEDs behave accordingly. The datasheet for the TM1814 can be found here: https://datasheetspdf.com/pdf-file/1330606/TitanMicro/TM1814/1

In addition to this internal functionality of the TM1814 there is the possibility of external resistors that will control the maximum mA going through the LEDs. I checked and this is in fact also the case for the small PCBs inside my string lights. So we basically have two current "regulations", the internal TM1814 and the external via resistors. So as long as these external resistors are being used there is no risk of damaging the LEDs, independent of the mA settings of the TM1814. The theoretical fact that the TM1814 could be used without external resistors (which I though was the case) can be ignored, because in praxis there will always be the need for external resistors to achieve the correct voltage for the LEDs. @esev: Why these resistors are needed (even though we could control the current through the TM1814) and how to calculate these resistor values is described in the article I linked above. If you can read or measure your resistor values you can use the same formula to get to the max current for your LEDs.

So bottom line is that we can set the maximum supported value in the library, given that the external resistor will protect the LEDs and therefore there is no risk of damaging the LEDs. Just by having a too low value we potentially preventing the LEDs from lighting up as bright as they would support.

[esev]

@mlangner84 Thanks for providing all the links and background.

The theoretical fact that the TM1814 could be used without external resistors (which I though was the case) can be ignored, because in praxis there will always be the need for external resistors to achieve the correct voltage for the LEDs.

I'm still not an expert here. This is a key take-way from the email thread with @Legsmaniac too. The LED strip manufactures are going to include the correct components. As long as we supply the correct voltage to the LED strip there is no concern for overdriving the LEDs with too much current. And we can measure the max current with a multimeter.

---

Just to quote from this article: "If you connect an LED directly to a current source it will try to dissipate as much power as it's allowed to draw, and, like the tragic heroes of olde, it will destroy itself

This is where I started to get confused. I took that as a blanket statement that applied in all situations. That conflicted with my understanding and lead to lots of confusion on my part.

Based on feedback from @Legsmaniac I did my own experiment. I connected a LED (a random LED I had in a parts box) to a 1.7V 50mA power source. I did not use any current limiting resistors. And I measured the current with a multimeter. The LED lit as expected and the multimeter measured a continuous 10mA current. The LED did not try to dissipate as much power as it was allowed to draw.

So the quote from the article seems to be inaccurate for some situations. I don't think the statement is true when the supply voltage is less than the forward voltage drop of the LED.

---

Just by having a too low value we potentially preventing the LEDs from lighting up as bright as they would support.

This was my initial assumption too. I think it'd be good if one of us can do an experiment to verify this. I won't be able to experiment till the weekend. The line that starts with "5." in the datasheet appears to imply the the current limiting may not even kick-in if a series resistor is present. So, in the presence of potentially conflicting information I think we should verify.

If it's true that the TM1814 adds additional limits to the current even when there is a series resistor than I also agree we should set the maximum supported value in the library. If the TM1814 doesn't add additional limits then I think WLED should copy the 22.5 mA value that is used by the manufacturer supplied controllers. Several manufactures appear to be setting the same value so it seems like a reasonable default for WLED too.

[mlangner84]

Trying to help as much as I can, but as we can all see from this thread it's easy to miss something...

Some feedback:

• Measuring the current: I would still be careful with that. The TM1814 draws itself up to 250mA (see datasheet). Given that we are trying to measure in a range of 10mA - 30mA I think this is something that could really throw the measurement off because they have only given the max, but not the typical in the datasheet.

• Connecting the LED: If you drive it with the correct voltage then this should not be a problem. My understanding is that it basically starts if there is a higher voltage available, then it will start drawing more current, heating up, leading to even more current draw. Having said this I realized that I was researching high power LEDs (500mA forward current) for another project and ignored the following in the same article which would probably have prevented a lot of the discussion here (but hey, we all learned something and that is the goal at the end of the day...)

The most common LED strips are designed with a group of LEDs in series with a current-limiting resistor in line with them. The manufacturers make sure the resistors are of the right value and in the right position so that the LEDs on the strips will be less prone to the variation of the voltage source as we talked of with the XP-G2. Since their current is already being regulated, all they need is a constant voltage to power the LED(s).

So basically the "off-the-shelve" LED strips and strings are taking care of the problem by inserting the resistors and then you have to use a certain power supply (e.g. 12V or 24V). For your experiment you could increase the voltage to be higher than the defined forward voltage of your LED, and you should see that the LED will draw more and more current over time. (Warning: This will most likely damage the LED.)

I did this test (by accident) when I initially brought up the TM1814. I had the current output (the one that is controlled with strip.SetPixelSettings(NeoTm1814Settings(165,165,165,165));) configured to a too low value and my LEDs would be very dim. Only after I changed the value to get to 22mA or more it had the same brightness than before. I will quickly test this again with my bench setup and get back to you.

[esev]

I have a strip with an actual TM1814 now that I can use for testing.

@Aircoookie I noticed you increased the refresh rate to 380 in 7f6a554e1b36d5d11e3e331ec0903dd23cc2749f. That didn't quite work for me. Some of the LEDs at the end of my strip were still not refreshed quick enough. It mostly works with 350 though. There is a small period of time, about 1 second after booting, where the refresh still isn't fast enough and the default pattern happens. I think something else must tying up the microcontroller's time. Not a big deal as it goes back to normal just as quickly.

@wonderslug & @mlangner84 could you test this on your TM1814 strips? https://github.com/Aircoookie/WLED/compare/master...esev:tm1814

It increases the refresh rate and also causes the LEDs to be refreshed even when turned off.

[makerglenn]

Thank you for the discussion and work to get WLED TM1814 support. Now that we've gotten by the "current per LED" discussion - one must remember (per @Legsmaniac's analogy above) that for a LED strip to work properly one must size the power supply (wattage) to meet or exceed the overall current requirements of the LED strip.

[esev]

Hi @makerglenn

Good advice! I'm testing WLED with the Atomi Smart LEDs at the moment. No worries about the power supply there since it was sized by the manufacturer.

It has a TYWE3S wifi board, which is just a ESP8266 with 2M of flash. I ended up using this for the env in platformio.ini

[env:tywe3s]
board = esp_wroom_02
platform = ${common.platform_wled_default}
platform_packages = ${common.platform_packages}
board_build.ldscript = ${common.ldscript_2m512k}
build_unflags = ${common.build_unflags}
build_flags = ${common.build_flags_esp8266}

I ended up cutting a pin on two of the built-in chips.

1. I cut a pin on the bottom chip (HC89F0421) that connects it to the serial RX port on the TYWE3S. This was needed because, when powered by the mains, the HC89F0421 interfered with my FTDI serial connection to the TYWE3S. With it connected I could not flash the TYWE3S.
2. I cut the DO pin on the TM1814 chip that is built-in on the circuit board of the device. I don't know if the HC89F0421 would continue driving this, and I wanted to keep the large DO cable soldered to the board. So I figured the simplest way to avoid interference with the onboard TM1814 was to disconnect it from the outgoing cable.

After that, it was pretty straightforward. I soldered connections to the TYWE3S for serial programming and for access to GPIO2. After flashing WLED onto the TYWE3S, I connected GPIO2 through a level shifter to the outgoing DO cable. The little proto board that the level shifter is on fits nicely in the gap between the circuit board and the case when rotated vertically.

[makerglenn]

I confirmed my Atomi String lights work with the 0.12.1-b1 build and changing the refresh rate from 380 to 350 on a NodeMCU and ESP-WROOM-32. I had to set the number of LEDs to 19 (actually 18 LEDs but there was a TM1814 on the original controller board now being bypassed). Also to get all LEDs to light properly I set the start to 1 and count to 18 in the LED setup UI page. Did anyone else have a different setup to get all LEDs to work?

Glad to hear the TYWE3S runs the TM18144 WLED with the level shifter. Just FYI the programming interface on the board is just to the side of the TYWE3S. See picture below. You can ohm this out to the actual pins of the TYWE3S to confirm...but on my board the red wire is for 3.3v, Yellow for Tx, Blue for Rx and Green is ground. To flash the TYWE3S with the wled esp01_1m build I just connected those four wires to my USB serial programmer and held a test probe connected to ground at GPIO0 pin temporarily just while plugging in the serial programmer to get it into flash mode. A second later you can just remove the probe/wire from GPIO0. You are now in flash mode. Hope that helps someone in that its best not to solder directly to the chip pins if possible. In this case Atomi provided a flash interface. Also to be clear I didn't use "mains" power to flash the TYWE3S as you did @esev, just the 3.3v from the serial programmer (and swapping the Tx and Rx wires between the programmer and TYWE3S of course).

[Legsmaniac]

Did anyone else have a different setup to get all LEDs to work?

You could try Skip First LED at the bottom of LED Preferences setup page.

[esev]

Nice work finding the programming interface @makerglenn! And thanks for confirming that 350 works for yours too. I only have the shorter LED strip with 12 lights, so I was curious if it would work with the longer ones.

Were you able turn yours off, or are you using a relay for that?

I didn't run into any issues with needing to skip LEDs or set the number one greater. But maybe that is because I removed the TM1814 on the circuit board before the first LED? With 12 lights, if I configure for 11 then the last one in the string doesn't get set. Setting it to 12 works perfectly on mine.

[makerglenn]

You could try Skip First LED at the bottom of LED Preferences setup page.

@Legsmaniac TY. Yes that worked. I knew the eliminated TM1814 on the hacked controller board was the "first LED" and needed to be skipped. I'm new to WLED trying to get this TM1814 string working and forgot about that option.

Were you able turn yours off, or are you using a relay for that?

@esev No my string does not turn off - it goes into "no refresh" varied color flashing mode drawing between .4 and 1.4 amps. I think @Aircoookie mention this might be a problem (and possibly provided code above to test?). I haven't investigated anything further since seeing my string of TM1814 LEDs light up and run wonderful WLED effects! Thanks to all for the effort. Almost there....

[mlangner84]

The 350 works for my string lights, too. I still have to update with the complete new file to verify that the "off" works.

@esev: I also did the test where I used 3 different mA values for the max. 0, 225 (the value that is used by my controller) and 380. For the test I set the color to white (the color, not the white channel) and the brightness to maximum:

max = 0:

max = 225:

max = 380:

If there is a difference between 225 and 380 it is too hard to tell (and using a quick photo from a phone with tons of autocorrection is questionable in general for this kind of comparison ...). But I do think the max = 225 and max = 380 are showing white, while the max = 0 has a blue hue. Also the "circle" on the floor is not as bright as the other two setting. I do think this confirms that the TM1814 is at least able to restrict the current. I'll try to build a small board with a TM1814 and a LED with current measurement on the TM1814 outputs. I'm debating using the TM1814 for some single high power LED projects, but I don't know when I get to it.

@makerglenn: Did you already try the modification that @esev mentioned above, that should resolve the issue with the TM1814 going into "default" mode:

could you test this on your TM1814 strips? master...esev:tm1814

[esev]

I tested two different strips. In WLED I set the brightness to max, set the color to white, and also set the white channel to max.

1. One very similar to the one you have pictured, the Atomi String. I had a device connected to read the wattage when plugged into the mains.
   • (MinCurrent=65) = 10.27W
   • (225) = 15.36W
   • (MaxCurrent=380) = 15.68W
2. A 4 segment section of this 24 volt strip (24x 5050 RGBW LEDs). I was measuring with a bench power supply that has a 10mA resolution.
   • (MinCurrent=65) = 150mA
   • (225) = 390mA
   • (300) = 490mA
   • (310) = 500mA
   • (320) = 520mA
   • (330) = 520mA
   • (MaxCurrent=380) = 520mA

So I also agree. The constant current setting does have an effect on the current used. Maybe up until it hits the design limit for the strip?

Let me know if you're able to verify that the lights turn off with this patch. If it's good for you then I'll send a PR. https://github.com/Aircoookie/WLED/compare/master...esev:tm1814 (You can cheat and in wled.cpp change if (!offMode) to if (!offMode || true) too. The rest of the code changes just make sure this only impacts the TM1814)

[mlangner84]

I'm not 100% sure about the 24V strip but for both our string lights I agree with you (and that would basically match the explanation with internal and external current control I tried to give earlier :) ).

I tested your changes (all of them) and can confirm that it is working. I can turn the LEDs off and they stay off. One thing to notice: It doesn't work when you first flash the ESP32. You need to go into the user config menu and "save and reboot" for it to work. Took me a while, because I completely wiped the flash and did a clean install including reprogramming the data files, then configured my LEDs and did not reboot the controller and it was not working. But yes, changes should be good to go.

[makerglenn]

Let me know if you're able to verify that the lights turn off with this patch. If it's good for you then I'll send a PR. master...esev:tm1814

Yes I did test this full patch and it worked fine for me. My LED string turns off and draws about 55ma in off mode.

Not sure if this a feature or a bug - but I set my "Total LED count" to 18 (top of config page). I set the start/count fields to 1 to 18 (hardware setup section mid page). And have "skip first LED" selected. All works fine and all 18 LED bulbs are driven properly.... until I fully power cycle the controller and it sets the start/count to 1 to 17! Now my last bulb in the string does not work. If I change the Total LED count to 19 then the start/count stays 1->18 through a power cycle. Is this expected?

Can someone please clarify what the current settings they are using? Are you using "Enable automatic brightness limiter" and if so what Max Current setting? And what about " LED voltage (Max. current for a single LED):"? Are you using Custom and 22ma? TIA.

[CTI-Tim]

I confirmed my Atomi String lights work with the 0.12.1-b1 build and changing the refresh rate from 380 to 350 on a NodeMCU and ESP-WROOM-32. I had to set the number of LEDs to 19 (actually 18 LEDs but there was a TM1814 on the original controller board now being bypassed). Also to get all LEDs to light properly I set the start to 1 and count to 18 in the LED setup UI page. Did anyone else have a different setup to get all LEDs to work?

Glad to hear the TYWE3S runs the TM18144 WLED with the level shifter. Just FYI the programming interface on the board is just to the side of the TYWE3S. See picture below. You can ohm this out to the actual pins of the TYWE3S to confirm...but on my board the red wire is for 3.3v, Yellow for Tx, Blue for Rx and Green is ground. To flash the TYWE3S with the wled esp01_1m build I just connected those four wires to my USB serial programmer and held a test probe connected to ground at GPIO0 pin temporarily just while plugging in the serial programmer to get it into flash mode. A second later you can just remove the probe/wire from GPIO0. You are now in flash mode. Hope that helps someone in that its best not to solder directly to the chip pins if possible. In this case Atomi provided a flash interface. Also to be clear I didn't use "mains" power to flash the TYWE3S as you did @esev, just the 3.3v from the serial programmer (and swapping the Tx and Rx wires between the programmer and TYWE3S of course).

How did you get it working? I loaded the precompiled version you have and the processor on the blard constantly dumps with reset 4 and reset 1 errors

[moriahmorgan]

I confirmed my Atomi String lights work with the 0.12.1-b1 build and changing the refresh rate from 380 to 350 on a NodeMCU and ESP-WROOM-32. I had to set the number of LEDs to 19 (actually 18 LEDs but there was a TM1814 on the original controller board now being bypassed). Also to get all LEDs to light properly I set the start to 1 and count to 18 in the LED setup UI page. Did anyone else have a different setup to get all LEDs to work?

Glad to hear the TYWE3S runs the TM18144 WLED with the level shifter. Just FYI the programming interface on the board is just to the side of the TYWE3S. See picture below. You can ohm this out to the actual pins of the TYWE3S to confirm...but on my board the red wire is for 3.3v, Yellow for Tx, Blue for Rx and Green is ground. To flash the TYWE3S with the wled esp01_1m build I just connected those four wires to my USB serial programmer and held a test probe connected to ground at GPIO0 pin temporarily just while plugging in the serial programmer to get it into flash mode. A second later you can just remove the probe/wire from GPIO0. You are now in flash mode. Hope that helps someone in that its best not to solder directly to the chip pins if possible. In this case Atomi provided a flash interface. Also to be clear I didn't use "mains" power to flash the TYWE3S as you did @esev, just the 3.3v from the serial programmer (and swapping the Tx and Rx wires between the programmer and TYWE3S of course).

How were you able to disassemble the controller? I have tried every way I can think of, and all of them failed.

[apop880]

@blacktirion @makerglenn

Same question. Just picked up a couple of these and trying to flash, and I'm stumped as far as how to best crack open the box to get to the controller.

[esev]

I used a dremel tool to cut along the seam.

This is likely a much cleaner solution https://www.youtube.com/watch?v=Z0krTGssXFA&t=200s

[timgray]

I used a 2 pound sledge and whacked it on the seam. The welded seam split cleanly around most of it, then used a flat head screwdriver to pop off the rest.

[oramirite]

Sorry for the slightly off-topic question here... but do these Atomi string lights just work now? Those disassembly and flashing instructions posted by @esev and @makerglenn are AMAZING- but being a bit noobish myself, I can't really tell if additional modifications are ultimately necessary to make it work. It seems like as long as my lights have the same TYWE3S chip then I can just flash the latest ESP32 version of WLED, skip the first LED, reboot, and be good to go?

I was able to get 2 of these Atomi strings enrolled in the Tuya app, so my plan was to try tuya-convert to change over to Tasmota and then ultimately WLED without having to open them at all. The hostname on the strings are "ESP_C357F2" and "ESP_C2F414" so I'm hoping this means they are ESP32's which I assume means they're TYWE3S chips.

If this doesn't work, can I just open them up and follow the same procedure as above? I've flashed devices before, I just want to make sure I'm not in for more than I'm anticipating or end up bricking the lights.

This was a wonderful thread to find - funny to see so many people working on this during the holiday last year, based around these same Atomi lights :)

[esev]

I was able to get 2 of these Atomi strings enrolled in the Tuya app, so my plan was to try tuya-convert to change over to Tasmota and then ultimately WLED without having to open them at all.

That's quite clever! I didn't go that route, but it seems very reasonable that it would work.

The hostname on the strings are "ESP_C357F2" and "ESP_C2F414" so I'm hoping this means they are ESP32's which I assume means they're TYWE3S chips.

TYWE3S is an ESP8266 with 2MB of flash. If you're compiling in PlatformIO, default_envs = codm-controller-0.6 should work (that's what I used).

If this doesn't work, can I just open them up and follow the same procedure as above?

If you've flashed devices over serial/UART before (with a USB adapter, possibly), then this should be straightforward. There weren't any surprises as far as I remember.