E1.31 in simple terms is "DMX512 over IP". It is a protocol that allows many universes of DMX to be transported over IP networks simultaneously. Most commonly these IP networks are built using relatively inexpensive cabled Ethernet networks, however they can be built over any transport ( for example Wi-Fi, or cellular data ) on which IP can be established.
Like many things, E1.31 has had an interesting history, before it became a published "standard" in July 2010. There was quite heated competition between two groups of manufacturers. The term "streaming ACN (sACN) got created by one group, but is not part of the official standard.. And there is often confusion between E1.31 and ACN. E1.31 is a specific use case of ACN, but it is not ACN itself. The ACN protocol has much wider use cases than just the transport of lighting data. ''For clarity, its good to refer to the protocol as "E1.31"''
A good number of the software packages that are are commonly in use by the lighting community ( eg XLights, Vixen, LightShow Pro, Madrix, Max5, OLA & Light-O-Rama ) now all support sending control data using E1.31. There are a few ( and it is expected to rapidly grow in 2011 ) hardware controllers that support E1.31 (eg J1sys's DR4, Stellascapes E16 ). The DR4 is a protocol converter ( E1.31 --> DMX512 ), and the E16 is a RGB pixel controller.. Rumours of a REN replacement are now surfacing, with an Ethernet driven 64 channel controller only just around the corner.
Each channel is referenced by a Universe and channel number. A universe is a group of 512 channels. ( remember this is DMX over IP ). Each "group" or universe gets a number between 1 and 63999. So a channel maybe the 200th channel in universe 200..
E1.31 is either transported as unicast or multicast. The data is wrapped in in UDP packets on non specific port numbers.. E1.31 is now recognised by Wireshark and there are some useful comments there about how the packets are formatted.
See also: E1.31 Multicast vs Unicast
A single E1.31 packet contains DMX data for a single universe (512 channels). A PC application (such as da_E131) will send multiple universes of DMX data by sending interleaved (eg U1,U2,U3,U4 ... U1,U2,U3,U4 ...) E1.31 packets. Each E1.31 packet only contains data for one DMX universe though; the one specified as part of the packet. In multicast mode, the last two octets of numbers in the IP address also reflects the universe number.
What's in a name?
Like many things, E1.31 has had an interesting history, before it became a published "standard" in July 2010. There was quite heated competition between two groups of manufacturers. The term "streaming ACN (sACN) got created by one group, but is not part of the official standard.. And there is often confusion between E1.31 and ACN. E1.31 is a specific use case of ACN, but it is not ACN itself. The ACN protocol has much wider use cases than just the transport of lighting data. ''For clarity, its good to refer to the protocol as "E1.31"''
How can you use E1.31 in the context of Christmas blinky lighting?
A good number of the software packages that are are commonly in use by the lighting community ( eg XLights, Vixen, LightShow Pro, Madrix, Max5, OLA & Light-O-Rama ) now all support sending control data using E1.31. There are a few ( and it is expected to rapidly grow in 2011 ) hardware controllers that support E1.31 (eg J1sys's DR4, Stellascapes E16 ). The DR4 is a protocol converter ( E1.31 --> DMX512 ), and the E16 is a RGB pixel controller.. Rumours of a REN replacement are now surfacing, with an Ethernet driven 64 channel controller only just around the corner.
Why Use E1.31?
- Cost: It could quite feasibly be cheaper to use E1.31 than other protocols, when you consider the "entire" system end to end
- Channel count: Very large scale ( 100,000's ) of channels are not only possible but have been demonstrated to work
- Simplicity: Overall the complexity of a well implemented e1.31 network is likely to be less
- Physical distance limits overcome: IP networks span the globe, and its possible to control a show half a world away. ( Wellington to Melbourne was done, Wellington to USA has been done ) At a more practical level its easy to control entire streets, or blocks of buildings or entire theme parks.
Essential Facts
Each channel is referenced by a Universe and channel number. A universe is a group of 512 channels. ( remember this is DMX over IP ). Each "group" or universe gets a number between 1 and 63999. So a channel maybe the 200th channel in universe 200..
Technical Nitty Gritty
A detailed discussion is well beyond the scope of this wiki, but you can refer to the full published standard:ANSI E1.31 - 2009 - Entertainment Technology - Lightweight streaming protocol for transport of DMX512 using ACN
ANSIE1312009-Entertainment Technology - Lightweight streaming protocol for transport of DMX512 using ACN-ANSI E1.31 - 2009, Entertainment Technology - Lightweig
webstore.ansi.org
E1.31 is either transported as unicast or multicast. The data is wrapped in in UDP packets on non specific port numbers.. E1.31 is now recognised by Wireshark and there are some useful comments there about how the packets are formatted.
See also: E1.31 Multicast vs Unicast
Universes
A single E1.31 packet contains DMX data for a single universe (512 channels). A PC application (such as da_E131) will send multiple universes of DMX data by sending interleaved (eg U1,U2,U3,U4 ... U1,U2,U3,U4 ...) E1.31 packets. Each E1.31 packet only contains data for one DMX universe though; the one specified as part of the packet. In multicast mode, the last two octets of numbers in the IP address also reflects the universe number.
Related
Categories:
DMX Information pages
Protocols