Understanding the DMX Protocol and the RS-485 Relationship

I often get questions asking about DMX and how it works so I thought it might be useful  to recycle my presentation about DMX from the 2012 Academy that talks about the basics of the DMX protocol.

What can DMX do?
• DMX is simple – it is designed to control
devices, usually lights
• This may also mean just turning on and off a device
• Work with desperate devices and software applications

Where did “DMX” Come From?
• DMX was designed as a public standard to allow hardware and software vendors to all be able to
design inter-operation devices
• Designed in the early 90’s
• Developed by USITT – United States Institute for Theatre Technology
• Designed to be very reliable (but not guaranteed – no error checking)

What is DMX?
• DMX is a protocol
• DMX is a public standard
   - E1.11 (ANSI)
   - Just a set of rules
• DMX runs “over” other protocols or wiring systems

What DMX isn’t
• DMX isn’t a wiring standard
• DMX isn’t a physical “thing”
• DMX isn’t complicated
• DMX isn’t the perfect protocol

RS485 and DMX
• It is important to understand that RS485 ISN’T DMX and vice-versa
• RS485 is the most common method of DMX transmission

Here is a table that shows how DMX (E1.11) compares to other layered systems:

RS485

• RS485 is the “road” on which DMX runs

• Very robust – designed for industrial environments back in the 1970’s

• Differential signaling system (positive and negative voltages)

Here is an example of how a differential signalling system works:

RS485

• Able to handle speeds up to 35 Mbit/s depending on cabling

• Cable lengths up to several thousand feet

• Two wires + ground (optional)

• Allows for a variety of wiring topologies 

• RS485 is the basis for DMX (E1.11) , LOR, Pixelnet and Renard protocols 

RS485 Termination – Yes or no?

• PRO: Termination “dampens” the reflections of the signal in the cable

• CON: Termination “sucks up” power on the line, lowering the voltage and thus the distance

• The RS485 (DMX) specs call for termination (100-120 ohms) with standard DMX cable

LOR Controllers don’t use termination 

• No one best answer – sometimes it is  necessary…sometimes not 

• A scope is the best tool for looking at the quality of the signal

• For video showing the effects of termination: 

Splitting RS485

• Some controllers passively split the connection (LOR/LE Express) and some actively split and then repeat the signal (LE Express)

• Splitting DMX can be as simple as using 3-way splitters

• Keep “stubs” as short as possible

Connectors and Cable (E1.11)

• The E1.11 DMX standard says to use 5 PIN “XLR” plugs (there is also a section about CAT5)

• Many lighting industry devices use 3 PIN “microphone” cable with XLR plugs instead as it is more common

• The holiday lighting world uses CAT5 cable and connections almost exclusively – as they are cheap

RS485 Wiring

• Chart showing wiring interconnections:  http://www.holidaycoro.com/kb_results.asp?ID=46

• Ground wire often not connected in holiday lighting controllers

Controller Count per line

• Technical limit to the number of devices on a single DMX line is 32 but many more are 

possible depending on the line load per controller (actually the RS-485 chip).  I've personally used 90, 3 channel DMX controllers on a single RS-485 line.

• Controller counts can be increased with the use of repeaters (not common)

DMX over Ethernet (E1.31)

• No RS485 - DMX is instead sent over standard Ethernet/Wireless using TCP/IP

• Allows many universes over a single network connection

• Used when distances are far or channel counts are high

• EtherCongateway (J1SYS) / SanDevices controllers or other high-channel count pixel controllers

DMX Channels and universes

• There are 512 channels (9 bits) in a DMX universe

• One transmitter (RS-485) per universe

• One transmitter (E1.31) for many universes

• Universes are effectively unlimited

• Universes are not “connected” to another universe

DMX Protocol Internals

• DMX runs at 250Khz or 4 micro seconds widths/”slices” of time – 1 Microsecond (µs) = .001 milliseconds (ms) / 1000 ms = 1 second

• MTBP – Mark Time Between Packets (idle)

• Break – Starts with 88 µs low/ 22 pulses (get ready…I’m about to send data)

• MAB – Mark After Break ~12 µs high / 2 pulses

• Channel Data - 44 µs / 11 pulses for each channel (shown in red below)

  – Start bit– 1 bit low

  – Data bits – 8 bits (0-255 that define the level of light intensity)

  – End bits – 2 bits high

• First channel zero, has the start code of binary 00000000 (zero) 

• MTBF - Mark Time Between Frames 0-1 seconds high (the next channel is coming up)

• All 512 channels are sent one after another until the next MTBP and the process restarts

DMX Packet Timing

• Timing References

  – 1 Microsecond (µs) = .001 milliseconds (ms)

  – 1 Second = 1000ms

• [(88)+(12)+(44)+(channels*44)+(channels*MTBF)+(MTBP)] µs

• 88+12+44+22528+0+50 = 22,722 µs

• 1,000,000µs (1 second) / 22,722µs = 44.01 Hz or 44(times per 

second)

• This means that as long as your sequences contain timing no smaller than 22ms or .022 seconds, the timing of the display will be as expected

Output Adapters / Dongles

• DMX must be generated by a device

