ErnieHorning: Expanded the E1.31 (sACN) overview by clarifying universe numbering, multicast and unicast operation, Wi-Fi and Ethernet deployment considerations, protocol relationships with DMX512 and DDP, and practical configuration guidance. Added recommendations for reliable network design, common troubleshooting scenarios, and controller compatibility to help users successfully deploy E1.31 in animated holiday lighting displays.

2026-07-30T13:54:42Z

Expanded the E1.31 (sACN) overview by clarifying universe numbering, multicast and unicast operation, Wi-Fi and Ethernet deployment considerations, protocol relationships with DMX512 and DDP, and practical configuration guidance. Added recommendations for reliable network design, common troubleshooting scenarios, and controller compatibility to help users successfully deploy E1.31 in animated holiday lighting displays.

ErnieHorning: Created E1.31 protocol page

2026-07-25T15:21:25Z

Created E1.31 protocol page

New page

{{DISPLAYTITLE:E1.31}}

= E1.31 =

'''E1.31''', commonly called '''sACN''' or '''Streaming ACN''', is a network protocol used to transport DMX-style lighting data over an Ethernet or Wi-Fi network.

It is widely supported by Christmas-lighting sequencers, show players, pixel controllers, and commercial lighting equipment. E1.31 allows lighting data to be sent from software such as [[xLights]] or [[Falcon Player (FPP)]] to one or more controllers using standard Internet Protocol networks.

[[File:E1.31.png|center|900px|thumb|Figure 1 – E1.31 transports lighting-channel data from a sequencer or show player to controllers over an IP network.]]

== Overview ==

E1.31 is formally titled:

:''Entertainment Technology — Lightweight streaming protocol for transport of DMX512 using ACN''

The protocol carries DMX512 channel data using a portion of the Architecture for Control Networks (ACN) protocol suite.

E1.31 is commonly used for:

* Pixel controllers
* DMX gateways
* Stage-lighting equipment
* Wireless lighting controllers
* Distributed Christmas displays
* Large synchronized lighting systems

== How E1.31 Works ==

A sequencer or show player creates lighting-channel data and divides it into groups called '''universes'''.

The E1.31 data is then transmitted across the network to one or more receiving controllers.

A typical signal path is:

<pre>
xLights or FPP
↓
E1.31 network data
↓
Ethernet or Wi-Fi network
↓
Pixel controller or DMX gateway
↓
Pixels, dimmers, or other lighting devices
</pre>

The receiving controller converts the network data into the electrical signals required by the connected lights.

== Universes and Channels ==

E1.31 organizes lighting data into numbered universes.

Each universe normally carries up to '''512 channels''' of lighting data.

An RGB pixel normally uses three channels:

* Red
* Green
* Blue

Therefore, one 512-channel universe can carry:

* 170 complete RGB pixels
* 510 used channels
* 2 unused channels

Large props and displays commonly span several universes.

== Universe Configuration ==

The sending software and receiving controller must agree on:

* Starting universe
* Number of universes
* Channels per universe
* Starting channel or offset
* Total channel count

Incorrect universe or channel assignments may cause:

* Pixels to remain dark
* Incorrect colors
* Data to appear on the wrong prop
* Portions of a prop to operate incorrectly

A universe is only an organizational unit for transporting channel data. It does not need to correspond to one physical controller output or one pixel string.

== Multicast and Unicast ==

E1.31 data may be transmitted using either multicast or unicast.

=== Multicast ===

Multicast sends universe data to a multicast network address rather than directly to one controller.

Advantages include:

* Multiple controllers can receive the same universe.
* The sender does not need a separate destination entry for every controller.
* It follows the traditional sACN discovery and distribution model.

Disadvantages include:

* Network switches and wireless access points may distribute the traffic more broadly than necessary.
* Large amounts of multicast traffic can burden Wi-Fi networks.
* Network equipment may require proper multicast or IGMP handling.

=== Unicast ===

Unicast sends data directly to the IP address of a specific controller.

Advantages include:

* Data is sent only to the intended controller.
* Network traffic is easier to control.
* It is often preferred for Wi-Fi Christmas displays.

Disadvantages include:

* Each controller must be configured as a destination.
* Changing controller addresses may require updating the sender configuration.
* Sending the same universe to several controllers requires separate transmissions.

== E1.31 Over Wi-Fi ==

E1.31 can operate over Wi-Fi, and it has been used successfully in many distributed Christmas displays.

For reliable operation:

* Use dedicated display access points when practical.
* Avoid unnecessary multicast traffic.
* Keep controllers within reliable Wi-Fi coverage.
* Use fixed or reserved IP addresses where appropriate.
* Connect the sequencing computer or show player to the network by Ethernet when possible.
* Avoid sending show data through a Wi-Fi connection that must simultaneously receive and retransmit the same traffic.

