The Reflector: The reflector fulfills two purposes:
1. To increase the efficiency of the instrument by deflecting light that would otherwise be unused.
2. To create specific patterns and qualities by the redirection of light.
The law of specular reflection explains what happens to light when it strikes a smooth, shiny surface, such as a mirror. Light will be reflected at an angle equal to the angle which it struck, but in the opposite direction. Early stage equipment used moulded glass as reflectors, but they have been replaced by lightweight spun-metal reflectors that are coated with a highly reflective and durable surface. Stage lighting instruments use one or possibly a combination of three reflector types: spherical, parabolic, and ellipsoidal.
|
|
|
|
|
Parabolic Reflector: |
Spherical Reflector: |
Ellipsoidal Reflectors: |
The Housing:The housing controls the excess light that has
not been reflected in the desired direction. It is generally painted black both
internally and externally to contain stray light and to keep the instrument
from attracting attention to itself. The housing also includes the color holder
slot, or gel holder slot.
Dichorism:
Dichoric filtration refers
to the ability of material to pass certain wavelengths of light through its
surface while rejecting others. This principle has been applied to color
filters, and is also now also used in reflectors. By reflecting the light
wavelengths which are visible, while allowing the heat wavelengths to pass, the
light being reflected is cooler and less likely to burn
through gels, or heat the front end of a light to the point that it will
burn you when you are focusing the instrument.










A par-can is a very effective flood instrument centered around
the PAR (Parabolic Aluminized Reflector) lamp. A PAR lamp looks very similar to
the headlight of an automobile. PAR lamps combine a parabolic reflector and a
lens into one unit. The lighting instrument is just the housing and the pig
tail (plug and cord). PAR lamps come with a variety of different lens
configurations and part of the focusing of these types of instruments is
choosing the types of lamps. PAR lamps control the spread of the light by the
grooves carved into their surface causing the light refract and spread.
Depending on the size, width, and how the lamps are orientated
,the light can be marginally controlled.


A cyclorama instrument or cyc light is an instrument
designed to provide a colored wash on a cyclorama. A cyclorama is a large cloth
drop used to surround the stage. The cyc lights
(pronounced "psych" light) a designed to be hung approximately 8 feet
from the cyclorama. One cyc light, hung 8 feet from
the cyclorama, will light an area approximately 16 feet high and 12 feet wide.
Cyc lights use a hybrid-reflector which is shaped like a curly-Q. cyc lights are a single purpose
instrument, and are rarely used for anything other than lighting cycloramas.

Strip lights are long troughs with a series of lamps in them. The lamps are
circuited together so that they can be lit in a colored sequence. These
instruments can be placed at the front edge of the stage and called footlights,
or they can be placed at the back edge of the stage and called the electric
ground row (EGR). Strips can also be used to illuminate a cyclorama
or hung with chain or a C-clamp to provide down light.
There are different types of strip lights. The most common form use PAR lamps and are wired with either 3 or 4 circuits. A newer type of strip lights are called mini-strips and use specialty lamps called MR16s. These are low voltage lamps which put out as much light as PARs and take up half the space






|
|
A diac is a form of solid-state switch used to switch AC voltage; it belongs to the class of switches known as thyristers. It is like a junction transistor without a base lead (it is a two-lead device) and accomplishes its switching action by breakdown at a certain voltage. There are also four layer devices with a similar mode of operation known as four-layer diodes. |
|
|
The triode AC switch (TRIAC) is a power-switching device as is the SCR. The TRIAC conducts currents in both directions while the SCR allows current in only one direction. A common application is for lighting controllers. In response to a trigger, the triac conducts until the AC voltage applied reaches zero, then blocks flow until the next trigger occurs. Since a trigger can cause it to trigger current in either direction, it is an efficient power controller from essentially zero to full power. |



