Renting a DMX splitter and various long cables for the last band gig provided the opportunity to see what such a unit does and do some signal analysis across various types of transmission line. The unit was a typical Doug Fleenor Design 5-way isolated splitter, which generates a fresh RS485 signal into each of 5 outputs. I had the unit at home for a while, and decided to fire up what laughingly passes for signal analysis gear at home [i.e. an analog o-scope and a critical eye] and continue the recent thread where things like using cat5 twisted-pair cable to carry DMX had been discussed. ========================================================= *Note*: this document is a text-only description of events and experimentation done in 2004. The topic was revisited in 2015, using a new type of splitter, with plenty of illustrative waveform pictures taken under various configurations of transmission cable. See this page: http://techno-fandom.org/~hobbit/lighting/dmxwave/ ========================================================= Having had some DMX troubles with a Leprecon VX dimmer pack at Arisia, this is freshly relevant to me. The effects of different cable types on signal quality is something I'm curious about, because there seems to be a lot of black magic and FUD around the topic -- where people assert everything from "oh, you MUST use this particular type of cable or you'll just have a ton of problems" to "I run all my movers on the crappy mic cable that the sound guys were going to throw away as bad, without a terminator, and NEVER had any problems". So which is it, already?! This is an effort to gain some real-life insight, as well as explore the possibility of using commonplace cheap data cable to control a rig. Some people don't even seem to realize that DMX bit rate is an order of magnitude *higher* than any audio signals, and that it's one reason generic audio cable might not carry it all that well. A quick review of DMX: RS485 differential serial data at 250Kbaud, swing around 2 to 3 volts into 120 ohms, normally appearing at a female 5-pin XLR connector wired thus: 1 shield 2 data - 3 data + 4 n/c [or custom option in some systems] 5 n/c [or custom option in some systems] Running protocol sends packets in the form ... idle in mark state, data+ is high and data- is low ... break [88 uS or so of space] start code byte [normally value 0] data byte 1, aka slot 1 data byte 2, aka slot 2 ... data byte 512 [or less if running with fewer channels] for a maximum of 513 bytes, or start-code + 512 "slots" as they're officially called. Each data byte is sent as a frame containing start bit, value 0 8 data bits, LSB first 2 stop bits, value 1 inter-frame [aka "mark before break"] time, varies and can jitter Each bit time is 4 uS long. Note arguable misuse of the word "frame". The whole packet simply repeats 20 or more times per second and has no error checking at all, so if a device misses a value for whatever reason it will probably pick it up the next time around. Receiving devices simply count and discard bytes after the start code, until the slot corresponding to their own DMX start address is reached, when they start paying attention and collecting values until past the last slot of concern to them. Referring to byte offsets as "channels" has fallen out of favor with the spec-writers, since there are now many devices that aren't dimmers. Control consoles which don't handle 512 channels have the option of ending the packet at any point and returning to the idle state, which signals the end of the sequence to receiving devices. For systems with few channels, this allows a faster overall refresh rate. Watching this on a scope is fairly easy, and fiddling with an A/B delayed timebase allows expanding out parts of the frame and observing single bits changing in specific bytes as DMX output from a console is changed. Sending values 85, or 55 hex or 33% output, gives the "worst case" pattern of alternating bits, or the closest thing to a burst of 125KHz squarewave. This allows viewing the fastest signal changes, and was the output primarily used for testing. What is critical is that bit levels electrically settle to a sufficiently stable value on the line before the receiver takes its sample, which may be an iffy situation in degraded transmission environments. It is interesting to note that the time between individual bytes can jitter a certain amount, but the timing of the bits themselves must be rock-solid. Well, that's how asynchronous data works, but honestly I thought the timing would generally be a little more stable. Then again, the Hog stuff is probably doing a lot of other things in between figuring out what the next channel's value should be. In general, it seems that very few boards or software packages do much in the way of hardware assist in building/transmitting the DMX packet -- the main processor does a lot of work outputting that byte by byte. In the real Hog boards with their old, slow i860 or the like processors, this causes a known problem that when a show is saved to floppy, DMX output virtually ceases entirely, causing lights to freeze or go entirely wacko until the show finishes saving. On the much faster PC version, this "#1 bug" as it's called isn't a problem since the software can hand a lot of work off to the OS's disk drivers. The real-life test setup was the Hog widget outputting channel 1 at 0x55 and everything else at zero, either driving candidate cables directly or passing through the DMX splitter first. The waveforms from each were very different, and subsequent research confirms that the Hog widget uses the slew-rate-limited MAX483E driver, and the DFD splitter uses the Nat Semi 75176 which whips the output high and low as fast as it can -- so fast that the vertical rise is almost invisible on the scope. The drawback to fast-risetime signaling, of course, is that it tends to ring more into a cable and emit more harmonics. The Hog takes about half a microsecond to complete a transition. Limiting slew rate, or the moral equivalent of that "warm" sound with some of the highs rolled off, is one technique for getting cleaner signals into a transmission line -- i.e. you only go as fast as you need to. Thus, I had two "qualities" of source signal available. Output was converted into 3-pin XLR [i.e. what runs out to most wiggle lights], and then a simple 3-pin XLR passthrough with partial bare leads hanging out provided a place to scope the lines. The tap could be inserted anywhere along the various test lengths of cables where they connected together, to see where data might be getting mangled worst. [The offending dimmer pack at Arisia was near the beginning of the line, but was clearly affected by changing things around *downstream* of it, way over on the other balcony at the far end.] Cables available to test with were two hundred-foot lengths of supposedly DMX-rated data cable, some equally long mic cable, and a little cat5, as well as a handful of shorter mic cables of unknown impedance characteristics. Most people agree that DMX needs to be terminated, and tests clearly confirm that. An unterminated signal into a long cable can easily keep ringing and wandering and settling right up until the next state change, and adding a terminator gets it under control much earlier. Now, I've got two types of terminators -- one that's just a 120 ohm resistor, and a couple that are a 100 ohm resistor in series with a bi-color LED that flickers red/green to show valid signal. This isn't really the correct way to do the with-LED termination, since driving the LED introduces slight nonlinearities, but the difference is fairly minor and my LED type is still clearly good enough to do the job on most runs and provide a useful diagnostic. Reading between the lines of what Doug Fleenor says about *their* "happy light" DMX terminator indicates that they use 110 ohms in parallel with a low-current LED and a higher limiting resistor like 1K, to reduce nonlinearities. But either way, there's an easily visible difference between terminated or unterminated. Because of that, most test results below assume a terminated line. There was actually relatively little difference between 200' of "proper" RS485 cable I had available as part of the rental, and 200' of normal sound cable. A bit of rounding-off of the transition leading edges, no real biggie. Perhaps the mic cables happened to be close to 100 or 120 ohm characteristic impedance. I've got no good way to test that other than eyeball signals going into or emerging from both. Some of my own shorter mic cables introduced different types of minor distortion, probably because of small reflections from several connectors in line, but nothing that would invalidate per-bit levels. Sending into a twisted pair in a cat5 cable actually yields a fairly clean signal, with a bit more high-speed ringing from the DFD splitter that settles out very quickly. It is already known that 100 ohm cat5 cable has good potential usefulness passing DMX data; there used to be a nice online reference at http://www.esta.org/tsp/DMXoverCat5.htm from the ESTA working groups when they were pursuing this, which seems to be gone now. The primary result of that work is a sensible RJ45 pinout to send DMX over existing horizontal network infrastructure in buildings -- using pair 2 for primary TX+ and TX-, just like ethernet. ========================================================= [2015 update: The page in question is now http://tsp.plasa.org/tsp/working_groups/CP/DMXoverCat5.htm . There was apparently some disagreement on which wires to use for ground or common. ESTA eventually settled on using pair 4, brown in the EIA-568B scheme. Search for "dmx" and "cat5" and "rj45" to find plenty of info on it. Meanwile, I had gone ahead and built an assortment of stranded-UTP XLR cables in both 3 and 5 pin, using white/blue and white/brown together as a "fake shield", and they have worked just fine ever since.] ========================================================= As a "worst case" test, I hooked up *all* of my cruddy mic cables end to end, all the rental DMX and mic cable, and the cat5 "experiments", and hung a wiggle light out at the end. It seemed to work fine either direct from the Hog or through the DFD splitter. Waveform samples taken at roughly the midway point were the most mangled, and showed a little ringing and rounding but nothing that would exceed the voltage threshold, i.e. data would be valid by the right time. The direct Hog output was a little cleaner because of the slew limiting, in fact. But what, one may argue, is the right time to sample data? Fleenor's articles on the website hint somewhere that in most receivers, the data sample is taken halfway through the bit time. But if it's known that receivers for this stuff may often wind up in harsh environments with buggered signaling, wouldn't it make more sense to take the sample at, say, 75% of the bit time after the state change is observed?? After all, if you're clocking at, say, 1 MHz, you could wait for three clocks after the edge instead of two and then read the bit, which would allow another microsecond for settling. It probably all depends on what the receiving UART or microcontroller or whatever does once it sees the start bit. Fine points, but still could make the difference between a robust receiver and a squirrely, unreliable one. The RS485 spec doesn't specify a maximum line length, but practical documentation seems to set it at 4000 feet. RS485 also gives a maximum of 32 "unit loads" per line, which are receiver taps of about 12 Kohms apiece. [32 loads equals about 375 ohms.] At Arisia, I in theory had ten loads -- eight wiggles and two racks, spread over about 400 feet. So let's review: slew-rate limited output, line length way less than the maximum, ten loads, "real" data cable for the longest runs, and *possibly* real data cable for the short jumpers -- even though a lot of the short rental stuff looked like mic cable, it should have been sufficiently clean. And only the one pack seemed faulty -- all other devices around the room worked fine. The problem was still there unchanged when I moved the laptop right up to the first wiggle, too. So I can only conclude that the pack in question has a really marginal receiver, and that enough cable-swapping managed to get things sufficiently this side of its marginality to make it mostly work for the night. This, in fact, was later confirmed by one of the rental techs, who said, "oh, it was one of those VX packs? Yeah, they cause problems sometimes because they used an RS422 receiver chip instead of the real SN75179, and it isn't quite up to higher speed RS485 spec." Well, there you have it. But they probably rarely have problems with it in other situations, since it's likely to be standalone or maybe ganged with one or two other packs nearby. They would have to deliberately create a degraded test environment around it to try and duplicate the problem, and who's got the time to mess with that in a busy shop where that pack could instead be out on another show making revenue? Perhaps they should just try to retrofit a better part someday, if it's socket-compatible and if they care... While exploring the innards of the DFD splitter I noticed that the five transmitters have jumpers where 56 ohm resistor pairs would normally go in series with the output to drive it at about 120 ohms. This bothered me a little since most driver circuits I've stared at seem to introduce a source impedance to match the expected transmission line. I had also started thinking about a useful converter widget, with XLR of various sexes/pincounts/polarities on one end and female RJ45 on the other, which would possibly allow using cheap commodity cat5 patch cables to run DMX on and just convert/adapt to each device along the way. Now, who would be the right company to start making such things? Doug Fleenor Design, for one, since they do a number of similar toys... Thus, I had two questions for one of their techs if they had the time to entertain them, and called in. And before I knew it, I was enjoying the honor of talking to Doug Fleenor himself! We had a very pleasant conversation, in fact. First, he pointed out that driving the line at full current capability and terminating at the *far* end had been found to work way better than trying to match source impedance, and in fact if one had the source resistors *and* the terminator that would only form a voltage divider that might wind up lowering the line voltage too far for receivers to decode it. He determined that the unit I had was one of the first-gen ones but had evidently been retrofit, and pointed out that after a while they started just jumpering those resistors in new units and any that they got back for repair. So the 56 ohm pair would have been a legacy of old design thinking that had been superseded by real-life discoveries, and newer units don't even have a place for them. Since many far-end receivers [i.e. rigs full of movers] are now more commonplace than the traditional one or two dimmer packs, impressing full signal across all the combined loads and soaking up the excess downstream is the right thing to do. Then, with regard to the RJ45 converter widgets, Doug pointed out that while UTP might work fine in many environments, ESTA had *not* concluded that it met all the necessary specs, particularly with regard to *shielding*, and was therefore deemed "unsuitable" because of the potential for outside interference. ESTA's jury is in fact still out on the subject, since they haven't yet set up the proper test environment. Doug raised the entirely appropriate scenario for the time: you've run UTP to the large rig you've hung all over the stadium, and your *rehearsals* for the big Super Bowl halftime flash-n-trash have run flawlessly. Now it's game day, and you bring in a live load of fans, all of whom are on their cellphones, and lots more security people with radios, and more power draw from concessions or what have you, and suddenly when your lights absolutely *have* to work they all go brain-dead. Too much liability in that situation, Doug said -- if ESTA had said that UTP cable was okay and then it started introducing problems. So they're saying to stick with shielded cable. Doesn't matter for little clubs and such, but they also keep in mind the perspective of critical, high-dollar events. He thought that while foil shielding gives 100% coverage and typical braid gives about 80%, that using one or two additional wires in UTP as sort of a fake shield might do 20% relative blocking of induced RFI at best and maybe still fail under strong fields. My own seat-of-the-ass testing by waving an inductive probe around in a coil of the UTP sort of confirms this, when I could hear just a little bit of the DMX packets going by. DMX has no error checking, unlike ethernet, so mangled signals can still cause actions at a receiving device. That's the main reason it's not kosher for use in life-safety-critical applications like truss motors or pyro. Still, the data signals are supposed to be *differential*, reject common-mode disturbances, and have proper twist all the way down! I told him I still intended to experiment, and just be prepared to swap in different cable if UTP was proven wanting. He wished me luck, and said that perhaps some simple injection molding around XLR and RJ45 connectors could result in robust widgets of the right type that suddenly everyone would want tons of and make me my first million. We both chuckled, and noted that neither of us were anywhere close to tooled up to produce such things. Now, there *is* 100 ohm shielded twisted-pair cable available, at about twice the cost of UTP which works out to about $.20/ft on the street. But taking that into account, along with RJ45 widgets, non-snag RJ45 heads, and touring-grade cable with jackets that can take being run over with heavy casters many times ... cost per hop might approach the cost of the regular DMX data cables anyways, at least for short lengths. So -- we small-time clubbers, rock-n-rollers, and community-theater geeks could probably consider soldering XLR connectors straight onto UTP [preferably stranded] as an upgrade from our cast-off mic cables, but the big boys will probably continue to spring for Proplex and the high-end Belden stuff like they always have. Then again, the big boys are starting to go *wireless* in a big way -- hmm, and they're worried about *interference*?! Aiieeeee... * * * Amusing anecdote, 11+ years after this was written and Fleenor's products were already well-established: As more players entered the DMX splitter market at lower price points, I eventually went shopping around, but wanted to know the output characteristics of any given candidate. One afternoon I had a "tech support" guy for one of the manufacturers actually try to tell me that *because* the outputs of a DMX splitter happen to be opto-isolated, they are inherently slew-rate limited. Why? Because, he insisted, "Doug Flutie" said so. Misquoting *and* misnaming an industry authority who doesn't even work for his company. Obviously the parts that optoisolate and the parts that drive an RS485 line are quite different pieces of the signal chain, each able to produce its own designed risetime. It's hard to imagine anyone being able to make an assertion any more professionally embarrassing than that. Upshot of the conversation: that brand uses generic "fast" 75176 chips, as do many of the others. By that same time, my own hack UTP/XLR cables had a decade of gigs behind them in which they performed flawlessly while carrying whatever waveforms we threw at them. So there's hard real-world evidence that UTP, preferably stranded as it handles flexing and coiling better than solid, is a good low-cost alternative to the high-end cable. _H* 040203, small update 150521