# Understanding Specifics of the DMX512 Protocol [Newbie Nate's Question of the Day]

#### NateTheRiddler

##### Well-Known Member
Morning, CB!

Time for another NNQotD! Thanks to recent joblessness, I've been recently taking a signals course from ETC that goes into detail re: the DMX-512a protocol, and I have a few rather practical questions. No need to answer them all at once, since I have quite a few, and have all the time in the world to wait for answers:

1. As I understand, DMX-512 inherits the properties of its parent protocol, RS-485. Two of these properties are a limiting length of 1,640' of home run wire, and a limit of 31 receiving devices. Is this a hard and fast rule, or a recommendation? I've worked on systems (that I did not design, however) that place much more than 32 devices on a single universe contained within a single cable run. What are the potential consequences of exceeding this limit? Also: I've been taught that 300' is the practical limit for a DMX home run, particularly if non-terminated. Am I remembering that wrong?
2. Piggybacking off of question #1, I've noticed that the RS-485 "stub rule" (no more than 12" of wire between data backbone and receiver) is violated by DMX-512, but is considered an acceptable violation. Why is this? Are there no consequences to violating that inherited property? Why does the stub rule exist for RS-485 in the first place? I can't find an explanation anywhere in the course.
3. The course has not explained what pins 4 and 5 are for on a 5-pin XLR connector. I assume 4/Data 2- and 5/Data 2+?
4. What does terminating really do for a system? I assume that by increasing resistance at the end of a data run, if data were to flash back/reflect, it would be far too weak (not enough voltage) to meet the requisite threshold to trigger the comparator inside the receiving device's decoder? So why not terminate with a much higher resistance than 120ohm? Or is 120ohm more than enough to do the job already?
5. Within the structure of a DMX packet, I've noticed that there are specific timings associated with the MAB and interbytes, to allow for counter reset and counter increment, respectively. These times have been set to a minimum of 8μs, but can be slowed if necessary. I understand that if a [less capable] device's counter is unable to reset in time, it will either lose its place in the packet, or perhaps never clear its framing error. Is that what devices such as the Doug Fleenor DMX Decelerator are for? To lengthen timings of the MAB and interbytes to allow inferior/slower counters to "keep up"?

