LIGHTING EQUIPMENT
RESOURCES

DMX 512 EXPLAINED:

The DMX 512 Packet

 

Before we go on to explain the structure of the DMX packet, I am assuming that the visitor has some knowledge of the bits & bytes that make up any computer's fundamental language system.

 

The DMX bits are also represented by a digital high (HI) or a digital low (LO). The actual DMX output transmits these HI and LO signals in an electrical form that is explained in the page DMX 512 (1990) Physicals.

 

The DMX data stream clocks out at the rate of 250Khz which means each bit is measured at 4 micro seconds widths.

 

1) IDLE or NO DMX situation:
In the absence of a valid DMX packet the output of a DMX line will be a continously HI signal.

 

2) BREAK
The start of a DMX packet is heralded by the output going LO for a MINIMUM period of 88 micro seconds. This means 22 LO bits are measured out one after the other. This is known as the BREAK. The BREAK could be longer but not less than 88 micro seconds. Experience shows that slightly longer breaks (above 88 micro seconds) sent from a console are better since the receiving devices are generally given the algorithm = "Is the BREAK>88 micro seconds or 22 pulses". I keep it generally at 100 -120 micro seconds in equipment designed by me

 

3) MARK AFTER BREAK (MAB)
The MAB immediately follows the BREAK by making the output go HI for a MINIMUM period of 8 micro seconds or 2 pulses. This MAB is a bit of a problem since the difference between the original DMX512 and the current DMX512(1990) standards relate to this period of the packet. The original was set at 4 micro seconds or 1 pulse. This created hassles for some receivers for being too short a MAB for detection and was upgraded to 8 micro seconds or 2 pulses in 1990. The problem comes when a older console is used with newer receivers or vice versa. Wrong detection will lead to packet rejection or the wrong data going to the wrong channel. This will travel down the line leading to utter confusion. Some receivers have a dip switch to set this parameter for both timings. Again the maximum MAB lenth could be 1 second. My ideal timing would be 12 micro seconds.

 

4) START CODE (SC)
The SC is next in the line. It is easier to remember that the SC is the start of the actual data stream where all individual channel data have the same format. The BREAK & the MAB were of different timings but the SC onwards all frames will have the same structure and timing of 11 pulses or 44 micro seconds width. The first one can be termed as data for channel number 0 which is a non-existent channel and represents the SC.

 

I will first describe the general structure of these channel data frames:

 

-Of the 11 pulses the 1st one is always LO signifying the Start bit.

 

-This is followed by the actual data byte of 8 bits (which could be any of 256 values from 0 to 255).

 

-The frame ends with 2 bits which are HI signifying the two stop bits and end of the channel information.

 

Channel number '0' is the SC, which as things stand, ALWAYS has the databyte = 0 signifying that the following data is for dimmers. As per the current standard, no other value can be used. The option is left open and as and when ESTA specifies, the SC value may be used to tell the receiver that the data following it is meant for a specific type of receiver. That is the end purpose of having the SC..... to be able to segregate a packet of data, receiver-wise. But, for the moment, it's zero which has been specified for dimmers by ESTA. Do remember that this also includes just about any receiving device like dimmers, moving lights or whatever!

 

5) MARK TIME BETWEEN FRAMES (MTBF)
The mark time between frames can be from a little more than 0 seconds to up to 1 second, but the lesser the better. Each channel frame can have the MTBF before the start bit. The MTBF is obviously HI .

 

6) CHANNEL DATA (CD)
The CD frames follows the SC frame in a logical manner from 1 to 512 (or less) in the form described above.

 

7) MARK TIME BETWEEN PACKETS (MTBP)
After the last valid CD stop bits are sent, one full packet is completed and the next packet can start with a fresh BREAK & MAB. However an idle (HI) can be inserted between packets (MTBP), the length of which may be a little more than 0 second to up to 1 second. It is up to the console designer to design the architecture of the console and the software powering it in such a manner that the data thruput time is at a minimum.

 

IMPORTANT

The happy part of DMX is that you DONT send the CHANNEL NUMBER AT ALL!!

 

The 1st byte AFTER the STARTCODE (SC) is AUTOMATICALLY taken as the data value for Channel 1...next, data value for Channel 2....next, data value for Channel 3...and so on...up to 512 OR less channels. That is how the receivers...be they intelligent lights or whatever...will decode them. Actually a channel counter is set up in the receiver...either in the software itself, or as a hardware counter.  This counter will be automatically reset to point at channel 0 when a valid BREAK and a valid MAB is detected. Subsequently with every LAST stop bit in each frame, this counter is incremented by ONE. Thus, DURING the SC frame, the counter output reads zero. At the end of the SC (last stop bit of the SC frame) the counter output becomes one, thus telling the processor that the next frame contains the data for channel 1 and so on. So the receiver knows which channel the current data is valid for ....

 

Thus when you set a start address in an MARTIN 812 at say 50 (+6 channels) it simply takes the 6 data bytes from when the internal channel counter reaches 50....counting up to 55 !!  The moment you start a fresh BREAK ...etc sequence (a new packet, that is) this counter is reset!! So it is fully legal for a console or software to generate up to valid 100 data bytes after the SC for 100 channels and then generate a BREAK, etc. Thus you don't HAVE TO generate all 512 bytes!! The LSC ATOM, for instance, has the capacity to drive 99 channels; thus at the end of the 100th frame or a count of 99 (remember, we have an SC frame to count too, at the count of zero) the console starts sending a BREAK + MAB and so on. This concept is vital in order to understand the one to one relation between channel numbers and their respective data.

 

Like this: