I have been working on a stage design project for since spring which has recently been deployed. There are six panels, each about 2’ x 7’ with 448 WS2812B LEDs on each (2688 total). Each panel is controlled by an NodeMCU ESP8266 12E and uses the FastLED library. The NodeMCUs are controlled by a Windows application that sends out UDP packets with instructions on what pattern to display. The short video shows the panels (3 on each side of a projection screen) implementing a graphical spectrum analyzer.
I’ve got a couple of questions - I have basically have a strip of 448 LEDs on each panel, and on occasion a panel will wig out and start to display random pixels from a given LED to the end of the strip, or stop updating from a given LED to the end of the strip. It can do this intermittently or stick that way until I turn off the power. If the failure repeats it often starts at the same LED. When I look at the data line with a scope it looks good going into the last LED that’s doing what it’s suppose to do, but between there and the next LED I either see nothing (downstream LEDs are not updating), or pretty random data (downstream LEDs are showing random colors).
Each strip has it’s own power connection (5v feed from a single bus 40amp supply). Voltage level at the end of the 64 LED strip look good. The data signal from the NodeMCU goes through a level shifter before going to the first LED on the panel.
If I increase the FASTLED_INTERRUPT_RETRY_COUNT should I see better results?
I don’t believe I can set FASTLED_ALLOW_INTERRUPTS to 0 since I need to receive UDP packets on when to stop or change the pattern.
Does the FASTLED library account for whether the NodeMCU is running at 80 or 160 Mhz?
Can you trade mode MCUs to see if the problem follows the node controller or if it stays? I would check and make sure pixel grounds are good between all power ground sources to that nodeMCU. Any differential grounds will cause some funky intermittent results causing sections to act out.
Are the nodeMCU’s powered by the USB or are they powered by the pins?
@Chris_Rees Moving NodeMCUs or trying another one is something I can try although not as easily now that the panels are being used. When I was building them and got one that started to act up I would cycled the AC to the power supply and it would be good for awhile and then come back (starting at the same LED). More often than not it’s intermittent which makes it difficult. As I mentioned, the failures where the rest of the string stopped updating I was able to look at the data signal and it was usually zero.
As for grounds - each strip has it’s own ground wire, they seem to be well connected. The failures all occur somewhere other than the beginning or end of the strip - and often times it’s at a splice in the strip. Those I re-soldered and it seems to fix them. When the failure wasn’t at a splice, I would splice in a two new LEDS (replacing the last working one and first failing one). That seems to always fix that failure.
The NodeMCUs are powered by the 5v pins (no USB connection).
Yes - I have a 5v 40amp power supply for each panel. It’s a single bus supply but has 3 taps (3 5v and 3 GND). One tap powers 3 strips (one connection to the supply and branches to each strip), one powers two strips, and one tap power 2 strips and the NodeMCU. So everything shares a common ground back at the supply.
I did use sockets for the NodeMCUs, so they are easy to swap/replace. I’ll have to number each and try some swapping next time I see a failure.
I’m still curious about my question on the NodeMCU clock speed and the FastLED library - does the library account for processor speed. Is it better to run 80Mhz rather than 160Mhz? missing/deleted image from Google+
My guess is that it’s the interrupts screwing you. I have been fairly much exactly here where you are, and three wire LEDs are a bad choice if your microcontroller is doing anything other than FastLED. I know this is unfortunate news. It was eventually solved in my case by having a different microcontroller doing the communication (in this case midi) and then talking serial to the FastLED micro.
@Robert_Atkins The NodeMCU is only watching for UDP packets on a specific port and writing the LED strip. It only gets a UDP packet when it’s told to change what’s it’s doing (expect in the case where its doing the spectrum analyzer in the video clip I posted).
I would expect an interrupted write of the LEDs to look like part of the strip doesn’t change/update. If the NodeMCU stops writing data the last LED to get data doesn’t have any data to pass on so the rest of the strip shouldn’t change, not start displaying random colors. Right? To me it seems like the small on chip controller wigs out somehow, or there’s a signal integrity problem between the two chips.
I think one way to rule out bad pixels is to temporarily bypass the strip in question and connect it to a known good strip and see if the problem stays. Switching MCU will verify if MCU is good, the only other possibility is voltage drop issues. One way to test that is give that strip a dedicated power source and see if if there is a difference. Other than that my ESP8266 skills are not savvy to point out if your dealing with interrupt issues etc.
You indicated that your using udp to communicate with it. Are you streaming to it like artnet or sacn e1.31?
@Chris_Rees The only time I’m streaming data to the NodeMCUs is when the panels are doing the spectrum analyzer. In that situation there’s a seventh separate NodeMCU dedicated to sampling the audio, doing an FFT, and then sending out frequency counts via a UDP broadcast packet. I haven’t seen any flickering when running like that oddly enough.
But otherwise I send a UDP packet to tell the panels to do a fire pattern, or slowly fade between to colors, there’s no streaming of data other than the command packet on what pattern to run. All the code to do the pattern is running local on the NodeMCUs. It’s in this situation that I’ve seen failures.
Very interesting… I would think the high UDP traffic would be more of the issue (increases conflicts with interrupt). but sounds like it’s not the case at all… and just to clarify it’s any panel that will do this and usually at the same pixel area?
@Chris_Rees I would think the UDP traffic would cause problems as well, but if all the interrupt would do is stop the writing of the data then it might be hard to know when that happens when what’s being displayed changes so rapidly.
Out of the six panels I think three have never shown a problem. When I would get a failure it was one of two scenarios: either the strip would stop updating from a given LED to the end, or the strip would flash random colors from a given LED to the end. The failures didn’t happen right away, it would need to run the pattern for awhile. If I cycled the power to the panel when it was failing it would usually be okay after it came back on for awhile. If it started to fail again, it would be from the same LED downstream. That’s when I usually replace the last good LED and the first bad one (splice in a new piece of the strip) and usually things were good.
It’s just a odd intermittent failure I guess. I’m going to start tracking which NodeMCU is plugged into which panel and swap things around when it happens again. Hindsight I should have used a clocked strip I suppose.
Yup switch things around and narrow it down . I still question if there is a power issue. Not that you don’t have enough but Instead there is too much voltage loss the further on the strip and it’s borderline… do you recall what voltage your data line pulses High at and what the pixel supply voltage is at before the trouble area?
I don’t recall the exact values but, when I had a solid enough failure to take measurements the 5v reading was good at both ends of the strip (power connected on one end - each strip was 64 LEDs long (2.2m)). If the downstream LEDS were not updating, the scope showed 0v on the data line. When the downstream LEDs were showing random colors the scope showed data, but the voltage was less than 3v. So that kind of offers an explanation for both scenarios, the question is why at the particular point in the strip. I did have one failure with random colors where the last good LED was at the end of the strip and I had a data wire over to the next strip - a re-solder fixed that one. And I did have a couple mid-strip where there was a splice between the good and bad LED - re-solder appears to have fixed that one. but most failures are mid strip without a splice involved.
(Plus another bunch of posts from me around that timeframe.)
If I did it all again I’d try harder to use four wire 12v pixels, even though there were very good reasons I didn’t the first time around. (Four core stage-proof cable less than 2.5mm^2 is basically impossible to buy, as are four pole non-solder connectors.)
@Will_Tatam I use a GUI made with QtCreator that lets the user select options such as pattern, color, refresh speed. The application then sends a UDP packet that the panels catches, parse and implement. It’s not a factor when the panels start wiggling out.
@Chris_Rees@Chris_Rees The LEDs are being run at about 20% brightness. Probably a good idea to crank them and see if I can get a solid failure again. That many LEDs at 100% are dang bright.