How to Troubleshoot Random Flashing in E1.31 Controllers (Updated for 2026)

Updated September 2026 for xLights, FPP and today's home networks.

From time to time customers report "flashing," brief interruptions of light output, or stuck pixels on their E1.31 controllers. We can't give one answer for every case because there are too many variables, but this post gives you concrete troubleshooting steps to track down the cause.

E1.31 (also called sACN), along with Art-Net, is just one part of a stack of systems that carries data from your sequencing software to your lights. Let's walk through each layer, from the lights up, and look at the likely causes and how to rule each one out.

1. Lights and power

Start at the bottom. Most E1.31 controllers have a built-in test mode that outputs a pattern straight from the controller, with no computer involved (check your controller's manual or web interface for its test function). This splits the problem in half: if the flashing happens in test mode, the problem is in the controller, lights or power, not the network or software.

Run the test at full white and watch for flashing:

• Flashing only at full white or bright, busy effects, but not on a single color usually means there isn't enough power for the number of lights.
• Minor under-powering shows up at the end of a run, where pixels drop below the voltage they need and glitch or go dark.
• Major under-powering makes the power supply shut off for a few seconds at a time due to over-current, and everything on that supply goes dark.

To check, set all pixels to full white and measure the voltage at the end of each run with a multimeter. A large drop from the start of the run points to a power problem. The fix is usually power injection or splitting the run; see our guide to lights, controllers and power.

2. The network

E1.31 controllers are devices on an Ethernet network, so the network itself can delay or drop data. Things to check:

• Wireless. If any part of the path is wireless (bridges, extenders, mesh, access points), switch to a wired connection for testing. We don't recommend running show data over Wi-Fi unless there's no alternative to a network cable. Wireless adds delay, loses more packets and is subject to interference.
• Multicast vs. unicast. E1.31 can be sent as multicast, which some home routers and mesh systems flood to every device on the network, including Wi-Fi. Setting your controllers to unicast (sending to each controller's IP address) in xLights and FPP avoids this and is the better choice for most home networks.
• A separate show network. For larger displays, many people put the show player and controllers on their own switch or network, away from household traffic.
• Multiple network interfaces. If the computer has both Wi-Fi and wired connections, disable the one you aren't using for the show. We've seen routing problems send show traffic out the wrong interface.
• Simplify. Where possible, connect the computer or FPP directly to the controller with a single cable to take the rest of the network out of the picture.
• Ping. Run a continuous ping to the controller and watch for dropped replies.

3. The show player

Most displays today are run by FPP (Falcon Player) on a Raspberry Pi or similar small computer, or directly from xLights on a PC. If you see flashing:

• Update FPP to the current release.
• Check FPP's output settings: the universes, IP addresses and unicast/multicast settings should match what's configured on the controller.
• To isolate the player, play the same sequence from xLights on a PC. If the flashing goes away, the issue is in the FPP setup or its network connection.

If you're sending from a PC, firewall and security software can inspect or delay outgoing network traffic, which can show up as random flashing. When troubleshooting, temporarily disable third-party firewall software to take it out of the loop. We also recommend testing from a dedicated computer rather than a virtual machine (such as Windows running on a Mac).

4. More than one program sending data

If more than one program is sending E1.31 data to the same controller, the two streams fight each other and the lights flicker between them. This happens more often than you'd think:

• xLights and FPP both sending at the same time (for example, xLights test mode open while FPP is running a schedule).
• A second show player, or an old one you forgot was still running.
• Light-O-Rama's Control Panel, if LOR is also installed. It can keep sending E1.31 data in the background even when the Sequence Editor is closed. To stop it, right-click the light bulb icon in the system tray and choose to unload it.

Make sure only one source is sending data to each controller.

5. The sequence

• Software updates. If a sequence worked last week and now flashes, and nothing in your hardware changed, the latest software version may have introduced a problem. Try rolling back to the previous version and re-testing.
• A bad sequence. Create a new, simple sequence from scratch, with nothing imported, that just turns everything on. If that plays cleanly, the problem is in the original sequence.
• Too much data. Displays now run tens of thousands of channels. If the player can't keep up, output can stutter. Test with a simple sequence or with some controllers removed to narrow it down.

The Test tool in xLights is also a quick way to send clean, simple patterns to one controller or output at a time.

6. Last resort: look at the packets

In rare cases we have to determine whether a problem is in the controller and network or in the software sending the data. For that we use WireShark, a free program that lets you see the actual data going to the controller, including malformed or out-of-order packets. It was the only way to prove the cause in the case shown below:

It's rare to need a tool like this. Your vendor should be able to help well before you get to this point.

7. Firmware

E1.31 is a simple protocol, but a controller's firmware can still have a flaw. Update to the vendor's latest firmware first. If that doesn't fix it, try moving things around: swap which universes go to which outputs and see whether the problem follows the output or the universe.

If you suspect the controller, send your vendor:

• A detailed list of the steps you've taken. Use specific references such as "output 1," not "the output."
• How the controller is configured (universes, channels, outputs) and what's connected to each output (pixel counts, etc.).
• A copy of the sequence that reproduces the problem.
• Details of your network: what's between the player and the controller.

The vendor knows nothing about your setup except what you tell them, so the more detail, the faster the answer.

Conclusion

E1.31 itself is simple, but there are a lot of layers between your sequence and your lights. Start at the bottom, rule out each layer, and never assume something is fine until testing proves it.

HolidayCoro.com