Unicast is commonly preferred for larger Wi-Fi installations because it limits traffic to the intended controller.

== E1.31 Over Ethernet ==

Wired Ethernet is commonly used with centralized and multi-output controllers.

Advantages include:

* High reliability
* Consistent network performance
* Large channel capacity
* Reduced susceptibility to radio interference
* Easier handling of large amounts of multicast traffic

Ethernet is often preferred for mega trees, large matrices, and centralized controller installations.

== E1.31 and DMX512 ==

E1.31 transports channel data in a format based on [[DMX|DMX512]], but E1.31 and physical DMX512 wiring are not the same thing.

'''DMX512''' normally uses an RS-485 electrical connection and daisy-chained devices.

'''E1.31''' carries similar channel information over an IP network.

An E1.31-to-DMX gateway can receive network data and produce a physical DMX512 output.

== E1.31 and DDP ==

Both [[E1.31]] and [[DDP]] can transport lighting data across an IP network.

E1.31:

* Organizes data into 512-channel universes
* Is based on DMX512 channel organization
* Is widely supported by professional lighting equipment
* Supports multicast and unicast operation

DDP:

* Sends data using continuous channel or pixel offsets
* Does not require universe boundaries
* Generally adds less protocol overhead
* Is often easier to configure for large pixel displays

E1.31 remains an important industry standard, while DDP is frequently preferred for direct pixel-data transport when both the sender and controller support it.

== Supported Software and Controllers ==

E1.31 is supported by many Christmas-lighting systems, including:

* [[xLights]]
* [[Falcon Player (FPP)]]
* [[WLED]]
* [[ESPixelStick]]
* Falcon controllers
* Kulp controllers
* Many commercial pixel controllers
* E1.31-to-DMX gateways

The specific configuration options depend on the software or controller.

== Common Configuration Problems ==

Typical E1.31 problems include:

* Sender and controller using different universe numbers
* Incorrect channel counts
* Incorrect starting-channel offsets
* Multicast traffic not passing correctly through the network
* Duplicate IP addresses
* Incorrect controller IP address
* Wi-Fi congestion
* Overlapping channel assignments
* Output channels not enabled in the sequencer or show player

When troubleshooting, verify the complete path from the sequencing software to the physical controller output.

== Advantages ==

* Open entertainment-lighting standard
* Widely supported
* Works over standard IP networks
* Supports Ethernet and Wi-Fi
* Compatible with professional DMX equipment
* Supports multicast and unicast
* Scales to large channel counts
* Useful for both pixels and conventional lighting

== Limitations ==

* Universe configuration can become complicated.
* RGB pixels may cross universe boundaries.
* Multicast can create unnecessary network traffic.
* More protocol overhead than some pixel-oriented protocols
* Sender and receiver channel assignments must match exactly.
* Wi-Fi performance depends heavily on network design.

== Christmas Display Recommendations ==

E1.31 is a good choice when:

* The controller requires E1.31.
* Compatibility with professional lighting equipment is needed.
* Existing controller configurations already use universes.
* Data must be sent to an E1.31-to-DMX gateway.
* Several devices need to receive the same universe data.
* Broad compatibility is more important than simplified configuration.

[[DDP]] may be easier for direct control of large pixel props when it is supported by both the sequencing software and controller.

== Official Standard ==

The current E1.31 standard is published by the Entertainment Services and Technology Association (ESTA).

* [https://tsp.esta.org/tsp/documents/published_docs.php ESTA Published Technical Standards]

== Related Articles ==

* [[DDP]]
* [[DMX]]
* [[Renard]]
* [[Pixel Controllers]]
* [[Smart Pixels]]
* [[ESP Controllers]]
* [[WLED]]
* [[ESPixelStick]]
* [[xLights]]
* [[Falcon Player (FPP)]]
* [[Ethernet]]
* [[Wi-Fi]]
* [[Art-Net]]

@@ Line 68: / Line 68: @@
 Large props and displays commonly span several universes.
 == Universe Configuration ==
@@ Line 100: / Line 106: @@
 * Multiple controllers can receive the same universe.
 * The sender does not need a separate destination entry for every controller.
-* It follows the traditional sACN discovery and distribution model.
+* It follows the standard sACN distribution model.
 Disadvantages include:
@@ Line 138: / Line 144: @@
 Unicast is commonly preferred for larger Wi-Fi installations because it limits traffic to the intended controller.
 == E1.31 Over Ethernet ==

E1.31 - Revision history

ErnieHorning: Created E1.31 protocol page