Thanks for those of you who take time to answer one or more of these questions. Figured I should use my time "off" to really amp up my educational pursuits in entertainment, and a better understanding of DMX seemed a great place to start.
Also, I'll go ahead and put my ego aside and ask: does anyone have any theatrical studies textbooks they no longer need? I want to keep studying, but I've hit the limit of what I can afford to purchase, and $60+ for each textbook while being out of work really doesn't seem wise right now. I'll happily accept digital copies if they exist, as well. Please DM me if you are willing to help, I really do appreciate it. Thanks! NOTE: I've gotten some preliminary/rough answers on these questions from Wikipedia (I RTFM'd), but I'd prefer expert opinion/fact over Wikipedia's version of fact. Last edited: RonHebbard #### sk8rsdad ##### Well-Known Member Premium Member Fight Leukemia Many of your questions could be answered by using the Search feature of the site. It's a good skill to be developing in your downtime. Regarding #1, the limit is a 32 UNIT LOAD including the transmitter, not to be confused with 32 DEVICES. Many (most?) transceiver chips developed since DMX-512a was first published are fractional load. So if every device on the link is using fractional load transceivers, and presuming the noise and line loss from all the connections don't become excessive it is possible to have a lot more than 31 physical devices on a DMX run. For some light reading have a look at the TI THVD1550 5V RS-485 transceiver. Notice it is a 1/8 unit load device. The 300' limit is not true, at least not for DMX-512a which operates at around 250 kBPs. Higher frequency transmission shortens the range. Perhaps you are confusing it with ethernet? #### NateTheRiddler ##### Well-Known Member Premium Member Many of your questions could be answered by using the Search feature of the site. It's a good skill to be developing in your downtime. Touche! I had searched the site vaguely but not dug too hard. That's on me. So if every device on the link is using fractional load transceivers, and presuming the noise and line loss from all the connections don't become excessive it is possible to have a lot more than 31 physical devices on a DMX run. Oh! Fascinating, didn't even know a fractional load was possible. My EE/CE background is really weak here. How does one know that a device has a fractional load transceiver? Os is it assumed to be the standard? Perhaps you are confusing it with ethernet? I've got enough random information in my head that this wouldn't surprise me. I'll make sure the 1640' sticks in my head better. Does that 1640' include Cat5e runs that are carrying DMX packets? I presume that, realistically, we probably don't get too close to this limit, even on massive rigs, so my question might just be insatiable and inane. #### almorton ##### Well-Known Member Question 4 is a fairly complex one. At the even moderately high frequency that DMX operates at (about 250kHz), the cabling behaves as a transmission line. This is a somewhat involved field which you may be aware of, but essentially, to stop reflections and standing waves in the line, it needs to be terminated at what is called its characteristic impedance. Turns out if the check the spec that the characteristic impedance of DMX lines is 120 ohms (in fact for DMX you can get away with 100-120). This is also why using non DMX cabling is frowned upon - for example, mic lines typically have a 600 ohm characteristic. If a transmission line isn't terminated properly then you do indeed get reflections and interference patterns, leading to local minima i.e. dropouts. By terminating, the signal is correctly absorbed at the end of the line and can't bounce back and interfere. Look up transmission lines - it's a rather interesting field, especially when you get into wave guides ... #### RonHebbard ##### Well-Known Member Premium Member Morning, CB! Time for another NNQotD! Thanks to recent joblessness, I've been recently taking a signals course from ETC that goes into detail re: the DMX-512a protocol, and I have a few rather practical questions. No need to answer them all at once, since I have quite a few, and have all the time in the world to wait for answers: 1. As I understand, DMX-512 inherits the properties of its parent protocol, RS-485. Two of these properties are a limiting length of 1,640' of home run wire, and a limit of 31 receiving devices. Is this a hard and fast rule, or a recommendation? I've worked on systems (that I did not design, however) that place much more than 32 devices on a single universe contained within a single cable run. What are the potential consequences of exceeding this limit? Also: I've been taught that 300' is the practical limit for a DMX home run, particularly if non-terminated. Am I remembering that wrong? 2. Piggybacking off of question #1, I've noticed that the RS-485 "stub rule" (no more than 12" of wire between data backbone and receiver) is violated by DMX-512, but is considered an acceptable violation. Why is this? Are there no consequences to violating that inherited property? Why does the stub rule exist for RS-485 in the first place? I can't find an explanation anywhere in the course. 3. The course has not explained what pins 4 and 5 are for on a 5-pin XLR connector. I assume 4/Data 2- and 5/Data 2+? 4. What does terminating really do for a system? I assume that by increasing resistance at the end of a data run, if data were to flash back/reflect, it would be far too weak (not enough voltage) to meet the requisite threshold to trigger the comparator inside the receiving device's decoder? So why not terminate with a much higher resistance than 120ohm? Or is 120ohm more than enough to do the job already? 5. Within the structure of a DMX packet, I've noticed that there are specific timings associated with the MAB and interbytes, to allow for counter reset and counter increment, respectively. These times have been set to a minimum of 8μs, but can be slowed if necessary. I understand that if a [less capable] device's counter is unable to reset in time, it will either lose its place in the packet, or perhaps never clear its framing error. Is that what devices such as the Doug Fleenor DMX Decelerator are for? To lengthen timings of the MAB and interbytes to allow inferior/slower counters to "keep up"? Thanks for those of you who take time to answer one or more of these questions. Figured I should use my time "off" to really amp up my educational pursuits in entertainment, and a better understanding of DMX seemed a great place to start. Also, I'll go ahead and put my ego aside and ask: does anyone have any theatrical studies textbooks they no longer need? I want to keep studying, but I've hit the limit of what I can afford to purchase, and$60+ for each textbook while being out of work really doesn't seem wise right now. I'll happily accept digital copies if they exist, as well. Please DM me if you are willing to help, I really do appreciate it. Thanks!

