Showing posts with label scope. Show all posts
Showing posts with label scope. Show all posts

13 October 2013

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:


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

08 March 2013

DMX & LOR Protocols and RS-485

I'm a firm believer in understanding "why" something does what it does and what effect those systems have on performance and reliability.  It is only when a person understands the underlying systems and processes that the "mystery" of why issues occur can be understood.  One area of confusion I see with customers comes up over and over and that is the relationship that the DMX and LOR protocols have with RS-485.  First, lets start with some basics:
  • Both DMX and the LOR controllers use a protocol for communicating between a PC (usually) and a controller (AC or DC) to make lights turn on or off at a specific time.  A protocol is nothing more than a definition of how two systems talk with each other - another example of a protocol would be TCP/IP or even the English language - it is nothing more than a set of rules that both parties/controllers agree on.
    • DMX Protocol:  The DMX protocol was defined in the early 1990's by the theatrical lighting community and is codified in a specific standard usually called DMX512 or E1.11.
    • LOR Protocol:  The LOR protocol was designed by Dan at Light-o-Rama in the late 1990's.  This protocol is unique to LOR and for the most part is not publicly used by other controller vendors.  The reason this protocol was created instead of using the existing DMX protocol was because of it's need to run very slowly (19,200 kb/s) compared to DMX's 250,000 kb/s as a result of a need to run on cheap, poor quality flat telephone cable (this is why you have a phone jack on an LOR controller.)
  • Both DMX and the LOR protocols run "over" RS-485.  RS-485 is a signalling protocol that defines the physical and electrical nature of the way each system will talk with each other.  Examples of this would be the Ethernet standard or how the letters of the English language are written.  RS-485 doesn't concern itself with what protocol is running over RS-485 but simply how the controllers interact at the physical and electrical levels.  This is why you can use a LOR "dongle" and output either the LOR or DMX protocols because the dongle is nothing more than a RS-485 output device - it is the software (LOR S3) that defines the protocol that is going out over the RS-485 connection.
There are some pros and cons to both the LOR and DMX protocols and we've covered those in previous presentations.  What is more important than the protocol (DMX, LOR) is RS-485 - this is where I see the majority of confusion, misunderstanding and problems.  Here are some common questions and answers to issues surrounding RS-485:
  • You can't "Tee" or split DMX/LOR signals
    • Again, this doesn't have anything to do with DMX or LOR - splitting a signal from an output dongle does have everything to do with RS-485.  On LOR controllers, there are two RJ45 plugs (excluding the one for telephone wire) for CAT5 cable.  You'll notice that there isn't really an "in" and "out" - why?  Because it doesn't matter.  As the signal comes from the output dongle to the first controller, then to the second and so on, all that is happening is that each controller is "tapped" or "tee'd" off a single data line.  Each controller simply listens to all the data on that RS-485 data line and waits for data that indicates that it should do something (dim, shimmer, etc).  This is the exact same with DMX controllers (in most cases) - the difference on DMX controllers being that some of them have XLR plugs which have a different connection for input vs output but in MOST cases, the controller is just connected to the wire.  (Yes there are some repeating/regeneration controllers but that is often the exception than the rule.)
  • Have you seen DMX controllers that only have only an input but no output?  Have you wondered if you need to split the signal to each one or have a separate output dongle for each one? 
    • Since there really isn't an input and output for the signal in most cases, all you need for a controller to work is to "tee" the controller off of the data line.  That could be that each controller is just manually soldered to each input and then the cable continues on to the next controller or by using a passive CAT5 splitter/tee.  So, if you have a controller that only has an input, it's not a problem - just split the signal outside of the controller as opposed to running the signal into the controller and then back out.  This is the same method we use on most HolidayCoro DMX controllers.
  • I hear there is a limit to how many DMX controllers you can hookup to a single DMX output dongle.
    • It depends.  Remember here that what really is at play is RS-485, not DMX.  So DMX doesn't limit you at all to how many controllers you can have hooked up to a single dongle - RS-485 limits you.  What are those limits - well it is a number of factors:
      • Power output of dongle - The RS-485 standard allows up to 19 volts of power for signal (-7 to +12).  So, the more voltage that is used for the signal output, the better.  This is somewhat like the difference between just yelling at someone a long distance away or using a bull horn - clearly the more powerful and amplified signal using the bull horn will go much feature and be much clearer to the recipient and will also be able to more easily overcome any background noise.  While the RS-485 standard allows up to 19 volts, nearly all USB based devices are limited to the USB voltages - about 5v.  Why does this matter?  Two reasons - noise and power loss - see below for more details.
      • Length and gauge of signal cable - Since cable itself induces loss, as your cable length increases or the gauge of the cable rises (see our blog entry on cable sizes and lengths), the overall strength of the signal also drops.  Lower power means there is a lower signal to noise ratio and you start to experience problems.
      • Type of cable - When selecting wiring for RGB elements, you have lots of choices out there.  Excluding the gauge of the cable, the other major factor of cable selection is how the cable is constructed.  There are two basic methods - twisted and non-twisted.  Why does this matter?  Twisted pairs of wires inherently does a much better job of rejecting EMI (noise) - this is the reason that all CAT5 cables are designed with twisted pairs of wires.  If you selected a cable (alarm wire, SPT cable, etc) without a twisted pair for the data signal, you risk greater EMI interference over straight cable.
      • Number of devices - Each controller exerts a "load" on the RS-485 line.  This basically means that as each new controller is added to the RS-485 line, it "sucks" some of the signal off, reducing the overall voltage on the line.  Once you get too many on the line and the voltage drops too much, the controllers are unable to determine the actual signal from any noise on the line.  So, how many can you put on a line?  It depends the the RS-485 chip used in the controller, some less efficient chips might limit you to 30 controllers, some might limit you to 100+ controllers on a single line.  How can you tell if you have too many controllers on the line?  Checkout this video article that shows about 50+ controllers connected to a single DMX output dongle.  You'll see that the only real way to know where you are pushing up against a limit is if you have the proper diagnostic equipment - namely a scope.  This is why we sell our pocket scope - so you can determine exactly what the RS-485 signal quality looks like.  We recommend this article by Maxim, the company that produces 485 chips if you would like in-depth details.
      • Termination - While "technically" all RS-485 connections should be terminated with a resistor, the reality is that it is often not needed and in fact, LOR doesn't even terminate their controllers due to the inherent design of their system (slow speeds and forced bus connections/tapping.)   When and where you need termination mainly varies based on the wiring scheme (serial/bus, long taps, location of output dongle on the line, etc) - the best place for technical details on the do's and dont's of termination is in the Maxim article.  You can also watch our video showing a real world lighting display, over a scope, showing what effects adding or removing a terminator will do to the signal.  Be aware that termination is no free ride and won't fix a bad network design.  Terminators are resistors and as a result, the "suck up" and reduce the level of signal - so while it might clean up the signal, you might end up with too little signal to make a difference.
With all this said, the vast majority of networks are simple and even when improperly constructed with the wrong wire, bad termination, long taps and other errors, RS-485 (and thus DMX and LOR) still continues to work.  Why?  Because RS-485 was designed just for this - to work in environments like factories with bad wiring, lots of EMI and long runs of cable.  When you really need to be concerned about these issues is when you get dozens of controllers, over long lengths of cable and with bad cables or connections.  If you are one of those people, we *highly* recommend getting a scope because without one, you'll only be guessing as to what the quality of your network is or where a problem might exist.

I welcome your feedback or suggestions below.

Thanks,
David
HolidayCoro.com