--- title: "What Is sACN? ANSI E1.31 Explained | DMXDesktop" description: "sACN explained: how ANSI E1.31 carries DMX over Ethernet, how multicast addressing and source priority work, and what really happens when the data stops." canonical: https://www.dmxdesktop.com/guides/what-is-sacn lang: en source: /guides/what-is-sacn --- # What is sACN? ANSI E1.31 explained **sACN is the usual abbreviation for ANSI E1.31, the open standard that carries DMX512 lighting data over an ordinary Ethernet network.** One network cable replaces many DMX cables, and a single computer can drive hundreds of universes across a building. It is published by ESTA, it is free to implement, and almost every modern lighting product supports it. This guide explains how sACN actually works: how it addresses universes, how it decides which console wins when two are sending, and what happens when the data stops. Every figure here is taken from the current revision of the standard, ANSI E1.31-2025. Last updated 2026-09-16 ## In short - •sACN sends DMX512 universes over UDP on port **5568**, normally by multicast, so one sender reaches many receivers without being configured for each one. - •Universe numbers run from **1 to 63999**, and the universe number maps directly into the multicast address **239.255..**. - •Every source carries a **priority from 0 to 200, default 100**. The highest priority wins, which is how backup consoles and remote control take over cleanly. - •If data stops for **2.5 seconds** the receiver treats the universe as disconnected. The standard's required gateway behaviour is to **stop output**, not to hold the last look. - •sACN carries no RDM and no device configuration. That is Art-Net's territory, or RDMnet (ANSI E1.33). ## [What sACN actually is](#what-sacn-actually-is) sACN stands for a standard with a much longer name: *ANSI E1.31-2025, Entertainment Technology, Lightweight streaming protocol for transport of DMX512 using ACN*. ACN there is the Architecture for Control Networks, ANSI E1.17, from which E1.31 borrows its packet framing. A small curiosity worth knowing, because it trips up people writing about it: **the abbreviation "sACN" never appears in the standard itself.** ESTA uses it informally in its own newsletters ("also known as sACN"), and everyone in the industry says it, but you will not find it, or the expansion "Streaming ACN", written out in the published document. If you want to be precise, call it ANSI E1.31 and note that sACN is the common abbreviation. The standard is published by [ESTA's Technical Standards Program](https://tsp.esta.org/tsp/documents/published_docs.php?utm_source=dmxdesktop.com), the same body behind DMX512 (E1.11) and RDM (E1.20). It is an open American National Standard: anyone can download it, and anyone can implement it without a licence fee. That openness is the main reason sACN spread so quickly across consoles, nodes, media servers and software. What it does is narrow and deliberate. It takes the 512 slots of a DMX universe, wraps them in a UDP packet with a few extra fields, and streams them across an IP network. It does not configure devices, discover fixtures, or carry RDM. It moves lighting levels, quickly, to a lot of places at once. ## [How sACN travels: multicast and port 5568](#how-sacn-travels-multicast-and-port-5568) sACN runs over UDP on **port 5568**. That port is properly registered with IANA, under the service name `sdt` (Session Data Transport), which is a small but real sign of the standard's maturity. The clever part is the addressing. sACN normally uses **multicast**, and the universe number is built directly into the multicast address: - The first two bytes are always **239.255**. - The third byte is the **high byte** of the universe number. - The fourth byte is the **low byte**. So universe 1 is 239.255.0.1, universe 2 is 239.255.0.2, and universe 300 is 239.255.1.44. There is an IPv6 form too, in the range FF18::83:00:00:00 upwards, built the same way from the last two bytes. Because the address is derived from the universe, a receiver does not need to be told where the data is coming from. It simply joins the multicast group for the universes it cares about, and the network delivers only those. That is why a large rig can run on one cable without every node being individually configured. One subtlety the standard is explicit about: **the universe is identified by the number inside the packet, not by the address it arrived on**. A receiver should never assume the two agree. Unicast is allowed as well, and a receiver must accept sACN sent directly to its own IP address. The catch is stated plainly in the standard: sACN defines no way to discover those addresses, so with unicast you configure destination IPs by hand. That is fine for two nodes and painful for twenty. Lighting software universe 1, priority 100 ↓→ Ethernet switch IGMP snooping ↓→ Multicast group 239.255.0.1, UDP 5568 ↓→ sACN node converts to DMX512 ↓→ Fixtures XLR5 daisy chain The node is the only place the signal becomes DMX512. Everything to its left is ordinary network traffic. ## [Universes: how many, and which numbers are off limits](#universes-how-many-and-which-numbers-are-off-limits) The standard allows universe numbers from **1 to 63999**. Universe 0 is reserved and must not be used, and so is everything from 64000 to 65535, with one exception: **universe 64214** is reserved for universe discovery. Two other rules catch people out: - The top 256 IPv4 multicast addresses, 239.255.255.0 to 239.255.255.255, are reserved by IANA for another purpose, so E1.31 devices must not transmit on them. If those universes are ever used, they must be sent unicast. - sACN numbers universes from 1, and so does DMXDesktop, so the number you set is the number that goes out. Art-Net is the odd one out, because it starts at 0. Discovery in sACN is limited, and worth understanding before you go looking for a feature that does not exist. Sources announce which universes they are transmitting by sending a list on universe 64214 every 10 seconds. That lets a monitoring tool show what is on the network without joining every multicast group. But there is **no device discovery** in sACN: nothing tells you what nodes exist, what they are called, or how to configure them. If you want that, you want Art-Net or RDMnet. ## [Priority: how sACN decides which source wins](#priority-how-sacn-decides-which-source-wins) This is the feature that makes sACN attractive for anything that has to keep running. Every sACN data packet carries a **priority** value from **0 to 200**. A source that does not support variable priority must send **100**, which is why 100 is the default almost everywhere. The rule is simple: for a given universe, a receiver taking data from several sources treats the **highest priority** as the definitive data. Higher numbers win. So a backup console sending at priority 90 sits silently underneath a main console at 100, and takes over the instant the main console stops. No switching, no patching, no operator input. Priority applies **per universe**, not per channel. Slot-by-slot priority is a separate mechanism that E1.31 mentions but does not define. What happens when two sources tie at the highest priority is where implementations differ, and the standard is honest about it. It defines two behaviours, *merge* (combining the data, commonly highest-takes-precedence per slot) and *arbitration* (choosing one source), and requires every device to document which it does, how many sources it can handle, and what it does when that limit is exceeded. It does not mandate an algorithm. It does give one strong warning, and it is a good rule for rig design too: designers are "very strongly discouraged" from algorithms that produce different results from the same set of sources on different occasions, such as accepting whichever source appeared first. The outcome then depends on the order things were switched on, which is the last thing you want on a show day. In DMXDesktop, priority is set per universe, from 1 to 200, defaulting to 100. ## [What happens when the data stops](#what-happens-when-the-data-stops) sACN runs over UDP, which the standard states outright offers no acknowledgement and no assurance that packets arrive. So the interesting question is not whether packets get lost, but what a receiver does about silence. Three rules govern this: - **Data loss timeout: 2.5 seconds.** If a receiver hears nothing from a source on a universe for 2.5 seconds, that source and universe are considered disconnected. In the 2025 revision this counts **data packets only**, so a source still sending synchronisation or discovery packets, but no data, will still time out. - **Keep-alive: every 800 to 1000 milliseconds.** A source that has nothing new to say does not have to keep blasting the network. It sends three identical packets, then drops back to a single keep-alive packet roughly once a second, which is enough to stay inside the 2.5 second window. - **Clean shutdown: the Stream_Terminated flag.** Rather than just going quiet and leaving receivers to wait out the timeout, a source that is finished sets a flag in three final packets. Receivers treat that as an immediate, intentional disconnect rather than a fault. **Here is the part almost everyone gets wrong.** Ask a room of lighting people what a node should do when the data stops, and most will say it holds the last look. The standard says the opposite: a gateway must provide a mode where, on loss of data from all sources of a universe, it **immediately stops transmitting DMX512**. Hold-last-look is permitted as an extra mode, not as the required one. If your rig blacks out when a laptop sleeps, that is compliant behaviour, not a fault, and the fix is to configure the node, not to blame the software. ## [Synchronisation, preview data and the option flags](#synchronisation-preview-data-and-the-option-flags) Each sACN packet carries a small options field with three defined flags, and they explain several behaviours you may have seen without knowing why. - **Preview_Data.** Data marked with this flag is for visualisers and media server previews and must not drive live output. It is how a designer can run a pre-visualisation stream on the same network without lighting the room. - **Stream_Terminated.** The clean shutdown described above. - **Force_Synchronization.** Controls what a synchronised receiver does if synchronisation is lost: freeze until it returns, or carry on updating with new packets. Universe synchronisation itself exists for cases where several universes must change in the same instant, such as LED panels, media servers and fast dimmers, where a few milliseconds of skew is visible. The source decides: it puts a synchronisation address in its data packets, and receivers hold that data until the matching synchronisation packet arrives. Two practical notes. Support for synchronisation is **optional for receivers**, while data and discovery packets are not, so you cannot assume a node implements it. And DMXDesktop does not currently use synchronisation packets: it streams data packets normally, which is what the overwhelming majority of rigs run on. ## [What your network needs](#what-your-network-needs) sACN is undemanding, but multicast has a few requirements that quietly explain most "it works at my desk but not at the venue" stories. - **IGMP support.** The standard requires receivers to support IGMP version 2 on IPv4 (or MLD version 1 on IPv6). That is how a device tells the network which multicast groups it wants. On a small unmanaged switch everything is flooded to every port and it simply works. On a larger managed network you want **IGMP snooping** configured properly, with a querier present, or traffic will either be flooded everywhere or dropped entirely. - **Wired, not wireless.** Multicast over WiFi is delivered at low data rates and is easily disrupted. Use it for a remote control tablet, not for a lighting data path. - **Firewall rules.** UDP port 5568 inbound must be open on any machine receiving sACN, and on Windows the interface has to be the one you think it is. Laptops with several adapters, including virtual ones from VPN software, frequently send out of the wrong interface. - **Frame rate.** The standard says sources must not exceed the DMX512 maximum refresh rate, which E1.11 puts at **44 updates per second** for a full 513-slot packet, unless the user deliberately enables higher rates on a universe with no DMX gateway on it. DMXDesktop outputs at 40 Hz by default and can be set between 10 and 44 Hz. ## [sACN, Art-Net and RDM: what sACN does not do](#sacn-art-net-and-rdm-what-sacn-does-not-do) Two questions come up constantly, and both have clean answers. **Does sACN carry RDM?** No. E1.31 defines no mechanism for RDM at all, so no product can offer RDM over sACN however it is marketed. RDM over a network is a different standard, **RDMnet (ANSI E1.33)**. RDM over Art-Net exists as well, but that is Artistic Licence's own extension rather than an ESTA standard. In DMXDesktop, RDM works over USB interfaces and over Art-Net. **Is sACN better than Art-Net?** They solve overlapping problems differently. sACN has priority, multicast addressing and a formal standard behind it. Art-Net has device discovery, node configuration and RDM. Plenty of rigs use both at once, which is exactly what Art-Net 4 anticipates. There is a full side-by-side comparison in the [Art-Net vs sACN guide](/guides/art-net-vs-sacn). ## [Common sACN problems](#common-sacn-problems) Almost every sACN fault is one of these. | Symptom | Most likely cause | What to check | | --- | --- | --- | | Nothing reaches the fixtures | Universe mismatch | The node's universe number must match the universe you are sending, remembering sACN counts from 1 | | Works on one machine, not another | Wrong network interface | Pick the adapter on the lighting network explicitly, and disable virtual adapters from VPN software | | Works at the desk, fails at the venue | IGMP snooping without a querier | Test with an unmanaged switch, then fix the managed network rather than working around it | | Output freezes, then everything goes dark | Data loss timeout reached | Expected behaviour after 2.5 seconds of silence. Check the sending machine, and set the node's data loss mode deliberately | | Two consoles, flickering output | Equal priority from both sources | Give the backup a lower priority. Equal priorities leave the result to the receiver's merge rules | | Intermittent, wireless only | Multicast over WiFi | Move the lighting path to wired Ethernet | | Receiver sees nothing, network shows traffic | Firewall blocking UDP 5568 | Allow inbound UDP 5568 on the receiving machine | ## Frequently asked questions What does sACN stand for? +sACN is the common abbreviation for ANSI E1.31, the ESTA standard titled "Lightweight streaming protocol for transport of DMX512 using ACN". ACN means Architecture for Control Networks. The abbreviation itself does not appear in the standard, and the expansion "Streaming ACN", while widely used, is not written out in any ESTA document. What port does sACN use? +UDP port 5568, registered with IANA under the service name sdt. Data is normally sent to a multicast address of the form 239.255.., so universe 1 is 239.255.0.1. How many universes can sACN carry? +The standard allows universe numbers 1 to 63999. Universe 0 and 64000 to 65535 are reserved, except universe 64214, which is used for universe discovery. In practice your limit is the network and the software, not the protocol. Does sACN support RDM? +No. ANSI E1.31 defines no RDM transport. RDM over an IP network is covered by a separate standard, RDMnet (ANSI E1.33). RDM is also carried over Art-Net as a vendor extension. DMXDesktop supports RDM over USB DMX interfaces and over Art-Net. Do I need a managed switch for sACN? +Not for a small rig. On a plain unmanaged switch, multicast traffic is flooded to all ports and everything works. Managed networks need IGMP snooping configured correctly, with a querier on the network, otherwise sACN traffic can be dropped or flooded everywhere. What happens if the lighting software crashes? +After 2.5 seconds of silence the receiver treats that source as disconnected. The standard's required gateway behaviour is to stop transmitting DMX512 at that point, so the rig goes dark. Holding the last look is an optional extra mode that many nodes offer, so set it deliberately if that is what you want. ## Using sACN in DMXDesktop DMXDesktop outputs sACN natively on Mac and Windows, with per-universe priority, multicast or a custom multicast address, and a live status view for every universe. The setup guide walks through the configuration screen. [sACN setup guide](/knowledgebase/sacn) [See tested sACN nodes →](/knowledgebase/supported-hardware) ## Sources Every technical figure on this page was read from the published standard itself, not from secondary summaries. - [ANSI E1.31-2025, Entertainment Technology, Lightweight streaming protocol for transport of DMX512 using ACN](https://tsp.esta.org/tsp/documents/published_docs.php?utm_source=dmxdesktop.com) , ESTA Technical Standards Program. Port, addressing, universes, priority, option flags, timeouts and gateway behaviour all read from this revision - [ANSI E1.11-2024, USITT DMX512-A](https://tsp.esta.org/tsp/documents/published_docs.php?utm_source=dmxdesktop.com) , source of the 44 updates per second maximum refresh rate for a full packet - [IANA Service Name and Transport Protocol Port Number Registry](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?utm_source=dmxdesktop.com) , registration of port 5568 as sdt