NOTE: I've gotten some preliminary/rough answers on these questions from Wikipedia (I RTFM'd), but I'd prefer expert opinion/fact over Wikipedia's version of fact.
If a DMX run was unterminated. the power consumed / drawn from the source would be minimal.
In a sense, the line could become an antenna picking up any noise / interference / RFI/ EMI. At some point you could easily have more noise on the line than signal. When you terminate the line, you're drawing more power / a stronger signal from the source driving the line. Drawing more power / a stronger signal down the line improves your signal to noise ratio.
If / when you employ an optically coupled splitter, your original source only sees the load of the splitter's input plus any other devices looped off in parallel with the input. Each optically coupled output is driven / powered by a new driver / source thus each output of the splitter can drive another ~30 full load devices or ~60 x 1/2 loads or ~120 x 1/4 loads; you've got the concept.

Toodleoo!
Ron Hebbard

#### derekleffew

##### Resident Curmudgeon
Senior Team
OK, for my turn, #3. The purpose and intent of pins4&5 has changed with every revision of DMX512. I think @sblair said it best when we weren't even on the latest revision. Search for it.

#### NateTheRiddler

##### Well-Known Member
Look up transmission lines - it's a rather interesting field, especially when you get into wave guides ...
That's an intimidating amount of information. I'll roll up my sleeves and get my eSet dictionary ready. I've got time, so no reason not to fascinate myself with this.

If a DMX run was unterminated. the power consumed / drawn from the source would be minimal.
In a sense, the line could become an antenna picking up any noise / interference / RFI/ EMI. At some point you could easily have more noise on the line than signal. When you terminate the line, you're drawing more power / a stronger signal from the source driving the line. Drawing more power / a stronger signal down the line improves your signal to noise ratio.
I hadn't thought of it in a raw power scenario; it makes sense that in the absence of a signal, signal can be inserted where not intended. If a strong signal exists, it's hard to screw it up.

OK, for my turn, #3. The purpose and intent of pins4&5 has changed with every revision of DMX512. I think @sblair said it best when we weren't even on the latest revision. Search for it.
I found good results on this in both in the current definition of the DMX standard and on Wikipedia, implying that they are indeed second data lines (similar to the data2s in a Cat5/6 cable). I was wondering in a more practical sense if those pins had come into recent use, but searching extensively online says they have not. Does this imply that at some point the 5-pin standard might come into question in favor of a 3-pin instead? Or will we continue to maintain the 5 pin availability in hopes that the two additional pins will actually gain standardized use?

EDIT: Thank you everyone thus far for your answers; in absence of a professor to teach me coursework on this (I have neither the money nor a curriculum nearby), you have all done a marvelous job satiating my curiosity.

RonHebbard

#### Rob

##### Well-Known Member
Does this imply that at some point the 5-pin standard might come into question in favor of a 3-pin instead?
No! This comes up too often. The reason for the 5-pin was so people didn't pick up cheap 600 ohm mic cables. Analog cables don't work well with digital signals. A lot of 2nd tier manufacturers save a nickle by putting on the ubiquitous 3-pin XLR, but the standard says for portable cabling it must be a 5-pin. You could share the ground and use the 2nd twisted pair (I did this 25 years ago), but today people use opto splitters which are a much better practice as they isolates your grounds. Typically you want two universes to go in two directions in any case.

#### NateTheRiddler

##### Well-Known Member
No! This comes up too often. The reason for the 5-pin was so people didn't pick up cheap 600 ohm mic cables. Analog cables don't work well with digital signals. A lot of 2nd tier manufacturers save a nickle by putting on the ubiquitous 3-pin XLR, but the standard says for portable cabling it must be a 5-pin. You could share the ground and use the 2nd twisted pair, but using an opto splitter is a much better practice which isolates your grounds.
I feel rather very silly not having considering that. I suppose I've never contemplated using mic cable as DMX cable, but I know that's been a hot debate. Must have slipped my mind. So it's merely a situation of establishing identity of the cable, and that makes sense. Apologies for rehashing a popular topic.

RonHebbard

