Hello,
I have received new LED strips with TM1914A IC chips on it. I tried to change the LED type with every provided LED types on WLED LED configuration to drive the LEDs, but was unsuccessful. I also tried some libraries provided from FastLED, but they did not work too. I was only able to drive them with Tuya controller, which has not so many features as WLED. Could you please help me find out the reason why ESP32 can not drive TM1914A IC chips? Does it needs some special library? or some predefined data exchange frequency?
Thank you in advance for your support
the Ccontroller got the same Specs as of the WS2815
did you turn off and after some sec repower the WLED with the WS2815 setting this shoudt work
I changed the configuration but there is no possibility to save it, I press save but it does not react. Seems like it does not save only with 12mA (WS2815) configuration applied.
change also grb to rgb the power consumtion is only for internal calculation
the 800kHz shoudt work
to find this out you may need to use a UNO with fastrled and a simple script to get more infos on how the LED Controller racts
DID you use a levelshifter as this Stripes need at least 4V to get the data throu the first 2Pixels as backup is full on the 5V requirerment 4.95 maybe failing on this line
the datasheet saying that the DIV between DataIn and Backup is lower then 20mV to switch to backup Data
Why at all are <you on this Stripe chip setup
is it the Data cable length at 200Feet you neeed
I changed the color order but that did not help. I am using the controller ordered from this website
https://shop.myhome-control.de/ABC-WLED-Controller-Board-5-24V/HW10015
I guess it already has logic level shifter on it, as I tested with other 24V LED strips with other IC chips, mostly WS28xx and the controller works.
The LED strip with TM1914A IC chip I tested with Tuya controller ordered from this website and it works.
the LED Stripe on the Controller is a SPI
so use either WS2801 ot APA102
in the Config go for GPIO16 as DATA
and GPIO12 as CLK
the clockspeed set to slow
#and only go for 3LED for checking things
CHECK the Settings below MAIN WS2801 try the WS2811 first
After Saving repower the Module
and if nothing lights up go to next in the second list
I tried with the configuration which you suggested, I had already tried that configuration before but as before so now it does not light up. So as I understand WLED also supports SPI communication.
From what I can tell looking at the datasheets floating around, the TM1914a chip allows for 3 different “Modes”:
- Read LED data on Din and ignore FDin (like WS2812)
- Read LED data on Din and use FDin as a secondary incase of pixels failure (like WS2815)
- Read LED data on FDin and ignore Din (sort of WS2812, but different input pin)
What makes these chips different is that you can set the Mode you want with an initial configuration byte(s) right before the main data stream statrs. After that you just send data as usual.
I think the LEDs default to WS2812 mode if there’s no initial configuration at LED power up.
So, it may be worthwhile to power up the LEDs with no data line attached then connect the data line from WLED to the powered string. That way you can try different WLED protocols to try and match what the string is expecting.
Doing it normally, WLED tries to set the string to it’s startup colour (or black) and the initial colour data is misinterpreted by the LEDs as Mode data.
Thank you for your response, I tried your suggestion, but that also does not seem to be the case. I would ask the supplier if there is the possibility to develop new LED strip with WS28xx IC chip, but that would may cost me some money. The product I displayed is already developed so finding suitable controller with WLED capabilities would be cheaper solution. If someone can help me by testing this Type of LEDs I could send several prototypes to you via Post throughout Germany. I thought maybe the level shifter is not the right one for my application used by ABC Controller.
Are you sure you have the controller right?
The white board appears to have a 4 wire interface, normally that means clock and data?
How is your working controller configured?
If you have a multimeter, check that the voltages on each wire looks the same on both controllers. If you have an oscilloscope, even better.
WLED uses NeoPixelBus to drive the pixels. But not all the LEDs that NeoPixelBus supports have been exposed in WLED.
NeoPixelBus does support TM1914, you need to use the specific feature for it when you construct it, like…
NeoPixelBus<NeoRgbTm1914Feature, NeoTm1914Method> bus(pixelCount, pixelPin);
...
bus.Begin();
bus.SetPixelSettings(NeoTm1914Settings()); // use default config, must be called
The TM1914 require that “header” config to be sent before the pixel data, so they are not directly compatible with any other chips. The NeoRgbTm1914Feature will enforce this. The common method NeoWs2812xMethod should also work with this specific feature.
NeoPixelBus<NeoRgbTm1914Feature, NeoWs2812xMethod> bus(pixelCount, pixelPin);
2 Likes
I will be requiring alpha/beta testers. Contact me on Discord.
I have just tested the LEDs with your mentioned library and played with the provided example codes. But I met some problems. The configuration only works with NeoTm1914Method, but something is wrong with the communication, as not the proper code is supplied to TM1914A chip, looks like LEDs do what they want. The LEDs light up and that is already something. Thank you. I am trying to create some effect but the library speaks differently than I think.
If you want to discuss issues with using NeoPixelBus directly, I suggest starting it in the discussions area for it (Makuna/NeoPixelBus · Discussions · GitHub).
NeoPixelBus exposes very low level but flexible animations support, requiring some knowledge to achieve results. Using it to make sure we are correctly driving your LEDs is the top goal, thus WLED can then be relied on for its animation support knowing it’s not a low-level communications support issue.