AMX192, (a USITT standard) was
devised to multiplex up to 192 analog dimmer levels down a four wire cable. The
four wires are ground, analog level, and a differential clock. The USITT
standard is now quite old, having been last revised in February 1987, and is
probably now mostly of historic interest, although there are many thousands of
installations out there which use this protocol every day, there won't be many
more newly installed systems. DMX512 is now the
protocol of choice for multiplexed lighting control. The AMX192 standard
document is bundled in from USITT with the DMX512 standard document
The standard says...:
2.0 Applicability
This Standard is intended as a guide for:
It is important to note that the origins of this standard come from a
control protocol originally developed by Strand Lighting
(Strand Century Inc.). This protocol is used by a large installed base of
equipment manufactured by
There are substantial differences between the receive timing and the
transmit timing. New controllers adhering to this standard must produce a
signal acceptable to a wide variety of dimmers, and new dimmers must be able to
listen to a number of different controller signals. As an example, note that
new controllers should provide a wide "analog valid" window, but new
dimmers must be able to cope with the differences in existing consoles, and use
a narrow "sample window". These differences in timing between the
Receive Standard and the Transmit Standard produce enough tolerance to cover
worst case variations on the original
Although widespread adoption of this Standard is sought by USITT,
compliance with the standard is strictly voluntary. Furthermore, it is not
intended as a replacement for existing protocols already manufactured, but
rather as an addition to existing protocols which will broaden the installed
base of controllers and dimmers that can communicate with each other.
One real gotcha with all the multiplexed analog schemes is that the cable
radiates a fair amount of interference, and so wireless intercomms
can get blocked if you are close by.
|
Pin |
Purpose |
|
1 |
Signal common |
|
2 |
Differential clock +ve |
|
3 |
Analog level |
|
4 |
Differential clock -ve |
DMX-512
The U.S.Institute of Theatre Technology (hence refered to as USITT) first
developed the DMX512 protocol in 1986 as a standard interface between dimmers
and consoles. It was a simple concept and was easily adoptable by all
concerned. Since the first standard, some improvements was
made in 1990 to accomodate some problems and it is
now known as the USITT DMX512 (1990) standard. Another round of discussions are
on for further modifications and then it would become USITT DMX512-A. It
started out as a means to control dimmers from consoles and has ended up being
used to control intelligent lights, color changers, yokes, strobes, smoke
machines, lasersand even confetti dispensers.
BASIC
OPERATION
Although
details of how USITT DMX512(1990) (hence forth refered to as DMX, unless specified othewise)
is described in detail on other dedicated pages (see main page), a preamble is
given below.
The
DMX protocol consists of a stream of data which is sent over a balanced cable
system connected between the data transmitter (usually consoles) and a data reciever (could be dimmers or any of the stuff mentioned in
the above paragraph).
A
single DMX port, outputting this stream, can pass magnitude value information
for a maximum 512 channels (or lesser) only. This port is known as a DMX
universe. For consoles catering to more than 512 channels a second universe ( and therefore a second port) is required. The following is
the universe/channel table:
UNIVERSES
CHANNELS
1 1-512
2 513-1024
3 1025-1536
4 1537-2048
5
2049-2560
6
2561-3072
The data
stream is sent as a packet ( hence forth refered to as the DMX packet) of data which is repeated
continuously. It consists of starting bits of data which informs the recievers that the packet is being refreshed and then sends
out a stream of serial data corresponding to the magnitude value of each
channel , starting with channel 1 and ending with 512 or a lesser channel No(
depending on the design and size of the console). Each channel is separated
from the other by specified bits of start and stop data.
&h01...
&h02...
&h03...
&h04...
&h05...
&h06...
&h07...
&h08...
&h09...
&h0A...The
whole system works like a city postal system. Each postman (
universe ) has a beat of 512 houses(channels). Each house(channel)
has a unique address.Some houses are high risers with
many individual apartments(several channels in one unit like an intelligent
light). The postman goes from house to house and delivers the mail(the value data ) in individual letter boxes. Each
occupant opens only HIS letterbox and takes HIS mail. Similarly each recieving unit is told it's address (one of 512 adresses) and thus ignores all other data except the one
it's supposed to recieve against it's address.Some units like intelligent lights have one address
as a start and go on to recieve data for that address
AND several more addresses FOLLOWING it . Not unlike
the lobby security receptionist who takes in the mail for every one in that
building and then distributes it.
The data
stream has a specific format (THE DMX512 PACKET) and has specific physical properties(DMX512 PHYSICALS) by which it is propagated .
The
actual electrical method by which the digital 1s' & 0s' are spit out by
your console and then recieved by all the gear on
stage is also important to understand, in view of the fact that 80% of your
problems are caused by distortion, in some way, of the physical DMX512 signal.
The
DMX512 signal is transmitted via the industry standard interface known as the
EIA485, more familiar as the RS485. This is not dissimilar to the RS232 port
behind your standard desktop, but is not the same stuff exactly.
Specialised instrumentation desktops have these RS485 ports for process control
jobs, but the format for communication is quite different. It's like using the
same English alphabets to write two different languages.
The
RS485 standard uses two/three wires to transmit the digital HIs
& LOs:
1) The +signal wire (+s)
2) The -signal wire (-s)
3) The 0 wire or ground wire (0v)
A
digital 1 is sent out when the +s wire is at a higher potential then the -s
wire.
A
digital 0 is sent out when the +s wire is at a lower potential then the -s
wire.
The
difference between these two data wires is what's IMPORTANT ;
NOT the difference between EACH of them and the ground wire which is simply a
reference point. The ground wire may not be present at all in some EIA485
installations.
The
high or low potential levels are defined clearly by the RS485 interface
standard.
Any of the two wires can go upto +12volts (measured
to ground) or down to -7volts (measured to ground).
e.g. To
transmit a digital 1 ,the +s wire is held at +5volts and the -s wire is held at
-5 volts.
To
transmit a digital 0 ,the +s wire is now taken to
-5volts and the -s wire to +5 volts.
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 recieving
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 immidiatly
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 recievers 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 recievers 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 recievers have a dip switch to set this parameter for both
timings. Again the maximum MAB lenth 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 reciever
that the data following it is meant for a specific type of reciever.
That is the end purpose of having the SC..... to be able to segregate a packet
of data, recieverwise. But, for the moment, it's zero
which has been specified for dimmers by ESTA. Do remember that this also
includes just about any recieving 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.
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 recievers...be they
intelligent lights or whatever...will decode them. Actually a channel counter
is set up in the reciever...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 reciever 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.
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 recieving 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 immidiatly
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 recievers 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 recievers 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 recievers have a dip switch to set this parameter for both
timings. Again the maximum MAB lenth 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 reciever
that the data following it is meant for a specific type of reciever.
That is the end purpose of having the SC..... to be able to segregate a packet
of data, recieverwise. But, for the moment, it's zero
which has been specified for dimmers by ESTA. Do remember that this also
includes just about any recieving 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.
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 recievers...be they
intelligent lights or whatever...will decode them. Actually a channel counter
is set up in the reciever...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 reciever 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.
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 recieving
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 immidiatly
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 recievers 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 recievers 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 recievers have a dip switch to set this parameter for both
timings. Again the maximum MAB lenth 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 reciever
that the data following it is meant for a specific type of reciever.
That is the end purpose of having the SC..... to be able to segregate a packet
of data, recieverwise. But, for the moment, it's zero
which has been specified for dimmers by ESTA. Do remember that this also
includes just about any recieving 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.
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 recievers...be they
intelligent lights or whatever...will decode them. Actually a channel counter
is set up in the reciever...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 reciever 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.
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 recieving
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 immidiatly
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 recievers 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 recievers 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 recievers have a dip switch to set this parameter for both
timings. Again the maximum MAB lenth 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 reciever
that the data following it is meant for a specific type of reciever.
That is the end purpose of having the SC..... to be able to segregate a packet
of data, recieverwise. But, for the moment, it's zero
which has been specified for dimmers by ESTA. Do remember that this also
includes just about any recieving 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.
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 recievers...be they
intelligent lights or whatever...will decode them. Actually a channel counter
is set up in the reciever...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 reciever 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.

