Difference between revisions of "Protocols"
Line 11: | Line 11: | ||
'''ACN/E1.31''' | '''ACN/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. | + | 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 helps reduce the overhead on your network. | + | 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 | ACN/E1.31 Header |
Revision as of 15:42, 5 June 2015
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.
ACN/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
Preamble size (2 bytes)
Post-amble size (2 bytes)
ACN ID (12 bytes)
Flags/Length (2 bytes)
Vector (4 bytes)
Source name (64 bytes)
Priority (1 byte)
Reserved (2 bytes)
Option flags (1 byte)
Universe number (2 bytes)
Flags/Length (2 bytes)
Vector (1 byte)
Address and data type (1 byte)
First property address (2 bytes)
Address increment (2 bytes)
Property value count (2 bytes)
Art Net
Art Net protocol is not as popular. This is an Ethernet message based protocol that requires communication between the controller and the computer. There are multiple types of messages.
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 May 26, 2015