I’m testing a RadioShack TM1803 Tricolor LED strip, model 2760339, that may or may not be fried. I’m trying to see if it works using the following code on an Arduino Micro and FastLED 3.0.3, compiling using the “ino” Python-based build tools to drive the Arduino compilers from the command line:
In theory, this should animate a white light from the start of the strip to the end, with LEDs illuminating in groups of 3. But there are two obvious problems with the output:
LEDs set to CRGB::Black show up as medium-intensity red. I can make them more red if I want, or I can turn on the other colors and get white, etc., but I can’t get rid of the baseline red level.
The white LEDs move from the start to the end of the strip on average, but they’ll frequently skip a step, leap to another position, or otherwise do something odd. It’s hard to see the exact pattern in the video—the frame rate isn’t quite high enough. UPDATE: This was fixed by upgrading to the FastLED 3.1 branch.
If anybody sees this and says, “I know, you just need to fix X”, I’d be delighted by your help! But if nobody has any idea what’s going on here, I’m going to junk this strip. Thank you for your advice!
The TM1803s that radio shack sells are terrible. I’d say try the 3.1 branch real fast, as I made some changes on there.
Also, what arduino version are you using, and what version of avr-gcc? The timing code for that family of leds is fairly tight, and there’s some ugly stuff I did at the ASM level to make it work, but some versions of GCC mess it up.
Thank you for your help, and for an amazing library!
Upgrading to FastLED 3.1 fixes the animation problems: The white lights now proceed from the start of the wire to the end, with no jumping around out of sequence.
However, the red channel still seems to have a minimum value of about 50–75% intensity, even when set to CRGB::Black. As before, if I ask for CRGB::White, I get a nice, bright white. (However, if I insert the power pins without the data pin, the LEDs remain off—it actually needs some kind of signal from FastLED to get to the default red.)
Defaulting to a baseline red is obviously not ideal behavior, but it’s good enough that I can probably find something amusing to do with the strip.
As for the versions: avr-gcc (GCC) 4.7.2, Arduino software version 1.0.1, compiling on a Raspberry Pi host for electrical isolation and programming over USB. Powering the Arduino Micro and LEDs using a 12V 1A wall wart, which is theoretically enough if you believe the RadioShack docs.
And yes, I completely agree that this strip is junk. But it would be amusing to salvage it, and I appreciate your help tremendously.
Oh, one other complication: I’m compiling this code for the Leonardo, and uploading it to a Micro. Theoretically it’s the same board in a different form factor for almost all purposes, but it’s better to mention it.
If I get this working, I’m happy to add any appropriate notes to the wiki.
The problem may be the version of avr-gcc that you have actually, and it is messing up the writing of the first bit of data (which is why you always have a baseline of red). I haven’t done any testing with the 4.7 avr-gcc - I had to do a bunch to get it to work with the 4.8.3 avr-gcc that’s with the arduino 1.5.8 distribution.
Also you should be using Arduino 1.5.8 or 1.0.5 or later - I’m not going to put in a bunch of effort/work into back supporting (gcc’s asm support is problematic enough as it is).
Thank you for your help! And I certainly don’t think you should put time into supporting obsolete setups; you’ve already helped me far above and beyond the call of duty as is.
If I get this working, would it be useful for me to write up some notes or add something to the wiki so other people don’t bug you about these issues in the future?
OK, after much messing around, here’s what I’ve learned:
Use the FastLED 3.3 branch.
Compile using an official, up-to-date WIndows version of the Arduino IDE.
Skipping either of these will most likely result in display errors. The RadioShack strip requires very precise assembly-language timings, and using the wrong version of avr-gcc will result in incorrect colors, bad timing, etc.
Or better yet, just buy Adafruit dotstar strips if you want to compile on Linux. They’re cheaper than the RadioShack strips, they offer per-LED control, and they’re not sensitive to I/O timing.
A huge thank you to Daniel Garcia for all his help.
I’m trying FastLed library on latest Arduino 1.6 (Linux x64) and the black colour is red. Is there any solution to this problem or switch off LED’s?
What can I check?
Other colours seems to be fine.
Definitely try compiling under Windows or MacOS if you have easy access. Certain LED chipsets require precise assembly-language timing to work correctly, and depending on what version of avr-gcc you’re running on Linux, it may be messing up the timing while optimizing.
If you want to compile on Linux, I’d recommend looking into Adafruit “dotstar” LEDs, which use 4 wires, but which are also much more robust about bad timing. Just make sure you give them 5V, that you connect the LED ground to the microcontroller ground, and that you slap a big capacitor across the power inputs. Actually, all that applies for the WS2812 as well, plus you probably want a resistor between the microcontroller’s data pin and the first LED—the LED controllers are tempermental, and you may want to see the Adafruit tutorial: https://learn.adafruit.com/adafruit-neopixel-uberguide/best-practices
In my experience, most visual glitches seem to involve bad timing or an insufficiently paranoid circuit.