#### DrewE

##### Well-Known Member
RS-485 isn't so much a protocol, as such, but a rather lower level standard of signaling, a transport and physical layer standard (to use computer networking terms). It mainly defines electrical characteristics: what defines a one bit or a zero bit on the wires, how fast they can change under different conditions, and so forth. I think it also defines the use of asynchronous serial data transfer, or at least very strongly implies that in practice: that the data bus is in a mark state when idle, and a byte consists of a (usually single) start bit, followed by the data bits, any parity bits, and some number of stop bits before the next byte. RS-485 signaling (and its very close relative, RS-422) is very commonly used in many different applications. A lot of the limitations on lengths and loading and such do come from RS-485.

If you're curious, the main difference between RS-485 and RS-422 is that RS-485 implies the possibility of bidirectional data on the differential pair of wires, with more than one transmitter using the bus at various times, and generally suggests many different things in a network of some sort. RS-422, on the other hand, is unidirectional (one sender to usually one receiver) and bidirectional data transfer requires two sets of wires, one for each direction. Electrically they are very similar and many driver chips are made that can be used for either one.

The stub rule is related to termination; a long stub provides a place for reflections and such to develop in the transmission line. Most DMX512 devices, or at least the ones I have seen which is a bit limited, do not come anywhere near breaking this rule as the internal connection between the in/out connectors and the main circuit board is quite short. Y cables should not be used with DMX512, of course. Splitters/optoisolators do not break this rule because each output is electrically a separate bus with its own transceiver.

My understanding is that the DMX decelerator is intended to correct or extend the timings for devices that can't cope with the minimums. These days, it would be a little surprising (to me, at least) to find any new devices that could not keep up; microcontrollers perfectly capable of reading and interpreting a DMX packet cost pennies (well, maybe nickels or dimes) in even small quantities. In fact, I suspect many would work just fine with well under the minimum timings, say with one rather than two stop bits (i.e. the interbyte timings). Naturally I'm not recommending that you violate the standard's timings and expect everything to work properly; I merely suspect that it probably would work in some (many?) cases.

#### NateTheRiddler

##### Well-Known Member
RS-485 isn't so much a protocol ............................. some (many?) cases.
Thanks @DrewE for the excellent supplemental information. I wasn't offered a comparison to RS-422 in the course, and that actually provides additional understanding to why a 5-pin connection was chosen. Thank you for the correction in terminology as well, I should probably be careful calling things protocols that are not actually as such.

