Support for TM1914

[oraclesod]

Currently NeoPixelBus supports TM1814, comparing the datasheet to the TM1914, there seems to only be a few differences, specifically white channel support, Different OUT PWM output frequencies and Propagation delay times. Beyond these they seem to be the same

Would anyone be able to make the changes to allow the TM1914 ? I've attached its datasheet, but I'm not very good at coding so not sure ill be able to do this myself :(

TM1914A_V1.1_EN.pdf

[Makuna]

The initial strip data setup is completely different. The TM1814 allows setting the current level for the RGBW while the TM1914 seems to just set how/which input pin is used.

"1) 0xFFFFFF_000000:
The chip is configured as normal operating mode. In this mode, it is defaulted for the first time that DIN
receives display data. When the chip detects that this port has signal input, it will always maintain reception by
this port. In case no data is received for more than 300ms, it will switch to that FDIN receives display data.
When the chip detects that this port has signal input, it will always maintain reception by this port. In case no
data is received for more than 300ms, it will switch to that DIN receives display data again. DIN and FDIN
switch in a circulatory way to receive display data.
(2) 0xFFFFFA_000005 command:
The chip is configured as DIN operating mode. In this mode, the chip only receives the display data input from
DIN port and FDIN port data is invalid.
(3) 0xFFFFF5_00000A command:
The chip is configured as FDIN operating mode"

Since I do not have any of these, I could not test it and would have to rely on you to test it. This would mean that you understand how to use GitHub to get a branch of code. Is this something you could do?

[oraclesod]

Thanks for the quick reply @Makuna

Sure thing, I can pull the code, add it and test it.

[Makuna]

What platform do you use? ESP32? Esp8266? Mega2560?

[oraclesod]

Im using ESP32, specifically the ESP32-WROOM-32

[Makuna]

Please get the TM1914 branch and give it a try.

https://github.com/Makuna/NeoPixelBus/tree/TM1914

use NeoPixelBus<NeoRgbTm1914Feature, NeoTm1914Method> strip(PixelCount, PixelPin); as a guide for the feature and method.
remember in setup to call strip.SetPixelSettings(NeoTm1914Settings(NeoTm1914_Mode_DinOnly));' before you call strip.Begin()`

NeoTm1914_Mode_DinFdinAutoSwitch,  // Switches between DIN and FDIN on any signal pause > 300ms
NeoTm1914_Mode_DinOnly, // DIN input pin used exclusively 
NeoTm1914_Mode_FdinOnly  // FDIN input pin used exclusively 

[oraclesod]

Ok i have just tested with all 3 switches using the basic NeoPixleTest, I have 30 pixels connected (break points are every 6 pixels)

I was connecting the data wires (DO and BO) to GPIO2

with NeoTm1914_Mode_FdinOnly set:

• DO: Green in the first 6 pixels and by red in the second 6 pixels and blue in the last 3 pixels, but just flashes on for 1 second
• BO: Blue in the second set of 6 pixels for 1 second
• DO+BO: Green in the first 6 pixels and red in the second 6 pixels and blue in the last 3 pixels, but just flashes on for 1 second

with NeoTm1914_Mode_DinOnly set,

• DO: Red in the second set of 6 every on cycle for 1 second, and randomly get blue in the 3rd set of 6 for 1 second
• BO: Red in the first set of 6 pixels every on cycle for 1 second
• DO+BO: Red in the first two set of 6 pixels every on cycle for 1 second

with NeoTm1914_Mode_DinFdinAutoSwitch set:

• DO: Green in the first 6 pixels and red in the second 6 pixels and blue in the last 3 pixels, but just flashes on for 1 second
• BO: red in the first set of 6 pixels for 1 second and blue in the second set of 6 pixels for 1 second
• DO+BO: Green in the first 6 pixels and red in the second 6 pixels and blue in the last 3 pixels, but just flashes on for 1 second

Each time the lights are on for 1 second, but i guess based on the delay of 5000 it should be 5.

// NeoPixelTest

#include <NeoPixelBus.h>

const uint16_t PixelCount = 30; // this example assumes 4 pixels, making it smaller will cause a failure
const uint8_t PixelPin = 2;  // make sure to set this to the correct pin, ignored for Esp8266

#define colorSaturation 128

// three element pixels, in different order and speeds
//NeoPixelBus<NeoGrbFeature, Neo800KbpsMethod> strip(PixelCount, PixelPin);
//NeoPixelBus<NeoRgbFeature, Neo400KbpsMethod> strip(PixelCount, PixelPin);

NeoPixelBus<NeoRgbTm1914Feature, NeoTm1914Method> strip(PixelCount, PixelPin);

RgbColor red(colorSaturation, 0, 0);
RgbColor green(0, colorSaturation, 0);
RgbColor blue(0, 0, colorSaturation);
RgbColor black(0);

HslColor hslRed(red);
HslColor hslGreen(green);
HslColor hslBlue(blue);
HslColor hslBlack(black);


void setup()
{
   ​Serial.begin(115200);
   ​while (!Serial); // wait for serial attach

   ​Serial.println();
   ​Serial.println("Initializing...");
   ​Serial.flush();

   ​// this resets all the neopixels to an off state

   ​strip.SetPixelSettings(NeoTm1914Settings(NeoTm1914_Mode_DinFdinAutoSwitch));
   ​
   ​strip.Begin();
   ​strip.Show();

   ​Serial.println();
   ​Serial.println("Running...");
}


void loop()
{
   ​delay(5000);

   ​Serial.println("Colors R, G, B...");

   ​// set the colors, 
   ​// if they don't match in order, you need to use NeoGrbFeature feature
   ​strip.SetPixelColor(0, red);
   ​strip.SetPixelColor(1, green);
   ​strip.SetPixelColor(2, blue);
   ​
   ​strip.Show();


   ​delay(5000);

   ​Serial.println("Off ...");

   ​// turn off the pixels
   ​strip.SetPixelColor(0, black);
   ​strip.SetPixelColor(1, black);
   ​strip.SetPixelColor(2, black);
   ​strip.Show();

   ​delay(5000);

   ​Serial.println("HSL Colors R, G, B...");

   ​// set the colors, 
   ​// if they don't match in order, you may need to use NeoGrbFeature feature
   ​strip.SetPixelColor(0, hslRed);
   ​strip.SetPixelColor(1, hslGreen);
   ​strip.SetPixelColor(2, hslBlue);
   ​strip.Show();


   ​delay(5000);

   ​Serial.println("Off again...");

   ​// turn off the pixels
   ​strip.SetPixelColor(0, hslBlack);
   ​strip.SetPixelColor(1, hslBlack);
   ​strip.SetPixelColor(2, hslBlack);
   ​strip.Show();

}

[Makuna]

This sounds like your strip is actually using six RGB LEDs connected to a single TM1914; as it is setting six LEDs to a single color. Please check your strip circuit to confirm. Make sure your strip voltage is correct.

Simplify the sketch, get rid of the HSL stuff.
Things to try:
Try another pin than GPIO2.
Try a level adjuster between GPIO pin and the strip input (ESP32 is 3.3v and the TM1914 requires the data pin levels to be -0.4～VDD+0.7)
And lastly, I do wonder if the chip requires a constant update otherwise its clears its setting. So get rid of the set to black and the delays and just loop calling set the colors and update.

[oraclesod]

I have cleaned out the HSL stuff from the code, these results are all with NeoTm1914_Mode_DinFdinAutoSwitch and both DO and BO connected

When i remove the set to blacks and the delays: 1st bank of 6 are green, second bank are red and 3rd bank are blue and holds steady, adding back just one delay, with no black, they flash on for 1 second and off again for 5

GPIO16 - red in the first 6 and blue in the second 6 (also flash the same way as GPIO2)
GPIO13 - Same as GPIO2, occasionally changes to red in the first 6 and blue in the second 6 or red in the first 12 and blue in the third 6

I don't have a level level adjuster, will order one this weekend for further testing. Happy to do more testing if you want before it arrives. Let me know if there is anything else we can try prior to it coming

I have included a pic of a bank of 6, when i use one of the cheap SP108E units, it can control each LED separately if that helps.

[Makuna]

What do you mean each LED that the SP108E can control? In your picture, there are six RGB leds but only one TM1914; so this means those six should always match and will be considered one NeoPixel (as the library addresses the TM1914 not physical LEDs).

By DO and BO, you actually mean DI and BI right? DO stands for data output, BO stands for Backup ouput; DI is Data input and BI is backup input (BI = FIN from the spec sheet). So you should be connecting your ESP32 to the inputs not the outputs. If you connect on the left in the picture, that would be DI/BI.

You are connecting the GNDs between the ESP32 and the Strip correct?

It should show 6 red, 6 green, then 6 blue without the delays being present and only setting it to RGB (no setting to black).

Then if you JUST add a 5 second delay, if it acts differently then I suspect the TM1914 has another feature they don't explicitly mention but some wording hints at. But let me know.

[oraclesod]

Sorry that was my mistake, yesterday was the first time testing and working with a short strip, up to date ive been using 10m of it, and never noticed that banks of 6 pixels change together, but that makes sense as you say there is one IC per 6 LED's.

Yep i have it wired the right way round to DI and BI, not sure why i chose to write the output pin vs input, but yes the wiring is attached via the input pins to the ESP32. Yep i have connected the ESP and strip to the same ground wire. Im powering the strip from a 24v DC inverter and the ESP32 from my laptop via USB at the moment ( i have a 24v->5v to use with it later)

The strip is a GRB not RGB (from what ive read online)... and i get 6 green, 6 red then 6 blue.

i suspect the level adjuster may help with the instability between different wiring setups i'm seeing, and occasionally not working on some of the wiring setups... I'll still order one and test that too.

If i add a single 5 second delay with only the set colours as on, i still get 1 sec on and 5 sec off

[Makuna]

The color order from the spec shows it as RGB, but its easy for me to add the GRB order as a feature. If you pull the latest from the branch you will get a NeoGrbTm1914Feature you can use.

Try the NeoEsp32Rmt6Tm1914Method method and see if its different.

I am worried that you will have to update the signal at least once a second otherwise it turns off. There are a few "hints" at this in the spec but it does not call it out specifically. The SP108E could be constantly sending the signal over and over, while my library only sends it once when you call "Update". This is unusually for these types of LED controllers.

[Makuna]

Did you get a chance to use the latest GRB feature?
Switch you sketch to make sure to call Update at least once a second (or even 300ms) and see if it retains the color.

[oraclesod]

Sorry for the late reply on this, i haven had much time this past two weeks to look at this again.

So pulled the latest code from github and applied the script below.... The colours look to be correct now, however, I also reduced the delay to 400 to test with.... this is a video of the result:
https://www.dropbox.com/s/jsnffsd7vlq0bt4/IMG_0923.MOV

// NeoPixelTest

#include <NeoPixelBus.h>

const uint16_t PixelCount = 30; // this example assumes 4 pixels, making it smaller will cause a failure
const uint8_t PixelPin = 4;  // make sure to set this to the correct pin, ignored for Esp8266

#define colorSaturation 128

// three element pixels, in different order and speeds
//NeoPixelBus<NeoRgbTm1914Feature, NeoTm1914Method> strip(PixelCount, PixelPin);
NeoPixelBus< NeoGrbTm1914Feature, NeoEsp32Rmt6Tm1914Method> strip(PixelCount, PixelPin);

RgbColor red(colorSaturation, 0, 0);
RgbColor green(0, colorSaturation, 0);
RgbColor blue(0, 0, colorSaturation);
RgbColor black(0);

void setup()
{
    Serial.begin(115200);
    while (!Serial); // wait for serial attach

    Serial.println();
    Serial.println("Initializing...");
    Serial.flush();

    // this resets all the neopixels to an off state
    strip.SetPixelSettings(NeoTm1914Settings(NeoTm1914_Mode_DinFdinAutoSwitch));
    strip.Begin();
    strip.Show();

    Serial.println();
    Serial.println("Running...");
}


void loop()
{
    delay(400);

    Serial.println("Colors R, G, B, W...");

    // set the colors, 
    // if they don't match in order, you need to use NeoGrbFeature feature
    strip.SetPixelColor(0, red);
    strip.SetPixelColor(2, red);
    strip.SetPixelColor(4, red);
    //strip.SetPixelColor(1, green);
    //strip.SetPixelColor(2, blue);
    strip.Show();

//    delay(5000);

//    Serial.println("Off ...");

    // turn off the pixels
//    strip.SetPixelColor(0, black);
//    strip.SetPixelColor(1, black);
//    strip.SetPixelColor(2, black);
//    strip.Show();

}

[oraclesod]

So just playing with the delay a little more..... at 370 i get a slight flicker but the sequence is stable and the colour doesn't switch between different spots... at at 350 i get a very rare flicker

[Makuna]

Ok, try 300ms. This number shows up in the spec sheet and makes it sound like if it doesn't get a signal in that time it resets. This isn't good as it requires the sketch writer to maintain the updates to keep the strip colors.

[oraclesod]

300 holds perfectly steady....

Yeah i do agree this isn't brilliant... i'm a little disappointed in this strip (this signalling issue along with not noticing that it was one chip per 6 leds)... the reason for purchasing this one (and i have a lot of them) was because its a RGB+CCT strip, the RGB we have looked at, the CCT is not addressable but allows the spectrum of white... I primarily (and regularly) use the whites and in different temps depending on the time of day.... the RGB is more for special occasions and was hoping to code some fun stuff for it, this was the only strip i could find that had addressable RGB that could do white 3000k-6500k as well...

Im strongly thinking about pulling it all down and trying with another chipset if i can find something

Happy to keep working on this though... I have access to an oscilloscope (although don't know how to use it), but could test out one of the controllers i have to see how it works there too....

[Makuna]

This is good enough. I merged this into the main branch as it is. The use of the TM1914 method will have the caveat that the sketch writer MUST call Update() at least every 300ms as per required from the TM1914 chip.

[Makuna]

v2.6.4

[mattk926]

300 holds perfectly steady....

Yeah i do agree this isn't brilliant... i'm a little disappointed in this strip (this signalling issue along with not noticing that it was one chip per 6 leds)... the reason for purchasing this one (and i have a lot of them) was because its a RGB+CCT strip, the RGB we have looked at, the CCT is not addressable but allows the spectrum of white... I primarily (and regularly) use the whites and in different temps depending on the time of day.... the RGB is more for special occasions and was hoping to code some fun stuff for it, this was the only strip i could find that had addressable RGB that could do white 3000k-6500k as well...

Im strongly thinking about pulling it all down and trying with another chipset if i can find something

Happy to keep working on this though... I have access to an oscilloscope (although don't know how to use it), but could test out one of the controllers i have to see how it works there too....

Wondering what you settled on. I'm looking at the same use case and came across that same tm1914 24v addressable RGBCCT strip and wondering if it is worth while or if you found a suitable replacement without that tm1914?

[dschaulet]

Hi

v2.6.4

Hi Michael! How are you?

I´m trying to use the lib on an Arduino Leonardo board and TM1914 RGB strip. I´m receive the above error:

'NeoTm1914Method' was not declared in this scope

I take a look on the source code and just see methods to ESP boards, could be it´s my problem with the Leonardo board?

Thanks!

[Makuna]

@dschaulet It is better to ask questions in the Discussion area rather than the issues area. But the answer is try NeoTm1914InvertedMethod. BUT, this will not work if you directly connect the 1914 to the device. This is due to the 1914 requiring its "normal signal" to inverted from a normal NeoPixel signal. So this method would output an inverted signal as far as the 1914 is concerned, so you need to add hardware to invert it. This can be accomplished with a transistor and also give you the ability to level shift the signal (if your Leonardo is running at 3.3v) to 5v.