Ethernet Communication in Lighting Control
Shaun Jackman
April 27, 2005
A thesis submitted in partial fulfillment
of the requirements for the degree of
Bachelor of Applied Science
in the school of
Engineering Science,
Simon Fraser University
Copyright 2005 Shaun Jackman. All rights reserved.
APPROVAL
Name: Shaun Jackman
Degree: Bachelor of Applied Science
Title of thesis: Ethernet Communication in Lighting Control
Dr. Mehrdad SaifDirector, School of Engineering Science, SFU
Examining Committee:
Dr. M. ParameswaranProfessor, Engineering Science, SFUAcademic Advisor
D. HigginsPresident, Pathway Connectivity Inc.Technical Advisor
B. BartLecturer, Computing Science, SFUCommittee Member
Date Approved:
Abstract
Pathway Connectivity Inc. designs products to control entertainment and architec-
tural lighting devices. Their products are typically installed in theatres, theme parks,
and cruise ships. Lighting control devices currently use an industry standard pro-
tocol, DMX512, or digital multiplex 512, which allows 512 lighting fixtures to be
controlled using a single cable. With the advent of more complex lighting fixtures,
such as moving lights, this aging protocol is becoming less suitable. During my employ
at Pathway Connectivity, the company designed the Pathport to serve as a bridge
between the installed base of DMX products and today’s ubiquitous Ethernet net-
works. This thesis considers the design of the Pathport and measures a number of
performance parameters such as network latency, dropped packet rate, and processor
utilisation.
i
Acknowledgements
I would like to thank my technical advisor, Dave Higgins, for providing a workplace
that fosters exploration and innovation.
I would like to thank my supervisors, Dr. Ash Parameswaran and Brad Bart, for
their direction throughout the writing of this thesis, as well as my past supervisors,
Dr. Patrick Leung, and Dr. Jacques Vaisey for their help in writing the proposal. Dr.
Vaisey was an enthusiastic and thoughtful professor. I regret that future engineering
students will not have the experience of knowing him.
Finally, I would like to thank my family and friends for their company, my parents,
Mike and Agnes Jackman, for providing encouragement in any endeavour I undertook,
and my girlfriend, Breanne De Jaegher, for her scrupulous editing, excellent cooking,
companionship, and support.
ii
Contents
List of Tables v
List of Figures v
List of Acronyms vi
Glossary x
1 Purpose 1
2 Background 1
3 Objectives 2
3.1 Functional Specification . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Design and Implementation . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Design 5
4.1 Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3 Lighting Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5 Simulation 13
5.1 Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
iii
5.2 Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6 Experiment #1: Delay 17
6.1 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2 Observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7 Experiment #2: Dropped Packet Rate 22
7.1 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2 Observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8 Experiment #3: Processor Use while Merging 25
8.1 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.2 Observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9 Conclusions 27
References 28
iv
List of Tables
1 Communication requirements . . . . . . . . . . . . . . . . . . . . . . 7
2 Simulated low-level drivers . . . . . . . . . . . . . . . . . . . . . . . . 15
List of Figures
1 An example of a lighting control network . . . . . . . . . . . . . . . . 6
2 Hardware components . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 dmx4linux – lighting console and DMX display . . . . . . . . . . . . . 13
4 Firmware organisation . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5 Measuring zero delay using a loopback cable . . . . . . . . . . . . . . 18
6 Measuring a calibrated non-zero delay using a delay line . . . . . . . 19
7 Measuring the delay of the Pathport system . . . . . . . . . . . . . . 19
8 Delay vs. time of a “one input, one output” network . . . . . . . . . 20
9 Histogram of a single period . . . . . . . . . . . . . . . . . . . . . . . 21
10 Processor utilisation and dropped packet rate vs. packets per second 24
11 House-keeping cycles vs. number of merged channels . . . . . . . . . 26
12 Processor utilisation vs. number of merged channels . . . . . . . . . . 26
v
List of Acronyms
ACN . . . . . . . . . . Architecture for Control Networks – An ESTA standard for
the configuration and control of TCP/IP based lighting control net-
works.
ANSI . . . . . . . . . American National Standards Institute – An American or-
ganization responsible for a variety of voluntary standards, including
computer and communication standards.
bps . . . . . . . . . . . bits per second – A measure of data rate.
BSD . . . . . . . . . . Berkeley System Distribution – A distribution of Unix origi-
nally written by Bill Joy and others at the University of California,
Berkeley.
CAT5 . . . . . . . . . Category 5 Cable – The standard cable used in wiring Ethernet
installations. It has four pairs of conductors, only two of which are
used in 10BaseT and 100BaseT.
DC . . . . . . . . . . . . Direct Current – Voltage constant over time.
DHCP . . . . . . . . dynamic host configuration protocol – A protocol for the
automatic configuration of TCP/IP networks. See also RFC1533.
DMX512 . . . . . Digital Multiplex – A unidirectional 250 kbps, 8 bit frame, 512
byte packet, streaming serial protocol used in the lighting industry to
control lighting dimmers and fixtures. Uses EIA-485 for the physical
medium. Originally designed by USITT, this standard is currently
maintained by ESTA. Also referred to simply as DMX.
EIA . . . . . . . . . . . Electronic Industries Alliance – A partnership of US high-tech
associations and companies that maintains standards for electronics.
See also TIA.
EIA-485 . . . . . . Electronic Industries Alliance standard number 485 – A
physical communication standard used in multi-drop serial protocols
vi
consisting of two differential signals that swing between 0V and 5V.
Previously known as RS485. Maintained by the EIA.
EL . . . . . . . . . . . . electroluminescent – An organic phosporescent used to back-
light LCD displays.
ESTA . . . . . . . . . Entertainment Services and Technology Association – ESTA
is a non-profit trade association representing the North American
entertainment technology industry.
GDB . . . . . . . . . GNU debugger – A debugger written by the GNU project.
GNU . . . . . . . . . GNU’s not Unix – The Free Software Foundation’s project to
provide a freely distributable replacement for Unix.
GTK+ . . . . . . . GUI toolkit – A library for designing portable graphical user
interfaces.
HTP . . . . . . . . . . highest takes precedence – A DMX merge scheme wherein the
controller giving the highest control values takes precedence.
IEEE . . . . . . . . . Institute of Electrical and Electronics Engineers – An in-
dustry organisation that maintains a number of electrical standards,
such as PoE and Wi-Fi.
IETF . . . . . . . . . Internet Engineering Task Force – An open international
community of network engineers that maintains a number of net-
working standards.
IGMP . . . . . . . . internet group management protocol – Used to control which
multicast groups Ethernet switches route to which subnets.
IP . . . . . . . . . . . . . Internet protocol – The standard protocol used for communi-
cation on the Internet. See also STD5 (RFC791).
IrDA . . . . . . . . . Infrared Data Association – A protocol suite used in wireless
infrared communication. It is often used between hand-held com-
puters. The Pathport uses a SIR transceiver module.
vii
JTAG . . . . . . . . . Joint Test Action Group – A standard for testing silicon cores,
often used for debuggging with micro-controllers.
kbps . . . . . . . . . . kilobits per second – A measure of data rate.
LCD . . . . . . . . . . liquid crystal display – A thin flat display capable of displaying
text and graphics to a user, as used in a graphing calculator or hand-
held computer, for example.
LTP . . . . . . . . . . last takes precedence – A DMX merge scheme in which the
most recent change in control value takes precedence.
Mbps . . . . . . . . . megabits per second – A measure of data rate.
PC . . . . . . . . . . . . personal computer – In the context of this project, a PC is
used to configure the Pathport, communicating using Ethernet.
PoE . . . . . . . . . . . Power over Ethernet – 48 V DC delivered over either the trans-
former midspan or one of CAT5 cabling’s two spare pairs of wires.
This technology was originally developed by the VoIP industry, who
use it to power VoIP handsets. It is now a standard maintained by
the IEEE, namely IEEE802.3af.
RDM . . . . . . . . . remote device management – The extension of DMX to a
bidirectional communication protocol.
RFC . . . . . . . . . . request for comments – A body of standards governing the
functioning of the Internet published by the IETF.
RFU . . . . . . . . . . remote focus unit – A portable hand-held console used for test-
ing and focusing lighting fixtures.
ROM . . . . . . . . . read-only memory – This term is now also used to describe
flash memory, which is writable in large time scales.
SIR . . . . . . . . . . . serial infrared – Supports asynchronous communication at 9600
bps through 115.2 kbps at distances of up to one metre.
STD . . . . . . . . . . Internet standard – A set of RFC documents that have been
adopted by the IETF as official Internet standards.
viii
TAP . . . . . . . . . . virtual Ethernet interface – A simulated Ethernet interface
for Unix systems.
TCP . . . . . . . . . . transmission control protocol – An Internet protocol that pro-
vides a full-duplex streamed communication channel. See also STD7
(RFC793).
TCP/IP . . . . . . transmission control protocol / Internet protocol – The
suite of protocols that powers the Internet.
TDM . . . . . . . . . time division multiplexing – A mutiplexing scheme wherein
multiple communication channels share the same medium by allo-
cating a different time slot to each channel.
TFTP . . . . . . . . trivial file transfer protocol – A simple file transfer protocol
often used for downloading boot code and firmware. See also STD33
(RFC1350).
TIA . . . . . . . . . . . Telecommunication Industries Association – An association
of companies in the telecommunications industry. See also EIA.
UART . . . . . . . . Universal Asynchronous Receiver/Transmitter – A device
used for asynchronous serial communication.
UDP . . . . . . . . . . user datagram protocol – An Internet protocol that provides a
full-duplex packet oriented communication channel. See also STD6
(RFC768).
USITT . . . . . . . United States Institute for Theatre Technology – The orig-
inal authors of the DMX standard, which is now being maintained
by ESTA.
VoIP . . . . . . . . . . voice over Internet protocol – A standard for transmitting
voice communication over the Internet.
Wi-Fi . . . . . . . . . wireless fidelity – Wireless communnication standard also known
as wireless Ethernet or IEEE802.11.
ix
Glossary
100BaseT – The extension of 10BaseT to a 100 Mbps connection.
10BaseT – The physical communication standard used in 10 Mbps Ethernet.
channel – A single channel controls a single parameter of a fixture, such as its
brightness. A single channel is eight bits wide. Parameters that require more
precision, such as the position of a moving light, may use two or more channels.
console – A lighting console which controls fixtures using DMX, also called a control
desk.
Debian – A Unix implementation most commonly using the Linux kernel.
Ethernet – A network technology for local area networks. Two common flavours
are 10BaseT and 100BaseT.
fixture – An intelligent lighting fixture controlled by DMX. A number of other de-
vices are also controlled using DMX, such as lighting dimmers, fog machines,
and relays.
half-duplex – A bidirectional communication channel in which only one node can
transmit at a time.
hand-held – A hand-held computer, such as a Palm or Pocket PC.
Linux – A Unix kernel originally created by Linus Torvalds. It is now a world-wide
project with thousands of authors.
multicast – A point-to-multipoint TCP/IP protocol. Multicast groups are negoti-
ated using IGMP and data is transported using UDP. See also STD5 (RFC1112).
non-volatile – Used to describe a memory device that retains its contents without
power.
Pathport – A DMX / Ethernet network gateway device, and the focus of this paper.
x
Pathway Connectivity Inc. – A data communications company in the entertain-
ment lighting industry developing the Pathport.
segment – A portion of a lighting network that shares the same DMX universe. See
also universe.
universe – One segment of a DMX network is referred to as a universe. Each universe
carries 512 8-bit control channels, sourced by the lighting console, and multiple
lighting fixtures controlled by these channels. See also channel.
Unix – An operating system developed at Bell Labs, originally spelled UNIX. This
term, spelled Unix, now generally connotes a large class of systems implementing
the same interface, such as Linux and BSD.
xi
1 Purpose
For the past decade, communication between lighting equipment has been achieved
using DMX512 (Digital Multiplex), an industry standard serial protocol. However,
the industry is beginning to shift from the ageing DMX protocol towards Ethernet
as the new communication standard.
The purpose of this project is to design, implement and test the Pathport, a device
meant to act as the bridge between the installed base of DMX products and newer
Ethernet products. The device multiplexes multiple 250 kbps DMX signals onto one
10 Mbps Ethernet network. A second Pathport then extracts the component DMX
signals from the Ethernet network to control lighting fixtures.
2 Background
Pathway Connectivity Inc. [1] is a small company of roughly a dozen employees op-
erating in a unique market: the entertainment and architectural lighting industry.
Specifically, the company designs and markets products that transport and aid com-
munication between lighting consoles (the controlling devices), and intelligent lighting
fixtures (the controlled devices). Typical installations are in theatres, theme parks,
and cruise ships. Pathway does not design the consoles or the fixtures themselves.
Rather, the company concentrates on the devices in the middle of the lighting net-
work that facilitate communication, the equivalent of switches and routers in Ethernet
networks.
Lighting control communication primarily uses an industry specific serial protocol
named DMX [2], which has been in existence and left relatively unchanged for al-
most twenty years. A large portion of Pathway’s business comes from a commodity
product, the DMX Repeater. This device is to DMX what a hub is to Ethernet,
allowing a single signal to drive multiple outputs. Modern networking technologies
are revolutionising this market by replacing DMX and its unique wire with Ethernet
and CAT5 (Category 5 Cable). This substitution allows a more costly DMX repeater
to be replaced by a fifty dollar Ethernet hub.
1
Although the market for a product such as the DMX Repeater might be depressed
after the industry’s transition to Ethernet, the business opportunity that arises is
the same as in any major tech-industry paradigm shift. The existing DMX hardware
in the field will need to communicate with the new Ethernet hardware. Protocol
converters and repeaters have previously been Pathway’s niche led to the design of a
new product to fill the apparent gap in the market, the Pathport. Its purpose is to
act as a communication gateway between DMX segments and an Ethernet network,
allowing existing equipment to interoperate with modern gear.
3 Objectives
During my first work term at Pathway Connectivity, my technical advisor challenged
me to build a device that translated lighting data from DMX to an Ethernet network.
This device was to be the proof of concept for a product that would eventually become
the Pathport. I built this proof of concept using a standard PC (personal computer)
running Linux, a wire-wrap DMX card, and an off the shelf network card. The primary
goal of this thesis is to design and build the Pathport, whose primary purpose is not
drastically different from the original proof of concept. In fact, the first prototype
Pathport was referred to as the “shrink-ray” model, since it used hardware quite
similar to a PC but much reduced in size. The architecture of the final product
evolved much from the original “shrink-ray” prototype. Its design is discussed in this
paper.
The second goal of this thesis is to design a suite of tests that show the Pathport meets
certain performance goals outlined in the functional specification, which follows. The
experimental evidence is given in the final sections of this paper.
2
3.1 Functional Specification
The functional requirements of the Pathport define the capability, performance, and
capacity of the system and are broken up into three major components:
Communications — Pathport-to-device communication
User Interface — Pathport-to-user communication
Lighting Control — DMX and lighting control algorithms
To be a useful and successful product, the Pathport must have the following capabil-
ities:
1. Communication Requirements
(a) Transmit or receive on two DMX ports simultaneously.
(b) Receive DMX control data from a console.
(c) Control a fixture using DMX.
(d) Discover, configure, and receive status information from a fixture using
RDM (remote device management).
(e) Communicate with lighting control devices using ACN (Architecture for
Control Networks).
(f) Communicate using 10 Mbps (megabits per second) Ethernet.
(g) Communicate using TCP/IP (transmission control protocol / Internet pro-
tocol).
(h) Communicate using 9600 bps (bits per second) IrDA (Infrared Data Asso-
ciation).
3
2. User Interface Requirements
(a) Display status information using a graphical LCD (liquid crystal display).
(b) Be remotely configurable by a PC connected to the network using TCP/IP.
(c) Be configurable by a hand-held device using IrDA.
(d) Store the device configuration in non-volatile memory so that the device
can resume from power failure autonomously.
3. Lighting Control Requirements
(a) Process 1000 DMX packets per second.
(b) Achieve end-to-end packet latency of no more than 30 ms.
(c) Drop no more than 0.1% packets under a load of 1000 packets per second.
(d) Patch a DMX channel from any input to any output.
(e) Allow multiple consoles to control a single fixture, through either HTP
(highest takes precedence), LTP (last takes precedence), or priority patch-
ing.
(f) Merge up to 8 separate channels.
Ethernet is a best-effort transmission medium and performs best when it is operating
below 60% of its maximum capacity. The figure of 1000 packets per second approaches
this guideline. The lighting network as a whole must be capable of processing 1000
DMX packets per second, whereas an individual output node must be capable of
merging eight individual channels of DMX.
3.2 Design and Implementation
The majority of the design work for the Pathport was completed during a four month
work term, which was eventually extended to a full year. Although I was heavily
involved in the hardware design process before the hardware existed, the majority of
my work consisted of writing the firmware for the Pathport. This thesis discusses the
communication protocols mandated by the functional specification and looks at the
selection of hardware components to make this communication possible. My work
4
also included simulating a Pathport – and in fact many Pathports – to facilitate
testing. Finally, following the completion of the Pathport hardware and its firmware,
my work consisted of implementing test benches to measure the performance metrics
mandated by the functional specification.
3.3 Testing
Ensuring the device meets the functional requirements outlined in Section 3.1 is the
basis for validating the project. The experiments concentrate on testing the net-
work performance and reliability of the system. Physical tests, such as lifetime and
reliability due to physical failure, are outside the scope of this project.
In Experiment #1, the additional delay introduced by the Pathport in a nominal
lighting network is measured. This result is compared to the functional requirement
in Section 3.1. In Experiment #2, the rate of dropped packets is compared against
network activity to determine the maximum load of the system. In Experiment #3,
the Pathport’s processor utilisation is compared against the processor intensive task of
merging DMX, discussed in 4.3, to determine the maximum number of DMX channels
a Pathport is capable of merging.
4 Design
4.1 Communications
The Pathport must communicate with the devices listed in Table 1. An example
network of these devices is shown in Figure 1. Implementing the protocols needed
to communicate with each of these devices was a large part of this project. These
protocols use three separate physical media and each require a unique piece of com-
munication hardware.
TCP/IP is the protocol suite commonly used to communicate over Ethernet. TCP/IP
is needed for communication between the Pathport and the user’s computer, which is
used to configure the Pathport remotely. Since TCP/IP is a suite of communication
5
Key
WiFi Access Point
PathportComputer
Lamp PDA
Lighting Console
DMX
IrDA
WiFi
DMX
DMX DMX
Ethernet
Figure 1: An example of a lighting control network
6
Table 1: Communication requirements
Device Protocol Purpose
PathportTCP/IP (transmission control pro-tocol / Internet protocol)
Transmission of multiplexed DMXcontrol data between Pathports.
ACN (Architecture for Control Net-works)
Lighting network management.
PCTCP/IP (transmission control pro-tocol / Internet protocol)
Configuration of the Pathport bythe user’s PC.
Hand-heldIrDA (Infrared Data Association)
Configuration of the Pathport bythe user at close range.
LightingConsole DMX512 (Digital Multiplex)
Source of DMX control data.
LightingFixture DMX512 (Digital Multiplex)
Lighting control.
RDM (remote device management)Configuration of the fixture andstatus feedback from the fixture.
protocols, a variety of protocols are implemented, such as DHCP (dynamic host con-
figuration protocol) for network configuration and multicast for point-to-multipoint
communication. TCP/IP is also used to transmit lighting control data between Path-
ports.
The medium used to transmit TCP/IP is typically Ethernet. Thus, the Pathport re-
quires an Ethernet chip. Ethernet commonly comes in two flavours: 10 Mbps and 100
Mbps. Working with 100 Mbps requires a significantly more powerful processor and
thus higher frequencies on the circuit board. The Pathport is designed around the
assumption that 10 Mbps is sufficient for the transport of lighting data in a typical
installation. A quick back-of-the-envelope calculation shows that a theoretical maxi-
mum of 40 250-kbps DMX channels can be multiplexed onto one 10 Mbps Ethernet
channel.
nDMX/Ethernet =fEthernet
fDMX
=10 Mb/s
250 kb/s= 40 (1)
7
This capacity is more than sufficient for the largest existing lighting installations.
Robustness is also important to the lighting industry, and because of its slower speed,
10 Mbps Ethernet tends to operate with fewer errors in marginal conditions than 100
Mbps Ethernet.
ACN [3] is an emerging ANSI (American National Standards Institute) protocol for
the control of TCP/IP based lighting control networks currently under development
by ESTA (Entertainment Services and Technology Association). The purpose of this
protocol is to standardise the communication of modern lighting control networks,
much the way DMX did for serial-based lighting devices. ACN’s only requirement of
the hardware is that it be capable of communicating using TCP/IP, the underlying
protocol on which ACN is transported.
Although ACN has been in development for many years now, the standard has not
yet reached an implementable stage. In the mean time, Pathway developed a propri-
etary protocol for the configuration and control of lighting networks using Ethernet.
This protocol is referred to simply as the Pathport Protocol. Like ACN, Pathway’s
proprietary protocol uses TCP/IP to communicate using Ethernet. Therefore, the
Pathport requires an Ethernet chip and a TCP/IP stack. These requirements also
leave open the possibility of implementing ACN in the future.
IrDA [4] is the protocol suite used in wireless infrared communication. Since the
Pathport does not have a physical user-input device, a hand-held device may be used
to configure the Pathport at close proximity. The data passed in this process is not
high in volume. Minimum speed IrDA, 9600 bps, is sufficient and minimises complex-
ity and cost. The Pathport requires an IrDA capable UART (Universal Asynchronous
Receiver/Transmitter), and an infrared diode and lens to transmit and receive the
IrDA data.
DMX is the standard protocol used in entertainment lighting control. DMX is a rel-
atively straightforward 250 kbps (kilobits per second) serial protocol. At the physical
level, it uses EIA-485 (Electronic Industries Alliance standard number 485), a differ-
ential signal electrical standard, over any twisted pair cable, often Belden cable or
more recently CAT5. DMX is a multi-drop bus with one master, the lighting console,
controlling many slaves, the lighting fixtures. The console is the only device on the
bus that may transmit packets; the fixtures listen passively.
8
A full DMX packet consists of 512 individual lighting levels. Each level consists of
eight bits of data and three overhead bits for eleven bits in total, and is commonly
referred to as a frame of DMX. The overhead bits consist of two start bits, no parity
bits, and one stop bit. Their purpose is to synchronise the transmitting and receiving
UARTs since an explicit clock is not transmitted. This configuration is commonly
referred to as 8N2 asynchronous serial data. At 250 kbps, each bit takes 4 µs to
transmit and a frame takes 44 µs to transmit.
tframe =nbit/frame
fbit
=11 bit
250 kbit/s= 44 µs (2)
To reduce the overall cost per DMX port to the user, each Pathport unit has two DMX
ports, and so the micro-controller must have sufficient processing power to receive two
simultaneous streams of DMX. It must be capable of processing two frames of DMX
data every 44 µs. This requirement is more stringent than receiving one frame every
22 µs since one frame from each port could potentially arrive nearly simultaneously.
To physically receive the DMX signal, the Pathport requires two UARTs, one for each
DMX port.
A complete frame of DMX also includes an additional frame, referred to as the start
code, transmitted before the 512 lighting levels. This start code frame is set to zero
to indicate the following frames compose lighting control data. If the start code is
non-zero, the following data is vendor specific. Non-zero start codes are commonly
used to configure lighting fixtures, receive status reports, and is employed by RDM
to accomplish these same tasks.
RDM is the extension of DMX to a bidirectional protocol. RDM is an evolving
standard being developed by ESTA [5] for the intelligent control of lighting fixtures.
With bidirectional communication, lighting fixtures can identify themselves and their
capabilities, be remotely configured, and send back status information. Although
lighting communication networks were typically configured by hand previously, RDM
allows these networks to be self-configuring and intelligent.
RDM uses the same physical medium as DMX. However, it is a half-duplex protocol
that requires that the device be able to both send and receive data on the same
9
physical wire. Therefore, the Pathport must be able to dynamically swap between
transmitting to and receiving from that single wire.
4.2 User Interface
The Pathport is not intended to have a direct physical user interface. Since these
devices are expected to be used in quantity, physically manipulating each device to
configure them would be time consuming. Eliminating physical controls also has the
advantage of reducing part cost and wear-and-tear of the device itself. There are
three ways in which the user interacts with the device:
• Remote configuration using a PC
• Local configuration using a wireless hand-held device
• LCD for status display
Remote Configuration — The Pathport is typically configured from a computer
that communicates with the Pathport using its Ethernet connection. This configu-
ration is often changed relatively rarely; the Pathport may be reconfigured one or
more times per show, or even just once per installation. The Pathport stores this
configuration in its non-volatile flash memory and is autonomous from then on. The
configuring computer does not need to run during normal operation of the Pathport.
Local Configuration — Although the majority of the user’s interaction with this
device is intended to be remote, the user may find the need to configure the Pathport
when he or she is much closer to the device itself than to the controlling workstation,
for example when connecting lighting fixtures in the ceiling of a theatre. To meet this
need, the user can employ a hand-held computing device to configure the Pathport
using the infrared port, rather than climbing down the ladder and walking to the
control booth.
LCD — The user can get quick status information from the front panel of the
Pathport, such as which DMX ports are actively transmitting or receiving data. To
facilitate this, the Pathport requires a small graphical LCD.
10
4.3 Lighting Control
Besides the basic transport of DMX over Ethernet, the Pathport can provide certain
application-specific control of the lighting fixtures. For example, the ability to control
one fixture with multiple lighting consoles is a common need of lighting designers.
DMX has no allowance for multiple controllers, so this functionality must be provided
at a higher level, specifically by the Pathport.
Patching allows multiple lighting consoles to control multiple independent segments
of DMX. A simple system of DMX devices contains one lighting console and many
lighting fixtures, all connected by one DMX segment. If there are more lighting
fixtures than may be controlled by one segment of DMX, the fixtures may be parti-
tioned across multiple segments of DMX. In addition, a complex system may contain
multiple lighting consoles, which generate multiple DMX signals. In this case, the
Pathport must act as a switch, routing DMX data from multiple input segments of
DMX to multiple output segments. This is referred to as patching DMX channels.
Merging allows multiple consoles to control one fixture. It is not uncommon for a
building to have a primary lighting console and backup console in case the primary
fails, as well as a portable hand-held console, called a RFU (remote focus unit), used
for testing and focusing lighting fixtures. Many systems also incorporate simplified
push-button controls, resembling household light switches, for use by non-technical
staff. The merge algorithm decides which of these devices controls the lighting fixture.
There are three common methods of merging DMX channels:
HTP (highest takes precedence) — The controller transmitting the highest, or
brightest, value takes control of the fixture.
LTP (last takes precedence) — The controller that executes the most recent change
takes control of the fixture.
Priority — One particular console is given total priority. If that console ceases to
transmit, a backup console assumes control of the fixture.
11
4.4 Hardware
In the communication requirements of Section 4.1 we noted a number of necessary
components. These components were incorporated on a pair of four-layer circuit
boards housed in a cast aluminium enclosure. The architecture of the Pathport
hardware and topology of these components is shown in Figure 2.
CS8900A
ST16C650A
Ethernet
UART
UART
UART
1 MBSRAM
Pathport
IrDA
10BaseT
DMX
DMX
Atmel AT91M40800
LCDSED1520
16 bit bus
32 MHz
ARM7TDMICPU
Timer CounterInterrupt Controller
Peripherals
2 MBFlash
Figure 2: Hardware components
The device is powered using PoE (Power over Ethernet), which is 48 V DC (Direct
Current) delivered on the Ethernet cable, eliminating the need for a second cable
solely for power.
12
5 Simulation
I did not have the benefit of a full lab of lighting equipment available to me for my
research. This situation prompted me to consider using a computer to simulate the
lighting hardware that I was lacking. I decided to port the Pathport firmware to run
on a Unix platform, specifically the Debian distribution of Linux.
The lighting hardware, such as consoles and fixtures, were simulated using the dmx4linux
[6] software package. It provides a software lighting console that uses graphical sliders
rather than physical sliders, as well as an application that displays the DMX levels a
lighting fixture would receive, as can be seen in Figure 3.
Figure 3: dmx4linux – lighting console and DMX display
Running the Pathport firmware on a full computer system has many prospective
advantages. A debugger, such as GDB (GNU debugger), can be used to inspect the
Pathport firmware process as it runs. This is possible to some extent on an embedded
system by using a JTAG (Joint Test Action Group) debugger. Due to cost constraints,
I did not have this equipment available to me. However, the foremost advantage was
the ability to simulate a rack of Pathports using only a single computer. Those
simulated Pathports could then saturate the Ethernet connection with traffic so that
13
a physical Pathport could see a variety of network conditions without the need for a
small fortune in lighting gear.
The Pathport hardware is not simulated in its entirety. In particular, the Pathport’s
RISC processor is not emulated; the firmware is recompiled for the host system and
runs natively on it. However, the Pathport’s hardware peripherals are simulated
using desktop computer counterparts. For example, the Pathport’s LCD is simulated
using a window on the host’s desktop. The simulation of the peripherals is discussed
further in Section 5.2.
5.1 Firmware
The Pathport firmware is divided up into three categories:
• platform dependent drivers
• platform independent libraries
• applications
The platform dependent drivers, such as the Ethernet interface, were rewritten for
the Unix platform. The platform independent libraries, such as the IrDA library, ran
without any or only minor modification. Finally, the applications make use of all the
libraries to comprise the entire system. This hierarchy can be seen in Figure 4.
Note there are exactly two applications: the loader and the firmware. The firmware
is field-upgradable by downloading new code to the device using TFTP (trivial file
transfer protocol). If the new firmware were faulty, or something were to go wrong
when writing the new firmware to flash ROM (read-only memory), the device could
be rendered useless. To help prevent this scenario, a division between the loader and
the firmware is created.
The loader’s responsibilities are kept to a minimum. It obtains an IP (Internet pro-
tocol) address from the DHCP server and checks for a firmware upgrade from the
TFTP server. If such an upgrade is available, it downloads the firmware and writes
it to the flash ROM. The loader, however, is not overwritten. Thus, even if the new
firmware were faulty or if the flash were to fail, the loader would still function; the
device can still reboot and attempt to download replacement firmware.
14
Platformdependent
LCD
DMX
SIR
Ethernet
Flash
IrDA
TCP/IP
Lighting
DHCP
TFTP
Libraries
Firmware
Loader
Applications
Figure 4: Firmware organisation
5.2 Drivers
To simulate the Pathport, each of the low-level drivers shown in Table 2 was rewritten
for the Unix platform.
Table 2: Simulated low-level drivers
Driver Simulation
DMX Simulated using shared memory.Ethernet Simulated using TAP (virtual Eth-
ernet interface).Flash Simulated using a file.IrDA Simulated using a TCP (transmis-
sion control protocol) socket.LCD Simulated using GTK+ (GUI
toolkit).
15
DMX — In essence, DMX simulates a 512-byte buffer of shared memory. In
fact, this is how it is often implemented. The protocol is not analysed as a stream
of packets like other communication protocols. Instead, it is viewed as a single 512-
byte buffer that is continually being updated by the master. Thus, the most sensible
simulation is not a socket or stream, but a 512-byte shared memory buffer. This also
allows interoperability with other pieces of Unix software that view a DMX buffer in
the same way, such as dmx4linux.
Ethernet — The Unix platform uses the standard Berkeley sockets [7] TCP/IP
interface. Our adapted TCP/IP stack, on the other hand, uses an entirely different
interface. Thus, the network protocol libraries, such as DHCP and TFTP could
not compile for Unix directly, and modifying them for the BSD (Berkeley System
Distribution) interface would defeat the purpose of simulating the system, as it would
then be using the host’s TCP/IP interface instead of the firmware’s, which needs the
testing. Instead, Linux’s virtual Ethernet interface, TAP, was used to simulate an
Ethernet interface. The host routes packets to and from this interface as if it were a
physical interface connected directly to a single physical device. In fact, the Ethernet
interface is virtual, and the connected device is the simulated Pathport running as a
process on the host system.
Flash — Flash ROM is used for non-volatile storage on the device. It is used
to store the firmware the device is running as well as permanent configuration data
such as serial numbers, networking information, and lighting control patches. This
non-volatile storage is easily simulated as a file on the host’s file-system.
IrDA — The physical medium of IrDA is a simple UART, which uses an infrared
LCD rather than copper wire for signal transmission. Thus, the communication
channel is no more than a half-duplex stream communication channel. This half-
duplex channel is simulated using a TCP socket.
LCD — The LCD is used for quick visual feedback to the user. This is simulated
using a window on the host’s desktop drawn using GTK+, which is a portable graphics
toolkit. Additionally, if the LCD’s backlight is enabled the background of the window
is shown as a light blue reminiscent of an EL (electroluminescent) glow.
16
6 Experiment #1: Delay
6.1 Procedure
Lighting control systems originally used a single analog conductor for each channel.
Since the replacement digital system, DMX, used TDM (time division multiplexing),
the biggest concern for many was the delay it would introduce into the system. DMX
updates its universe of 512 channels 44 times a second. Thus, DMX introduces a
nominal delay of 22.7 ms into the system.
Tpacket = theader + nframe/packet · nbit/frame · tbit (3)
=96 µs
packet+
513 frame
packet· 11 bit
frame· 4 µs
bit=
22.7 ms
packet
fpacket =1
Tpacket
=1
22.7 ms= 44.1 Hz (4)
Experience has shown that this delay is unnoticeable to the human eye, at least
when the DMX signal is used for its originally intended purpose, which is to control
the intensity of incandescent lights. The thermal inertia of the filament naturally
smoothes changes in the light’s intensity. However, when DMX is used to control
the stepper motors of a moving light fixture, the delay may be noticeable as coarse
movement of the projected light. This is particularly true when the beam of light is
cast a long distance, and small changes in the angle of the beam produce large changes
in the placement of the spotlight. The Pathport system, which is an additional layer
on top of DMX, will naturally introduce further delay into the system. It is desirable
to keep this delay to a minimum. To this end, a test jig was built to measure the
delay.
The test jig is a device which transmits DMX out one port and receives the same
signal through a second port. It measures the delay between transmission and receipt.
The Pathport hardware conveniently has two DMX ports and a timer with which to
measure the delay. Firmware specific to the task of measuring DMX delay was written
to run on the Pathport hardware. The test jig Pathport transmits a packet of DMX
17
marked with a unique serial number and measures the time for that same packet to
return to its input DMX port. This value composes a single sample of the system’s
delay.
In the following diagrams, the box labelled Device under test is the system whose
delay is being measured. The single Pathport outside the DUT box is the test jig
measuring the delay of the DUT.
When a cable is connected directly from the output to the input of the test jig as
in Figure 5, the delay should read exactly zero – disregarding the transmission time
through the cable itself. The test jig is thus tared to measure zero delay.
Device under test
Test jig
Figure 5: Measuring zero delay using a loopback cable
Ideally, the test jig would also be calibrated for a non-zero value using a device that
exhibits a constant calibrated delay as in Figure 6. The construction of a calibrated
DMX delay line is, itself, a non-trivial task, so this additional precaution was omitted.
Ultimately, the test jig will be used to measure the delay of a complete Pathport
network as shown in Figure 7.
18
Device under test
Test jig
delay
Figure 6: Measuring a calibrated non-zero delay using a delay line
DMX DMX
Device under test
Test jig
Ethernet
Figure 7: Measuring the delay of the Pathport system
6.2 Observation
The delay of the loopback system in Figure 5, which would ideally be exactly zero,
measured 4 µs, which is the precision of the Pathport’s internal timer. This bias
is small in comparison to the measured value which will be on the order of tens of
milliseconds.
19
For the network system consisting of one DMX input and one DMX output shown
in Figure 7, the test jig was used to capture 250 consecutive samples of the system’s
delay. These samples show a mean delay of 47.8 ms. The sample data is shown in
Figure 8 and the histogram of a single period in Figure 9.
Figure 8: Delay vs. time of a “one input, one output” network
6.3 Analysis
The system consisting of one input and one output shown in Figure 7 gave a mean
delay of 47.8 ms without additional network activity. This value is above my original
goal of 30 ms that I specified in the functional requirement of Section 3.1. I chose
30 ms because it allowed for one entire DMX packet to be received and buffered,
which takes just under 23 ms, and retransmitted to Ethernet with some time allowed
for processing the data. I did not consider, however, that the Pathport receiving the
Packet from Ethernet is itself continuously transmitting DMX. Once it receives the
packet, it must finish transmitting its current DMX packet before it can transmit the
newly received packet. If the receiving Pathport has just begun to transmit a DMX
packet, there will be an additional 23 ms delay. Conversely, if the receiving Pathport
has just completed transmitting a DMX packet and is just about to transmit a new
packet, no additional delay will be incurred. Thus, the delay for each packet is going
to vary randomly from one to two packet times, plus the processing delay. So, the
minimum mean delay, disregarding processing time, is one and one half packet times,
or 35 ms.
20
Figure 9: Histogram of a single period
In fact, the actual delay is not entirely random. If the two transmitters are running at
only slightly different frequencies, a likely situation, the two transmitters will slowly
drift out of synchronisation and the delay will slowly increase. Eventually the phase
difference will come full circle and instead of an Ethernet packet arriving just too late
to be transmitted, the packet will arrive just in time causing the delay to suddenly
drop by exactly one packet time. We can see this exact effect in Figure 8.
It is important to differentiate between constant latency, a steady predictable delay
in the system, and jitter, a randomly varying delay. Most lighting shows are pre-
programmed. If the system has a constant delay of 50 ms from the lighting console to
the lights, timed events will always happen exactly 50 ms late. The lighting console
can easily compensate for this type of predictable latency by running exactly 50 ms
early. Jitter, on the other hand, is random latency that varies with time. The
lighting console cannot compensate for jitter with a static adjustment. From the
21
experimental data shown in Figure 9, the system exhibits a mean latency of 47.8 ms,
and as discussed above a jitter of one half packet time, or roughly 11.5 ms.
7 Experiment #2: Dropped Packet Rate
7.1 Procedure
Each Ethernet packet carrying DMX data is tagged with a sequence number, which is
unique, modulus 216. Every packet that is transmitted by an input node is expected
to be received by the output node. If a packet is transmitted and not received, it
is considered to be “dropped”. An Ethernet network is a connection of devices –
data sources, packet switches, and data consumers. Any of these devices may drop a
packet if the device or the network itself becomes overloaded.
Additional traffic, for example, will cause collisions on the Ethernet backbone, which
are normal events on an Ethernet network. Following a collision, the transmitter
attempts to retransmit the packet a finite number of times, usually sixteen. If each of
those retransmissions fails, the transmitter eventually gives up and drops the packet.
A dropped packet is identified by a non-sequential jump in the received sequence
number. Duplicate packets, although rarely a problem and usually an indicator of
more fundamental network problems, are similarly identified by a duplicate sequence
number. An unusual event, such as a dropped or duplicate packet, is logged using
the Unix syslog facility.
To conduct this experiment, one DMX input port is patched to one DMX output
port. The receiving output DMX node is monitored for the following statistics:
• received packet rate (packets / second)
• dropped packet rate (%)
• processor utilisation (%)
22
Additional input nodes are connected to the system incrementally. These input nodes
are not patched to the output node, but their presence creates additional traffic on
the common network backbone. The additional input nodes are simulated using
the Pathport simulation described in Section 5. The input and output node being
monitored are actual Pathport hardware. The output Pathport node monitors the
number of received packets per second to ensure the simulated Pathports are loading
the network as expected.
7.2 Observation
Without additional traffic on the network, the system dropped no packets. Input
nodes were added to the network one by one and the processor utilisation and dropped
packet rate were recorded for this new level of traffic. No packets were dropped until
the network load was over 1200 packets per second, as shown in Figure 10. At this
packet load the processor is at just over 50% utilisation.
7.3 Analysis
Dimming of incandescent lighting is not particularly susceptible to a single dropped
packet. As mentioned before, the thermal inertia of the filament naturally smoothes
transitions between discrete dimming levels. If the stepper motor of a moving light
misses a packet, however, it will stay at its previous location for an additional packet
time and suddenly jump two units of distance. This coarse motion of the light beam
is quite noticeable to the human eye. As such the dropped packet rate should be kept
at a minimum, preferably zero.
The Ethernet backbone proved to be capable of carrying 1200 DMX packets per
second without any packet loss, which is 200 packets per second more than the re-
quirement of 1000 packets per second specified in the functional requirement of Sec-
tion 3.1. 1200 packets per second equates to roughly 27 DMX input ports if each port
is transmitting at the full DMX rate of 44 packets per second. Beyond this, random
packet collisions on the Ethernet backbone cause packet loss. Lost packets can cause
a smoothly fading light to appear jittery.
23
Figure 10: Processor utilisation and dropped packet rate vs. packets per second
Incidentally, a rule of thumb exists for Ethernet that states network performance
begins to suffer at 60% utilisation of the 10 Mbps maximum throughput. With
network protocol overhead, each DMX packet is 610 bytes in length or 4880 bits.
At 1200 packets per second, the network utilisation is 5.856 Mbps or nearly 59%
utilisation.
utilisation =fpacket · nbyte/packet · nbit/byte
fEthernet
=
1200 packets
· 610 bytepacket
· 8 bitbyte
10 Mb/s= 59% (5)
24
8 Experiment #3: Processor Use while Merging
8.1 Procedure
The Pathport is capable of merging multiple DMX streams into one output stream
as described in Section 4.3. Merging multiple DMX streams is a processor intensive
operation. Every incoming channel is buffered and compared with the value of every
other channel participating in the merge to decide the controlling channel. The
maximum number of merged channels is ultimately limited by the capability of the
processor.
The Pathport firmware runs through the main house-keeping loop whenever it is not
occupied with more important tasks, such as receiving lighting levels and controlling
the output DMX stream. The number of times the Pathport runs through the house-
keeping loop in a given time frame is a simple measure of how much spare time the
Pathport has and is thus related to processor utilisation.
This experiment measures the number of times the Pathport passes through the
house-keeping loop in one second and plots that value versus the number of universes
of DMX data being merged.
8.2 Observation
To establish a base line, the number of cycles through the house-keeping function is
measured without any active lighting data. Figure 11 shows the plot of house-keeping
cycles per second versus the number of merged channels.
Figure 12 shows the same data normalised to 0% processor utilisation at the base
line. In other words, it is transformed such that x′ = x0−xx0
, where x is the frequency
through the house keeping procedure measured above, x0 is the baseline frequency,
and x′ is the resulting normalised processor utilisation.
This plot shows the Pathport nears 100% processor utilisation when merging nine
channels of lighting data.
25
Figure 11: House-keeping cycles vs. number of merged channels
Figure 12: Processor utilisation vs. number of merged channels
26
8.3 Analysis
The Pathport is able to reliably merge nine channels, which is one more than the pro-
posed requirement of eight channels. At ten channels, the processor is overburdened
and will drop incoming packets to compensate.
When the Pathport is overburdened, it runs the main house-keeping loop at a mini-
mum rate of once every 200 ms and drops incoming packets to compensate. This is
slightly different than the dropped packets of Experiment #2, where the transmitter
was being forced to drop packets by an overburdened Ethernet backbone. In this ex-
periment, the receiving Pathport is choosing to drop packets due to lack of processing
time. The end result, however, is the the same. The packet does not make it from
the transmitting Pathport to the receiving Pathport.
9 Conclusions
Designing the Pathport has been a successful and enjoyable project. With some
tuning for performance, the Pathport met all the design requirements set out in the
functional specification. The network is able to maintain a load of one thousand
packets per second without measurable packet loss, and can merge eight individual
DMX streams into one output stream.
The Pathport simulator, running on Linux and commodity hardware, was developed
particularly for this thesis. Running a port of the embedded firmware on the devel-
oper’s machine became an undeniable benefit. It allowed debugging the embedded
software on a controlled, transparent system, allowed simulating more embedded de-
vices than were immediately available, and did so without the added difficulty of
cabling dozens of devices. The greatest benefit was being able to run unattended
test-suites to collect data for the experiments. Running the tests by hand would have
been tedious and potentially error prone.
The Pathport won an award for best new product at Lighting Dimensions Interna-
tional, the lighting industry trade show, in its first year and is now an established
product being sold worldwide by Pathway Connectivity.
27
References
[1] Pathway Connectivity Inc. http://www.pathwayconnect.com/ (2005-02-15).
[2] United States Institute for Theatre Technology, “Digital data transmission stan-
dard for dimmers and controllers,” Tech. Rep. DMX512, USITT, 1990. http:
//www.usitt.org/standards/DMX512.html (2005-02-09).
[3] Entertainment Services and Technology Association, “Entertainment technology
- multipurpose network control protocol suite,” 2005. Also known as Architecture
for Control Networks (ACN). http://www.esta.org/tsp/documents/public_
review_docs.php (2005-02-08).
[4] Infrared Data Association, “IrDA SIR data specification,” 1996. http://www.
irda.org/ (2005-03-18).
[5] Entertainment Services and Technology Association, “Control Protocols Working
Group.” http://www.esta.org/tsp/working_groups/cp.html (2005-03-24).
[6] Michael Stickel, “DMX4Linux,” 2003. http://llg.cubic.org/dmx4linux/
(2005-02-02).
[7] W. R. Stevens, UNIX Network Programming: Networking APIs: Sockets and XTI.
Prentice Hall PTR, 1997.
28