Difference between revisions of "Protocols"
Dirknerkle (talk | contribs) |
ErnieHorning (talk | contribs) (Updated the protocol overview to reflect current DIY lighting practices. Added Distributed Display Protocol (DDP), clarified the roles of E1.31, Art-Net, Renard, and PixelNet, distinguished network protocols from pixel communication protocols, and preserved the original protocol descriptions and illustrations.) |
||
| Line 1: | Line 1: | ||
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. | 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 | + | In the lighting hobby there are not many protocols to chose from. From a performance perspective Today, most DIY holiday lighting systems use Ethernet networking because it provides excellent performance, scalability, and compatibility with modern controllers. Serial protocols such as DMX and Renard continue to be widely used for specific applications and legacy equipment. 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. |
[[File:LightBoard.PNG|400px|Left]] | [[File:LightBoard.PNG|400px|Left]] | ||
| + | == Common Lighting Protocols == | ||
| + | The following table summarizes the most common lighting communication protocols used by the DIY holiday lighting community. | ||
| + | {| class="wikitable sortable" | ||
| + | ! Protocol | ||
| + | ! Transport | ||
| + | ! Typical Use | ||
| + | ! Status | ||
| + | |- | ||
| + | | '''DMX''' | ||
| + | | RS-485 | ||
| + | | Professional lighting, legacy pixel controllers | ||
| + | | Current | ||
| + | |- | ||
| + | | '''sACN (E1.31)''' | ||
| + | | Ethernet (UDP) | ||
| + | | General-purpose network lighting protocol | ||
| + | | Current | ||
| + | |- | ||
| + | | '''DDP''' | ||
| + | | Ethernet (UDP) | ||
| + | | High-performance pixel displays | ||
| + | | Current | ||
| + | |- | ||
| + | | '''Art-Net''' | ||
| + | | Ethernet (UDP) | ||
| + | | Professional lighting systems | ||
| + | | Current | ||
| + | |- | ||
| + | | '''Renard''' | ||
| + | | UART / RS-485 | ||
| + | | DIY AC dimming and legacy controllers | ||
| + | | Legacy / Current | ||
| + | |- | ||
| + | | '''PixelNet''' | ||
| + | | RS-485 | ||
| + | | Early DIY pixel systems | ||
| + | | Legacy | ||
| + | |} | ||
| + | ---- | ||
'''DMX''' | '''DMX''' | ||
| Line 10: | Line 49: | ||
[[File:DMX_Timing.PNG|400px|Left]] | [[File:DMX_Timing.PNG|400px|Left]] | ||
| − | + | ---- | |
'''sACN (E1.31)''' | '''sACN (E1.31)''' | ||
| − | Over time, with the need to control more channels, DMX over Ethernet was created or ACN/E1.31. | + | Over time, with the need to control more channels, DMX over Ethernet was created or ACN/E1.31. sACN (E1.31) remains one of the most widely supported lighting protocols in the DIY holiday lighting community. It is supported by virtually all commercial and DIY Ethernet controllers, sequencing software, and many ESP-based controllers. 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. | 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. | ||
| Line 20: | Line 59: | ||
[[File:ACN_E131_Header.png|800px|Left]] | [[File:ACN_E131_Header.png|800px|Left]] | ||
| + | ---- | ||
| + | '''Distributed Display Protocol (DDP)''' | ||
| + | |||
| + | Distributed Display Protocol (DDP) is a lightweight UDP-based protocol developed specifically for controlling large numbers of pixels efficiently. Unlike E1.31, DDP is not organized into universes of 512 channels. Instead, it transmits continuous blocks of pixel data using absolute channel addresses, significantly reducing protocol overhead and simplifying controller configuration. | ||
| + | |||
| + | Because fewer packets are required, DDP can reduce network traffic and improve performance on large displays. It is supported by xLights, Falcon Player (FPP), WLED, ESPixelStick, Falcon controllers, Kulp controllers, and many other modern DIY lighting platforms. | ||
| + | DDP has become a popular alternative to E1.31 for large pixel displays while maintaining the same underlying Ethernet infrastructure. | ||
| + | ---- | ||
'''Art Net''' | '''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. | + | 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. Art-Net remains common in professional lighting installations but is less frequently used in DIY holiday lighting than E1.31 or DDP. |
| − | + | ---- | |
'''Pixel Net''' | '''Pixel Net''' | ||
| Line 31: | Line 78: | ||
[[File:Pixelnet_Protocol.PNG|375px|Left]] | [[File:Pixelnet_Protocol.PNG|375px|Left]] | ||
| + | '''Historical Note''' | ||
| + | |||
| + | PixelNet played an important role in early DIY pixel displays but has largely been replaced by Ethernet-based protocols such as E1.31 and DDP. | ||
| + | ---- | ||
'''Renard''' | '''Renard''' | ||
| Line 36: | Line 87: | ||
[[File:Renard_Protocol.PNG|300px|Left]] | [[File:Renard_Protocol.PNG|300px|Left]] | ||
| + | |||
| + | '''Historical Note''' | ||
| + | |||
| + | Renard continues to be used by many hobbyists to control legacy AC dimming systems and other serial controllers. Although new designs typically use Ethernet-based protocols, Renard remains fully supported by xLights and ESPixelStick. | ||
| + | ---- | ||
| + | '''Pixel Data Protocols''' | ||
| + | |||
| + | Protocols such as WS2811, WS2812, UCS1903, TM1814, and similar pixel signaling methods are local hardware communication protocols used between a controller and the pixel string. They are different from network protocols such as E1.31 or DDP, which transport lighting data across an Ethernet or Wi-Fi network before it reaches the controller. | ||
''Last edited June 10, 2015'' | ''Last edited June 10, 2015'' | ||
Latest revision as of 07:10, 20 July 2026
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 Today, most DIY holiday lighting systems use Ethernet networking because it provides excellent performance, scalability, and compatibility with modern controllers. Serial protocols such as DMX and Renard continue to be widely used for specific applications and legacy equipment. 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.
Common Lighting Protocols
The following table summarizes the most common lighting communication protocols used by the DIY holiday lighting community.
| Protocol | Transport | Typical Use | Status |
|---|---|---|---|
| DMX | RS-485 | Professional lighting, legacy pixel controllers | Current |
| sACN (E1.31) | Ethernet (UDP) | General-purpose network lighting protocol | Current |
| DDP | Ethernet (UDP) | High-performance pixel displays | Current |
| Art-Net | Ethernet (UDP) | Professional lighting systems | Current |
| Renard | UART / RS-485 | DIY AC dimming and legacy controllers | Legacy / Current |
| PixelNet | RS-485 | Early DIY pixel systems | Legacy |
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. sACN (E1.31) remains one of the most widely supported lighting protocols in the DIY holiday lighting community. It is supported by virtually all commercial and DIY Ethernet controllers, sequencing software, and many ESP-based controllers. 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
Distributed Display Protocol (DDP)
Distributed Display Protocol (DDP) is a lightweight UDP-based protocol developed specifically for controlling large numbers of pixels efficiently. Unlike E1.31, DDP is not organized into universes of 512 channels. Instead, it transmits continuous blocks of pixel data using absolute channel addresses, significantly reducing protocol overhead and simplifying controller configuration.
Because fewer packets are required, DDP can reduce network traffic and improve performance on large displays. It is supported by xLights, Falcon Player (FPP), WLED, ESPixelStick, Falcon controllers, Kulp controllers, and many other modern DIY lighting platforms.
DDP has become a popular alternative to E1.31 for large pixel displays while maintaining the same underlying Ethernet infrastructure.
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. Art-Net remains common in professional lighting installations but is less frequently used in DIY holiday lighting than E1.31 or DDP.
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.
Historical Note
PixelNet played an important role in early DIY pixel displays but has largely been replaced by Ethernet-based protocols such as E1.31 and DDP.
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.
Historical Note
Renard continues to be used by many hobbyists to control legacy AC dimming systems and other serial controllers. Although new designs typically use Ethernet-based protocols, Renard remains fully supported by xLights and ESPixelStick.
Pixel Data Protocols
Protocols such as WS2811, WS2812, UCS1903, TM1814, and similar pixel signaling methods are local hardware communication protocols used between a controller and the pixel string. They are different from network protocols such as E1.31 or DDP, which transport lighting data across an Ethernet or Wi-Fi network before it reaches the controller.
Last edited June 10, 2015