Lighting Control Protocols and Standards

The world of stage lighting uses a variety of communication protocols to link control devices (computers, light boards, houselighting systems) to endpoint devices (lights, dimmers, effects). These run the gamut from basic analog control through legacy serial protocols to modern packetized, ethernet-based protocols.

The specifications of many of the most widely-adopted protocols are managed by the Entertainment Services and Technology Association through their Technical Standards Program. Confusing matters slightly, these protocols are sometimes referred to by their ESTA standards numbers, often interchangeably with the common names. Below is a list of the major ESTA standards that apply to lighting control, with their standard number, their common name, and a brief description.

I'm not directly linking to the standards documents, but you can find them all on the approved standards page of the ESTA.

Here are the currently released standards:

Briefly, the protocols are:

E1.3 0-10V Control: Specifies control of dimmers/luminaries via individual analog control lines. 0 volts is always off, or one extreme of a parameter (e.g. full pan left; minimum blue; focus all the way in, etc). 10V is always on, or the other extreme of a parameter. "0V" is really -0.2V to 0.3V. "10V" is really "9.8V to 30V". Control lines must be stable to ± 20mV. Minimum load impedance is 50 kOhms. Passive controls have max 2.5 kOhms output impedance; active controls have max 100 Ohm output impedance. Short circuit protection, overvoltage protection, and current supply are also specified.

E1.11 DMX 512: ("Digital MultipleX") Specifies a 250 kbps serial protocol for controlling equipment, the EIA-485 transmission techniques for the same, physical cable specifications, and appropriate connectors (XLR5). The 5-conductor cables are common, data 1±, and data 2± (rarely used), each not to exceed 6V above common. Data lines are balanced in pairs. Signal line impedance is 120 ohms nominal. Each "packet" of serial data begins with a break, mark, and start code, followed by up to 512 slots of data, each of which has an 8-bit value. No error checking/correction is provided.

E.1.17 ACN: (Architecture for Control Networks) Specifies a series of protocol formats for (generally network-based) interchangeability between control systems and endpoint devices. Generally: the Device Management Protocol (DMP) encapsulates the Getting and Setting of device parameters; a set of Device Description Language standards (DDL) defines the format and language for component description to allow common control and identification; and the Session Data Transport (SDT) protocol allows for multicast delivery of messages with ordering and verification not present in generic UDP multicasting. The Protocol Data Unit is the singular message format for DMP messages.

ACN also provides for device discovery. While typically used with TCP/IP and 802.3 Ethernet or 802.11 WiFi, other physical/link/transport/network layers are incorporated as possibilities, including various serial and RS485 standards, via interoperability profiles.

E1.20 RDM: (Remote Device Management) Specifies an extension to a DMX512 link permitting intelligent, bi-directional communication between devices. An alternative start code in a DMX packet identifies an RDM packet. RDM uses a binary-tree or similar search to identify devices on a DMX512 line. Controllers can use RDM messages to Get or Set parameters of endpoint devices, and communicate to individual endpoints when they may drive the line to respond to Controller commands. Device configuration and monitoring are primary goals, as is identification.

E1.31 sACN (Streaming ACN): Describes a lightweight mechanism for streaming DMX packets over an IP network using a (small) subset of the ACN suite. Describes data format, protocol, addressing, and network management, as well as a synchronization method for ensuring that data arrives concurrently at multiple endpoints.

There are also some subsidiary standards documents managed by the Control Protocols Working Group, including:

• E1.27-1 - Standard for portable control cables for use with DMX512
• E1.27-2 - Standard for Permanently Installed Control Cables for use with DMX512
• E1.30-1 - EPI 23, Device Identification Subdevice
• E1.30-3 - EPI 25, Time Reference in ACN Systems using SNTP and NTP
• E1.30-4 - EPI 26, DDL Extensions for DMX512 and sACN Devices
• E1.30-7 - EPI 29, Allocation of IPv4 Addresses to ACN Hosts
• E1.37-1 - Additional Message Sets for E1.20 RDM Part 1 - Dimmer Message Sets

In addition to the published ESTA standards, it's worth mentioning two that are not currently maintained as standards:

The standard for E1.33, RDMNet, has been in draft review since at least 2011. It defines a suite of protocols for the types of device discovery, device management and configuration, and automatic device configuration that RDM provides on a DMX512 link, but across a network. It defines a broad scalable architecture that allows for multiple controllers and "tens of thousands of responders," as well as a minimal protocol for carrying non-RDM data over the same protocol. The spec defines

• A Low Level Recovery Protocol (LLRP), used to configure IP settings so that E1.33 equipment achieves connectivity
• A Broker protocol, which allows for discovery and many-to-many message transport
• The RDM Packet Transport Protocol (RPT), which defines the primary packet formats and messages, as well as topology and functional requirements for controllers and endpoints
• The Extensible Packet Transport protocol (EPT), which may be used to carry non-DMX data in a similar way to RPT.

BSR E1.33 Concluded its fifth public review in January 2018 with 68 pages of public comments; no date is known for the next public review session. As noted below, ETC has its own mechanism for transporting RDM and RDM-like data over ethernet via its NET3 suite.