• Devices can be “Smart” or “Dumb”

  – Smart – Command is sent to device from the sequencing software (say…Channel 1 at 128 bits) once and the devices keeps repeating it 44 times/sec. This way the PC doesn't need to keep repeating it. 

  – Dumb – Commands from the sequencing software have to be re-sent over and over 44 times/sec. This puts a larger load on the PC

• Adapters/Dongles

– Smart – HolidayCoro ActiDongle, Enttec Pro, DIYLA Dongle

– Dumb – Enttec Open, generic RS-485 Adapters

Levels of Fading

• Each channel in a universe carries 8 bits of data, allowing up to 256 (FF hex) levels of fading per channel.

• 0 = Off

• 128 = Half on

• 255 = Full on

• Fading “quality” can be affected by lighting curves, linear lighting output

See the following videos for example of what this looks like:

http://vimeo.com/19615787

http://vimeo.com/13703416

DMX Effect Generation

• DMX Devices don’t generate any local effects, unlike the LOR protocol which generates it’s effects in the controller hardware

• Effects are generated in software

• This means that effects can be changed easily as they are created in the sequencing software

LOR Users – How get DMX

• LOR S2 Users – Upgrade to LOR S3 Advanced

• Native in LOR S3 using Enttec Open/Pro (supported by LOR) / Lynx Dongle / HolidayCoro ActiDongle

• Native in LOR S3 using Lynx Dongle

• iDMX-1000 – converts LOR protocol to DMX  (not recommended)

• Play sequences in xLights – better output support and less moving parts

Misc

• LOR Controllers can listen to LOR and DMX allowing you to run all your controllers as DMX (DIY and LOR)

• There is “to spec” and there is “it works” – this is Christmas lights after all

Resources

• DMX Standards:

– Recommended Practice for DMX512 from USITT – book, purchase only

– BSR E1.11 Standard from USITT, book, purchase only

• RS-485

  – http://www.maxim-ic.com/app-notes/index.mvp/id/763  (wiring)

How To Question: Pixel Arches

Today's question comes from Phill who asks:

After reading, and watching several videos on your site, I would like to test an RGB Pixel setup (100 lights per string, using your tinypix controllers). I am using LOR S3 Advanced software, and would like you to verify what I will need (to make sure I don't miss anything).

Currently, I am just using the inexpensive Light-o-Rama USB485 dongle, at 500K (network speed), and it works great - will that work, or do I need to use one of your dongles, and if so which one - Ultimately, I will be using this for 12 arches (50 pixels each).

I know I need a 100 light pixel string, 1-tinypix, programming cable, and power supply - for the testing of the single string, I will just use one I have on hand). other then the possible dongle, is there anything else I will need???

 

So let's break down this issue - Phill would like to make pixel arches and he has indicated that he needs 12 of them at 50 pixels each.  My first question would be - what type of RGB pixel is being used here?  My guess is pixel strip given that the number is 50 pixels and pixel strip commonly comes in 16' lengths that contain 50 pixels (150 DMX channels), so we'll go with that given that pixel strip is a reasonable choice for pixel arches.

 

The next question I'd have is - what type of interface is going to be used here to get the sequencing data to the pixel controller?  50 pixels * 3 DMX channels (Red, Green, Blue) * 12  = 1,800 DMX channels - so that's a fair number of pixels and is comprised of 3 DMX universes (actually 4 because you would likely put 3 arches of 150 pixels each, within a single DMX universe of 512 channels.)  So, I think an RS-485 interface is out of the question here - the customer is going to need to go E1.31 for output of that much data.

 

So, to answer Phills question about LOR - yes, you'd need at a minimum LOR S3 advanced to get enough output and E1.31 support.  Phill would run the LOR network separately of the DMX network, so Phill's LOR settings really don't matter here since they don't impact the DMX E1.31 network.

 

Phill mentions needing a "100 light pixel string" which isn't correct based on my assessment that he has chosen RGB pixel strip, so maybe he is referring to 8mm pixel nodes?  If that is the case, usually 8mm pixel nodes would be a bad choice for this design - they don't mount well, you have to get them pointed in the right direction and they have less light output than the 5050 RGB chips in RGB strip - so we are going to just forget the 100 light pixel string reference and again assume he needs RGB pixel strip.

 

Phill also mentions needing a TinyPix -  I can't say if that is the case because I know nothing about the distances involved.  A centralized controller is great, something like the SanDevices E68x or the J1Sys controllers but they do have limits on distances you can place elements from the controller - yea, you can use null/ghost pixels to span longer distances but I'm not sure if we are talking 2 acres or a 5,000 sq/ft yard.  In the 2 acre, now a distributed pixel controller like the TinyPix really makes sense, if you have them all very close to each other, a centralized controller makes sense.  Now please note that the TinyPix is RS-485 based and thus would require "dongles" for output of each DMX universe as where the centralized controllers would require an Ethernet feed from the show computer.

 

So, to completely answer a question such as those posed by Phill, we need to know other relevant data such as:

• The physical design and layout of the display elements (arches)
• Any additional pixels/DMX channels used in the display
• The method the user will choose to sequence the display (software)
• The budget range for this project
• The skill level of the customer (plug-n-play or DIY)