I could use your help. I’ve been mulling this issue over but I can’t seem to figure it out. Hopefully I’m posing in the right place.
I have an ambilight setup using an Arduino Nano and WS2812B LEDs. The setup works perfectly except at framerates above ~25. At higher framerates, the controller will occasionally ‘hiccup’ and display strange colors, usually green/cyan, on alternating frames and for a random number of LEDs. The ‘hiccup’ seems to happen almost at random - sometimes it will work for 30 seconds, sometimes it will work for an hour. The LEDs affected also seems to be somewhat random – it always affects LEDs starting at the end and moving towards the beginning of the strip. Sometimes it’s the last 20-30 LEDs, sometimes more. (Although as far as I can tell, the block is always continuous.) Resetting the Arduino fixes the problem immediately, even with the same data stream.
Just to make sure it’s a software issue, I’ve replicated the problem using all new hardware (Arduino, LEDs, power supply). PC and software are the same. The problem occurs using both genuine and knockoff Arduinos.
The program is a modified version of Adalight using FastLED. The PC software is Prismatik.
My original assumption was that this was a serial overrun, however testing with a custom 256 byte serial buffer (TX & RX) didn’t affect the problem. This seems like it has to be a memory issue of some sort, although I’m not sure where it occurs.
From my testing, here’s what I know:
Lower framerates and smaller LED #s do not cause the problem.
Sending more data than the # of LEDs (e.g. sending data for 20 LEDs with the Arduino only supporting 10) causes issues immediately.
The 256 ‘software buffer’ in the adalight code is never even close to overflow (bytesBuffered is never > 6). The only time a byte is stored and not immediately retrieved is when the header is waiting to be checked. Next step is probably to rewrite the code and test without the buffer.
Adding “Serial.println((char)c)” under the initial “if” statement where bytes are buffered will also cause similar issues at lower framerates, but only if a lot of data is sent.
At ~30 FPS, adding a delay greater than ~80 µs to the same “if” statement causes the issue immediately. A delay of ~70 µs or less causes no perceivable change.
Serial packets from Prismatik are correctly formatted, regardless of framerate setting.
The LEDs don’t have any issues running high framerate test patterns (i.e. not receiving color data via serial).
My only conclusion is that this is somehow linked to the amount of serial data, although I’m not quite sure how. Does anyone have an explanation?
Current code, in full, is attached.
Thanks for any advice!
LEDstream_FastLED.ino (6.41 KB)
Welcome to the forum.
Please read the first post in any forum entitled how to use this forum.
http://forum.arduino.cc/index.php/topic,148850.0.html then look down to item #7 about how to post your code.
It will be formatted in a scrolling window that makes it easier to read.
Placing code and images off forum makes it hard for notepad and other NON PC platforms to access.
D'oh! Thanks Tom. I've added the code as an attachment. Too large to fit in the post, unfortunately.
What are you using for a power suppy?
Have you monitored your power-supply voltage with a DMM while these problems occur?
Have you monitored the +5V with a DMM while these problems occur?
The dedicated setup is using a 10A +5V brick power supply, but for testing I’m using the +5V rail of a 430W PC power supply.
Test setup has 4.78V on the near end of the strip (closest to the malfunctioning LEDs) and 3.84V on the far end of the strip (closest to the data input). I should probably tie power to both ends, now that you mention it. Variance with the LEDs changing is within 0.1V.
I haven’t had the chance to test power on the dedicated setup. I’m still convinced this is a code issue, because everything works flawlessly unless the framerate is set higher than ~25 fps.
I also should’ve mentioned that the LEDs don’t have any issues running high framerate test patterns (i.e. not receiving color data via serial). I should add that to the original post.
Okay, but usual trouble shooting is to start at the power supply.
So you have enough power...
For everyone that is struggling with fixing the ambilight random flickering and the ambilight is made with ws2812b + Raspberry Pi + Arduino there is a few things that each separate one (or any combination of them) can fix the issue. I was struggling few months too. Tried every suggestion on the web (software and hardware), missing one thing that wasn't suggested anywhere. It was not included in any tutorial too. The fix in my case was connecting one of the ground pins of the Raspberry to the grounds of the Arduino and the strip (all of them grounded in the power supply V-). There wasn't any tutorial that was saying that they (3 of them) must have common ground. All suggestions were that I have to have common grounds on the arduino and the LED strip.
So, this is short list of things that may help:
- putting additional capacitor 1800uF 6V+ (and more) on the power supply V+ and V-
- putting resistor 470 Ohm directly or as much closer as it can be placed on the first LED DI (Data In) connector
- using short and thick wires to power the LED Strip to prevent voltage drop and supply enough amps for the LED Strip
- If the strip is longer (let say 150, 200 or 300 leds and more) power it on a few places along its length and even on the end. Measure the voltage in between 2 power connections to check if additional power connection is needed to fix the voltage drop.
- Calculate the Amps needed to feed the strip. Each LED consumes 60mA. When buying the power supply and choosing the right one for you, use this formula to calculate how much power in watts do you need: P(W) = I(A) × V(V). So lets say 300 LED multiplied by 60mA = 18 000mA = 18A. 18A multiplied by 5V = 90W - needed only for the strip! But hey, don't be scrumpy when buying power supply - buy 100W. And read the buyer comments under the product and make sure if it is good quality. You don't want to fire you house or damage electronics for hundred dollars, right?
- When testing the configuration is done and everything works amazing, don't forget to use good quality and more thicker cables. Avoid any use of solderless power, ground and data joints. It may lead to power and voltage drops, loose/no connection at all and we know that with the higher power comes the higher responsibility.
Welcome to the forum.
Thanks for the input, the OP didn’t reply and that was over 12months ago.
The fix in my case was connecting one of the ground pins of the Raspberry to the grounds of the Arduino and the strip (all of them grounded in the power supply V-). There wasn’t any tutorial that was saying that they (3 of them) must have common ground. All suggestions were that I have to have common grounds on the arduino and the LED strip.
Unfortunately the OP of the this thread did not provide a circuit diagram that would hopefully have shown that situation.
It is a general rule that if you are passing power and signals between devices, you must have a common ground to provide a return path for the output current and/or a reference point for any voltage level.
Also how you wire your power supply can make a difference, with LED arrays you need to have dedicated power wiring for the LEDs back to the power supply, and dedicated wiring for the controller. That is a star connection at the supply, rather than daisy chaining everything together.
Those are all good suggestions! Thanks for contributing.
Sorry for not responding before, I had figured out the issue and since few people were using WS2812B LEDs for ambilights at the time I didn't think others would find the information useful.
My power setup was fine, it turned out to be a bug in the code I was using. The original author re-used the circular buffer from the original Adafruit code but didn't take into account what would happen in the case of a byte mismatch; either due to an array size mismatch or a truncated frame when interrupts are disabled during the LED latch. I eventually rewrote the code to get rid of the circular buffer altogether.
I'll add that for longer LED runs (100+) using the WS2812B chipset, a common cause of flickering at high baud rates is not clearing the serial buffer after each frame. The Arduino buffers the header information (6 bytes) for the next frame, misses most of the color data due to the LED latch, and then because it already buffered the header will push junk to the LEDs for the next frame.
Those are all good suggestions! Thanks for contributing.
Sorry for not responding before, I had figured out the issue and since few people were using WS2812B LEDs for ambilights at the time I didn’t think others would find the information useful.
My power setup was fine, it turned out to be a bug in the code I was using. The original author re-used the circular buffer from the original Adafruit code but didn’t take into account what would happen in the case of a byte mismatch; either due to an array size mismatch or a truncated frame when interrupts are disabled during the LED latch. I eventually rewrote the code to get rid of the circular buffer altogether.
I’ll add that for longer LED runs (100+) using the WS2812B chipset, a common cause of flickering at high baud rates is not clearing the serial buffer after each frame. The Arduino buffers the header information (6 bytes) for the next frame, misses most of the color data due to the LED latch, and then because it already buffered the header will push junk to the LEDs for the next frame.
I am currently experiencing the same problem, but I am using raspberry pi zero w with Hyperion to get ambilight working from any HDMI input. I was wondering if you could please provide the updated code, so I could test it on my setup??? I have tried everything… nothing worked for me… :o :o :o :’( :’( :’(
Thank you a lot. I am going to give it a try. BTW what OS are you using for raspberry? I am currently using osmc, but maybe raspibian or something else would be better?
I've never built a Raspberry Pi ambilight, so I can't give any advice there.
I had the same thing and fixed it (although just on pc instead of raspberry). I have a long ledstrip (138 leds). With an arduino uno, the leds start to flicker randomly after led ~55-70 after a while (10, minutes or so). With the arduino nano, it flickers all the leds practically immediately. With an arduino mega, everything is fine. Depending on the length of your ledstrip, your arduino can or cannot handle it. More leds means larger packages, means you need a faster controller. Upgrade your arduino would be my tip. It was not needed in my case, but a Teensy had been recommended by a friend if you need to control more than 200 leds.
(Yes it's years later, but for anyone who comes across this, it may help).
@Petoodle, good point, thanks..