WLED works perfect, until used in a Large Crowd

Hello,

I am new to WLED, but I have enjoyed learning about them recently. I was apart of a team that created a Light Show for our Local High School Band. We have 15 NodeMCUs controller 5v LED strips with 50 leds per strip. Any time we practice the show, it works perfect. However at the actual show, which is at halftime of football games, we get a lot of inconsistent performance. My gut tells me that is most likely has something to do with extra interference and possible network issues.

The problem seems like the UDP format is dropping packets. We will see some lights change, while others dont respond. The next synced effect usually does the same thing, but with different lights working. We have a wireless router connecting all of them on a local network. We tried the “Send 2 Notifications” trick and again, it seems to be very responsive at run throughs and practices. But in the football stadium is really unpredicable.

The props are moving throughout the show, so it needs to be wireless. I am considering running FPP on a Pi with xLights to see if that would make a difference. Thanks for your interest in our problem! I look forward to hearing about possible solutions.

Interesting and i would expect that on a wireless router might be worth taking a look at ESP-Now done here Discord

I would say you need dedicated router to use with your props. In that case you will avoid interference from high traffic. Also try to use network scanner to see what Wi-Fi channels is already in use and avoid them. Higher channels is better Wi-Fi signal performance. It looks like a basic things.

Oh that’s a great idea! We have a dedicated router with a password and hidden SSID. On game day though, there is a ton more traffic. Broadcasters, coaches headsets, even the stadium lights are on various wireless networks. I didn’t think about changing the channel. Do you have a recommendation for a WiFi scanner?

Unfortunately, I won’t be able to test until the next home game, but I feel really good about this solution. Thanks again!

Sounds like a cool project.

Yeah, protocol design should assume UDP is unreliable. Does/can the controller sending pattern commands that are known ahead of time, can the ‘show’ be ‘scripted’ into multiple ‘scenes’, so the script scenes are sent ahead of playback, or made available for NodeMcus to pull (MQTT). So the “Orchestrating” controller just sends UDP traffic containing just clock timing and scene identifier. Orchestrator sends regular heartbeat like time-scene packets. NodeMcus explicitly pulls when they haven’t received heartbeat. Stats about neglected NodeMcus gives you info/feedback about where to improve access points wifi coverage.

ESP Now mesh sounds cool too.

Maybe use transceivers operating on different non Wifi frequency(s) if unable to overcome Wifi congestion.

That did it! The Band had a competition today and I was able to get it working in time. I used Net Spot to scan the area and discovered more traffic on channel 1 and 11, so we choose 6. It worked perfect! Thanks for your help!!

That’s a good idea too! I’ll look into this as the show grows and evolves. Thanks for your interest!

Also might be worth looking into ESP-32 with ethernet, such as ESP32-POE - Open Source Hardware Board or Pre-Assembled QuinLED-Dig-Uno - quinled.info (needs an ethernet board add-on), and running ethernet to each of the locations, if you possibly can, to ensure a solid network connection.

I wouldn’t trust that one of the 2.4GHz channels will always remain clear enough.

The idea for an ETH enabled board is good except for:

Ohhhh…missed that, sorry.

Hm, maybe WLED/Arduino will support the ESP32-C5 soon, which has dual band WiFi6 (802.11ax). One hopes, although it’s a RISC-V core. Single core, 160 MHz. Don’t know how it compares to the current ESP-32 cores though, in terms of actual performance.