Protocols
A protocol is simply a mechanism of communication between two electronic devices. For communication to work, both devices must use the same protocol. For example, when two people talk to each other on the telephone, they may speak in "English" which is one "protocol" for speech. If one person speaks in English and the other tries to talk in French, the communication between the two people is likely to be more difficult and if both spoke in English or both spoke in French.
In the lighting hobby there are not many protocols to chose from. From a performance perspective Ethernet wins hands down. It is inexpensive to buy switches/routers to distribute the signals. Lighting control started with professional lighting. Where the lights were remotely controlled on stage with a board as shown below. This first standard was DMX run as a control wire to the lights on stage.
DMX
DMX is the standard industrial lighting designed for professional lighting. This is the standard that most of the lighting is based upon. This is similar to an asynchronous communication, but different timing to start the sequence. Once the start sequence has been sent the data is standard asynchronous format with 8 data bits, and 2 stop bits. The standard uses differential RS-485 to send the data. This format allows for a single transmitter to send data to multiple receivers, nominally 32. The last receiver in the line should terminate the signal with 120 ohms. DMX defines a universe as 512 channels of data, where each channel can control the brightness (0 to 255) of one light. For RGB LED’s, this requires 3 channels to control the light.
sACN (E1.31)
Over time, with the need to control more channels, DMX over Ethernet was created or ACN/E1.31. This is the main protocol used by the "Do It Yourself" community, for both hardware and software. The data is output as multicast UDP message packets. Which basically means that the data is just sent out on the network with no response expected. The standard has over 100 bytes of header for on each packet. This header includes many things, including vendor ID, format type, vectors and flags, universe number and number of channels. Following the header is a byte of intensity data for each of the channels. For multi-cast data each universe has an unique IP address, with a total of 65,535 universes.
Most of the controllers also support a uni-cast version of the UDP message set. This allows for multiple universes of data to be sent to the same IP address. This is not in the original specification, but helps reduce the overhead on your network.
ACN/E1.31 Header
Art Net
Art Net is another UDP based protocol. It supports both the broadcast type as ACN/E1.31 as well as uni-cast. This protocol is more complex in that it allows polling, triggers, time stamps, re-programming of nodes, changing node IP address etc. Check with both your software and controllers to ensure that support of this protocol is available.
Pixel Net
Pixel net is a one megabit RS-485 communication bus. The protocol is extremely simple, there is a 170 decimal start character, which is followed by 4096 bytes of channel data. Any data that has a value of 170 is changed to 171. The information is sent as asynchronously with 8 bits of data and one start/stop bit. This protocol is very simple and allows the hobbyist to use simple microprocessor for reception of data. The protocol only supports 50mS or slower timing for sequencing.
Renard
Renard is basically a asynchronous serial format with eight data bits and one stop bit. This protocol has three reserved characters. The start byte is 0x7E, which indicates the start of data. There is a pad byte that is ignored with a value of 0x7D, and finally 0x7F is used to send these three reserved bytes as two bytes of data. Many of the controllers will only transmit the 0x7E as a start character and then translate the three bytes to the nearest one byte value (for example 0x80). This data can either be sent as UART data using RS-232 levels, single ended or as differential RS-485.
Last edited June 10, 2015