The second 'standard' of interest is the former E.1.45, "Unidirectional Transport of IEEE 802 Data Frames over ANSI E1.11 (DMX512). This provided a mechanism for transmitting IEEE 802 packets - including Ethernet (802.3), Wireless LAN (802.11), and Bluetooth (802.15.1) - over a DMX512 link by using an alternative start code, stuffing the packet data into the DMX "payload" area, prepending two byte of sequence numbers and appending a two octet CRC for error checking. Interestingly, it seems that this standard was aimed specifically at Visible Light Communication (802.15.7), for transmission of data in the visible spectrum.

After publication, it was established that key parts of the E1.45 standard were covered by US and Korean patents, and the patent holder would not guarantee that licensing could be made "under reasonable terms and conditions that are demonstrably free of any unfair discrimination." Therefore, in October 2015, the ESTA withdrew this document as a standard.

Beyond the ESTA-specified standards, there are a handful other vendor-specific or genre-specific communications protocols in use. Electronic Theatre Controls (ETC) has used a number of protocols all their own over the years, including:

ETCnet (Net1): Originally called ETCNet and retroactively renamed to Net1, this was ETC's first Ethernet based control protocol. It is proprietary, without publicly available specification. It is a raw Ethernet protocol (layer 2), meaning that routers and certain types of switches do not pass Net1 traffic. A hub is recommended. Net1 provdes transport of console video information, up to 4 universes of DMX, tracking backup data, and keyboard command information to ETC products of the era, including Express/Expression/Insight and Obsession 1. Many Net2 DMX nodes can also be configured to operate in Net1 mode, with the concomitant loss of function.

ETCLink: ETC's Sensor dimmers with a CEM classic controller use this protocol to provide dimmer feedback to the console. Express/Expression and Obsessions 1/2 consoles could receive this data. Connections were commonly a 6-pin XLR connector. This functionality has been supplanted by ethernet-based feedback in modern systems.

ETC Net2: Introduced with the Obsession II console, ETC's second networked control solution incorporated IP addressing, this allowing network traffic to be switched or routed. Sends DMX data as eDMX, which in its final version incorporates per-"range" priority. Includes EDIMI, ESMPTE, FTP for ETC devices, and video data for remote video units.

ETC Net3: ETC's current suite of network-based communication. Sends DMX data over sACN. Uses a non-public RDM-over-ethernet protocol to receive RDM data from Net3 DMX Nodes. Incorporates network video data as Net2 did. Many ETC products (Sensor Dimming, Paradigm, Mosaic, Unison, etc) have ethernet functionality, but it is nebulous which of these fall under "Net3" and which are their own Ethernet-based communication system.

ETC also uses LonBus-based networking devices to control various legacy architectural control stations - while their modern counterparts can also usually take LonBus, they are typically served by an Ethernet connection.

Other situation-specific lighting communication protocols include:

Art-Net: A simple implementation for streaming DMX512 and RDM information over IP networks, typically ethernet. Multiple versions exist (1 thru 4) with significant differences - version 1 uses only broadcast packets; version 2 uses broadcast for discovery of endpoints and unicast for data delviery. Version 3 introduced the ability to expand to up to 32,000 universes, and further refinements were made to version 4. Artnet uses specific IP ranges for much of its configuration, which can present integration challenges when it needs to exist alongside other switched protocols.

HogNet and Fixturenet: High End Systems uses its proprietary HogNet ethernet suite of protocols to link its line of Whole Hog lighting consoles, as well as their DMX processors and optionally other lighting control PC's. These connect to a specific HogNet RJ45 connector on the back of most Whole Hog consoles, with its own NIC. A secondary connection, the FixtureNet ethernet connection, is used for connecting to Art-Net/sACN(E1.31) DMX gateways.

CITP (Controller Interface Transport Protocol): Used by some lighting and video controllers to exchange pictures and video streams over a network. The standard is maintained by Capture.

PosiStageNet (PSN): An open protocol developed by MA Lighting to transmit realtime position information over a network, for example from a tracking device on a moving actor, scenic piece, or prop to allow for video, lighting, or motion-control tracking.

So what does the future of lighting control look like? Clearly, we are living in an increasingly-connected theatrical world, and most of that connectivity is Ethernet-based. I don't expect to see an entirely new paradigm at the link layer any time soon.

I have expected for many years to see an additional level of automation and abstraction in how we set up lighting systems. When all of the devices in a system can talk to each other, is there still a need to individually plan, address, patch, and coordinate the ID's of individual fixtures or dimmers? Or can we automate ourselves out of the time consuming business of managing how the devices talk to each other and let the system set up its communication network automatically? We shall see.

No matter what the future holds, we've come a long way from Piano Board dimming.

Update: After posting this on Facebook, a friend asked about the AMX protocol that he remembered from high school. Here's the brief answer I gave him:

AMX (Analog MultipleX) was one of a bunch of protocols (AMX192, CMX, MPX) that appeared in the late 80's as people were trying to solve the "one dimmer = one wire" problem of E1.3 0-10v. It used 4 wires - two for a (balanced) clock signal, one ground, and a signal line which carried a succession of analog voltages (0-5V) that represented the levels of up to 192 parameters.

Acceptable connectors were 4-pin XLR or TY4F (mini-stupid!). Interestingly, the spec requires "sound-style" Male XLR connectors on the controller and female connectors on endpoints. 

The AMX192 standard was developed and published in 1987 by the United States Institute for Theatre Technology (USITT), instead of the ESTA.

Full spec re-hosted here: http://jeff.glass/documents/AMX192_8-08.pdf