I’ve got a really funny situation with some WS2811 ‘string’ lights.
I was getting funny results, till someone reminded me to common ground everything (duh!) but now, it’s just strange.
My lights seem to be adding red to everything.
I have some test code that lights the whole 50-led string in sequence: Red, Black, Green, Black, Blue, Black - with a 1000ms delay between.
What I get is Bright Red, Red, Purple, Red, Funny Green, Red.
So when I am telling the lights to turn off, they are turning red.
Anyone seen this before? I have tried all combinations of RGB/GRB/BGR, etc.
I have a print statement showing the colour that should be shown, and apart from Black showing a red led, they match - so when it should be red, red is printed on the serial monitor.
It’s making for some strange effects.
I would like to turn the red off…
What are you driving them off of - arduino or a teensy 3 or a due? Sounds like the chips aren’t reading the signal cleanly and so some bits are getting skipped and the data is sliding around.
If it’s an arm chip (due/teensy3) you may need to look into putting a level shifter to shift the data signals from 3.3v to 5v.
Sorry Daniel. An Arduino Nano.
I’ve tried two different strings - same result.
The signal seems rock-solid - in that all the red leds stay red, all the green stay green, all the blue stay blue, but the red LED is always on - when you call ‘Black’, it comes up red.
I could understand it being a faulty bit in the string somewhere, but I just wired in a new string and the same thing happens.
Curioser…
Aha! I just loaded the NeoPixel example ‘strandtest’ and it works perfectly normally.
I must have done something weird with FastLED.
Found it - I didn’t have FastLED Master loaded - just FastLED2.1
I trashed Arduino and all my settings, reinstalled it and tried FL2.1 and got the same result.
I reinstalled FL-master and everything is now working perfectly.
Hey @Daniel_Garcia there’s definitely something funny with 2.1 - I reinstalled it and ran the RGB test and ended up with red, a sickly green and pink/purple.
Without changing any hardware or source code, If I reload the F’Led master, the RGB test works normally.
(Thanks for the sleuthing and diagnostic help!)
Are you using then Arduino “delay()” or “FastLED.delay()”?
If you’re using ours, try switching to the basic Arduino delay. With a 50-pixel string, FastLED might be updating too fast. I think.
If you’re using the basic Arduino delay, this is ponderous, man. Really ponderous.
I read your post Mark, and my shoes started to squeak. 
Do you use the Arduino 1.0.6 Version? I installed a newer one and tried fastled and also got strange effects. Not even calibrate worked on my strips.
I uninstalled aurduino and installed “old” Version and … It worked.
Huh, I have only tried 1.0.6 with teensy 3.x - I know that 1.5.7 introduced compiler changes that mess with the library’s asm for hand timed code - I wonder if 1.0.6 includes those as well, now?
OK - I am running 1.5.8. I will go back and try an earlier (1.5.6) version
There’s a warning at the top of the readme file to not use 1.5.7 and later of Arduino:
“IMPORTANT NOTE: If you are building for AVR based systems, please do not use any version of the arduino IDE after 1.5.7 yet. It messes with some of the asm output which will cause you problems.”
I feel like I should put something in the code that completely breaks compiling under 1.5.7 or later.
Just checked in code to the 2.1 branch that will forcibly fail compilation if you’re building for AVR and using arduino 1.5.7 or later until I can fix it.
Sorry Daniel. readme files are like those tickets they have on mattresses 