Not going to work I bet: DMX and digital snakes

For DMX-512 Protocol specs, check out the USITT Standard. Another option might be John Huntington's book "Control Systems for Live Entertainment". It covers DMX in detail, in addition to a slew of other entertainment protocols.

-Griffin

Also, off the top of my head...

DMX is based off RS-485, which is serial.

To my knowlege DMX over 4 pins is not bidirectional*, doesn't have error correction or any fun stuff like that. I'll see if I can find my copy of the book above. It should have the answer.

*I suppose it's physically bidirectional if you have feedback running on pins 4 & 5...

-Griffin

I can't find any online resources that GIVE the information I'm looking for, so I'll buy a buy.

DMX-512 is only using 3 pins, since in my DMX cable I am only using 1, 2 & 3, wired 1-1. It could be bidirectional, you only technically need 3 wires(OK, 2 if you like being flaky), a TX, an RX(I'd assume pins 2 and 3 respectively), and the use 1 for either DSD, CD/LSD or DTR to at least negotiate signal rate(yes, it is IMPORTANT!!). But, really, pins 2&3 should be rolled at one end to ensure RX to TX otherwise you get DTE/DCE mismatches and essential make a null-serial cable.

Then again, I'm a datacomm guy.

As long as it is unidirectional, I should be OK, but the Aviom also converts the signal to a 16-bit 44.1K signal, which might also get knocked out of whack due to bitstream errors and jitter that can happen, not to mention other bits of digital ugliness.

I'm going to play it save and run it as a sepparate cable, but now I'm going to buy that book too, it can't hurt.

Didn't realize you were in datacom, LOL. Anyways, here are a few bits of info I was able to gether out of the book. It also has a timing diagram and so forth if you're still interested.

-Transmits 8-bit level data asychronously
-Data rate of 250kbps
-No parity
-2 stop bits

Let me know the outcome if you do end up 'experimenting'...
-Griffin

Oh, I'm definately getting that book. I'm a sound guy by nature. No, not a DJ, but a live sound and studio engineer. Lights are always secondary to me, but alas, I am being forced to learn this stuff, so that book sounds like it will be a wealth of information.

2 parity bits, so that is compensating for the high serial transfer rate by adding a forced pause, it's nearly like MIDI being really a 7-bit protocol in an 8-bit 33.1K data stream, with bit 8 being a null. It sounds to me like this is an 8-bit stream with a deliberate 2-bit pause, but that doesn't add up, since the maximum you can get in 8-bit is 256, so it would in fact need to be re-encoded from a 10-12 bit packet into an 8-bit encapsulation, so that must be one UGLY layer 2 going on there. The 2 stop bits are most likely spacing(No B8ZS, anyone? Binary 8 Zero supression, the answer to 64-bit DS0's)(ESF/B8ZS), freeing us from the restrictive 7-bit AMI-D4 encoding, and getting T1's much faster and preventing loopbacks). Of course, there's still a lot of 56K circuits out there so AMI-D4 isn't leaving any time soon!

Geeze, I'm dating myself and I'm only 32.

MIDI is a 3-word protocol, but if this is merely unidirectional, then a lot can occur with a 10-bit stream, but will require multiple words to get tasks accomplished. 512 channels of continuous controller information is much more difficult to transmit than 16 channels of which only some might be continuous controller information.

Man, I'm probably going to be crunching numbers in my sleep now. Thanks!

Hmmm, I think I am mostly following your reasoning on the packet makeup... but for clarity's sake here's a quote from the book:

"In it's idle state, the DMX line is held at a 'mark' level with the data line in a high condition. When a packet is to start, a 'break' signal is sent, dropping the line to a low level for at least 88us. Following the break is a short pulse known as the Mark After Break signal; this is the general sync pulse for the start of the data portion of the DMX packet, which warns the receiver that the next transistion from high to low will be the start of the data. Next a start code is sent...After the start code the actual data bytes are sent using 8-bit words, each with 2 stop bits. Any number of data bytes from 1-512 can be sent. While 8 bits means a range of 0-255, the standard does not specify how to map the 256 possible values onto a typical lighting scale of 0-100%."

Interesting reading... You might have grasped all of this already, and I may have just missed it. At any rate, it is a fantastic book... covers just about all aspects of show control from lighting to animatronics to entertainment ethernet.

-Griffin

if you have any further dmx questions i'd be happy to help out, I'm a student and John Huntington is one of my Professors. If I dont know an answer off the top of my head I can surely find it out for you. -Mike

Now THAT is a professor I would like to have. Be sure to tell him he's got fans!

-Griffin

Well, just thinking of the high data rate of the signal, coupled with the standard sampling rate of the digital snake, because the digital audio sampling rate is syncronous(clocked) and the data signal rate is async, it won't work. Plus, we're not talking a clear layer 2/layer 2 conversion, if we think the 7-layer OSI model.

Simply put, if it works, it won't be reliable. Bits can be runted or dropped or mis-sampled because of clocking issues.

Besides, a 110-foot XLR cable only cost me $100 to build, and a Cat5 of the same lenth is like, what, $7 or so when I build them myself. Strap onto that a second Cat5 and a Coax and I'm all set.

I really have to remember to use my DMX termators though.

Now I need to find myself a better controller. The DMX Operator is nice, but I need more direct control over fixtures, so maybe something with 64 60mm faders would be nice. I'm requesting a catalog so I can check it out. This site doesn't help me much, I need pictures quick, then dive deeper.