Ujjal's DMX512 Website

Go to content

Main menu:

DMX512 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.


1) IDLE or NO DMX situation:

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

My ideal timing would be 12 microsecs.






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 !





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)

dmx512 pACKET

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.

Copyright: Ujjal Kar | ujjal@standardrobotics.com

Back to content | Back to main menu