Ujjal's DMX512 Pages....The DMX512 Packet

THE DMX512 PACKET



INTRO PACKET PHYSICAL EQUIPMENT PROBLEMS
DOWNLOADS LINKS AUTHOR BULLETIN HOME

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 -

DMX512 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 microsecs. 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 microsecs. Experience shows that slightly longer breaks (above 88 microsecs) sent from a console are better since the receiving devices are generally given the algorithm = "Is the BREAK>88 microsecs or 22 pulses". I keep it generally at 100 -120 microsecs in equipment designed by me

3) MARK AFTER BREAK (MAB)
The MAB immediatly follows the BREAK by making the output go HI for a MINIMUM period of 8 microsecs 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 microsecs or 1 pulse. This created hassles for some receivers for being too short a MAB for detection and was upgraded to 8 microsecs 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 length could be 1 sec.
My ideal timing would be 12 microsecs.

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 microsecs width. The first one can be termed as data for channel No 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 No '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, receiverwise. 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 sec to upto 1 sec, 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 stopbits 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 lenth of which may be a little more than 0 sec to upto 1 sec. It is upto 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 datavalue for Channel 1...next, datavalue for  Channel 2....next, datavalue for Channel 3...and so on...upto 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 databytes from when the internal channel counter reaches 50....counting upto 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 upto valid 100 databytes 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 nos and their respective data.
Like this :
(This animation may take some time to load, but is worth waiting for)

Packet Demo..... PLEASE BE PATIENT !!!

What you see above, happens at a speed which is so fast that the scrollers actually retain the color. receivers also store the last channel data they receive in the last packet refreshing it with the packets as they come.
The scrollers going to white at the start of the MAB in the above animation, is ONLY for demonstrating the packet action with every new packet and does not actually happen in practice due to the storage refresh.

The following is a mathematical layout of the typical DMX512(1990) timing :-

[(88)+(12)+(44)+(CHL*44)+(CHL*MTBF)+(MTBP)] microsecs

Where CHL is the no of Channels under consideration.

The ideal timing ( this is purely my personal opinion) :-

[(120)+(12)+(44)+(CHL*44)+(0)+(50)] microsecs

For 512 channels my timing would be 22754 microsecs.

Thus the refresh rate = 1000000 / 22754 = 43.9 or 44 Hz

How the refresh rate varies would depend upon the Microprocessor speed,firmware code and system architecture.

DMX Timing Chart/1990


Use Links below or the console to navigate the site
(the faders don't work yet !!! )

MENU CONSOLE..like all consoles, this one takes time to come on..... so BE PATIENT !!!

(Go to Top)