DMX512 Standard Pinouts
The Standard connector for DMX512 is the 5 pin XLR
connector [Note 1]. A female is fitted to a transmitter (eg
a console), and a male to a receiver (eg a dimmer).
|
Pin |
Usual colour |
Usage |
Notes |
|
1 |
Screen |
Interference screen,
and ground reference |
[Note 2] |
|
2 |
Black |
DMX512 Data -ve |
|
|
3 |
White |
DMX512 Date +ve |
|
|
4 |
Green |
Spare data -ve |
[Note 3] |
|
5 |
Red |
Spare data +ve |
[Note 3] |
The 4 pin XLR is used mostly by scrollers and colour changers to deliver both control and power to a lighting
accessory.
The following pinout is believed to be correct
for:
Not the Wybron ColorRam!
|
Pin |
Usual colour |
Usage |
Notes |
|
1 |
Screen |
Interference screen, and ground reference |
[Note 1] |
|
2 |
Black |
DMX512 Data -ve |
|
|
3 |
White |
DMX512 Date +ve |
|
|
4 |
Green&Red |
+24V DC |
[Note 2] |
The 3 pin XLR is used mostly by moving lights. Of course, as the XLR3 was
never standardised as a "proper" DMX512
connector, there is no "proper" pinout, so
of course, both variations are used.......
|
Pin |
High End Systems |
Martin
Professional |
Notes |