I had misunderstood the stub concept; I was imagining something silly, and had never considered that the data backbone is technically the DMX daisy chain, and the stub is the distance between the IN to the board and from the board to the THRU (which is an incredibly short distance, much less than 12").

RonHebbard

##### Well-Known Member
Fight Leukemia
Does this imply that at some point the 5-pin standard might come into question in favor of a 3-pin instead?
It is highly unlikely that DMX will ever be full duplex; that is, make use of the second pair. Ethernet protocols like E1.31 and E1.33 already provide bidirectional communication at faster data rates. The industry would adopt those instead.

#### derekleffew

##### Resident Curmudgeon
Senior Team
Or will we continue to maintain the 5 pin availability in hopes that the two additional pins will actually gain standardized use?
We will continue to use 5pin, but not for your "in hopes" reason. This thread, starting here , especially item#8 of this post.

#### NateTheRiddler

##### Well-Known Member
We will continue to use 5pin, but not for your "in hopes" reason. This thread, starting here , especially item#8 of this post.
Fascinating and excellent read, thank you!

#### DrewE

##### Well-Known Member
Thanks @DrewE for the excellent supplemental information. I wasn't offered a comparison to RS-422 in the course, and that actually provides additional understanding to why a 5-pin connection was chosen. Thank you for the correction in terminology as well, I should probably be careful calling things protocols that are not actually as such.
DMX512 with RDP is bidirectional already; data flows in both directions. It is not, as sk8rsdad alludes to, full-duplex.

Just in case some of the terms aren't clear:

Unidirectional: data only goes one way, like broadcast radio or TV or remote controls. Something sends, something else (or multiple other things) receive.
Bidirectional: data can go in both directions, like a telephone.

Simplex: a wire/connection carries data in only one direction, which basically implies unidirectional communication.
Half-duplex: a connection can carry data in both directions, but only one way at a time. Walkie-talkies are half-duplex; when someone is talking, the other person must be listening and vice-versa.
Full-duplex: a connection can carry data in both directions simultaneously. Telephones are basically full-duplex.

As a practical matter, the precise details of how DMX512 data gets onto the cables and then interpreted is probably not of exceptional importance unless you're designing equipment to send or receive DMX512 data, any more than knowing how USB or telephone signaling works is necessary to make calls or use a mouse or print stuff out.

#### SteveB

##### Well-Known Member
A thanks to Nate for asking the questions, I AM learning stuff !

#### Chris Pflieger

##### Well-Known Member
RS-485 isn't so much a protocol, as such, but a rather lower level standard of signaling, a transport and physical layer standard (to use computer networking terms). It mainly defines electrical characteristics: what defines a one bit or a zero bit on the wires, how fast they can change under different conditions, and so forth. I think it also defines the use of asynchronous serial data transfer, or at least very strongly implies that in practice: that the data bus is in a mark state when idle, and a byte consists of a (usually single) start bit, followed by the data bits, any parity bits, and some number of stop bits before the next byte. RS-485 signaling (and its very close relative, RS-422) is very commonly used in many different applications. A lot of the limitations on lengths and loading and such do come from RS-485.

If you're curious, the main difference between RS-485 and RS-422 is that RS-485 implies the possibility of bidirectional data on the differential pair of wires, with more than one transmitter using the bus at various times, and generally suggests many different things in a network of some sort. RS-422, on the other hand, is unidirectional (one sender to usually one receiver) and bidirectional data transfer requires two sets of wires, one for each direction. Electrically they are very similar and many driver chips are made that can be used for either one.
A well written explanation, but just a few nits.
RS-485 is a protocol - just a low level one that doesn't define any formatting. It's a spec of the physical layer in a protocol stack.
RS-422 isn't unidirectional; it's bidirectional, full-duplex. It's raison d'être is to replace RS-232 in applications where noise immunity and longer lengths is required.
You can always use an RS-422 driver chip with an RS-485 network, but not vice versa.

My understanding is that the DMX decelerator is intended to correct or extend the timings for devices that can't cope with the minimums. These days, it would be a little surprising (to me, at least) to find any new devices that could not keep up; microcontrollers perfectly capable of reading and interpreting a DMX packet cost pennies (well, maybe nickels or dimes) in even small quantities. In fact, I suspect many would work just fine with well under the minimum timings, say with one rather than two stop bits (i.e. the interbyte timings). Naturally I'm not recommending that you violate the standard's timings and expect everything to work properly; I merely suspect that it probably would work in some (many?) cases.
It's not so much that the CPU can't keep up, it's that the engineer wrote crappy code, and had shoddy testing.

#### microstar

##### Well-Known Member
Fascinating and excellent read, thank you!
Around 1993, Rosco/Entertainment Technology (ET) had their "Talkback" system which used pins 4 and pin 5 to communicate information from their Intelligent Power System (IPS) dimmers to their consoles like the Eclipse and the Horizon software consoles. From one of the manuals:
"Dimmer Configuration shows the actual number of the dimmer displayed, the DMX address of the package which contains it, It's offset within the package, and its rating in Kilowatts.
The Toggle Detail function (F5) changes the display to additionally show the total number of dimmers in the package, the package firmware revision, the full output voltage, the fall/rise time mode, and the load/source mode.
The Operating Status display shows the dimmer's present heatsink temperature in degrees C, its present output level, its connected load in Kilowatts and the load type, and the present power line voltage."

They also made the Status Monitor which was a box that intercepted the "Talkback" line and displayed the IPS dimmer information on a separate video monitor so allowed the system to be used with any console.

A great source for learning about DMX is Adam Bennette's "Recommended Practice for DMX512--A guide for users and installers".