Lighting Networks 101 DMX Digital Multiplex Protocol or

Lighting Networks 101

DMX Digital Multiplex Protocol or ANSI E 1. 11 – 2004 USITT DMX 512 -A Asynchronous Serial Data Transmission Standard for Controlling Lighting Equipment and Accessories

Proper DMX Layout Daisy Chain the signal path Console Fixture or dimmer

DMX Troubleshooting “T” or “Y” connections change the cable impedance causing reflection Fixture or dimmer Console

DMX Mixed Layout Opto-splitter/Repeater Console Merger Console Each DMX leg out of a repeater is its own electrical entity Repeaters can be daisy-chained

DMX Troubleshooting (2) Signal path must be terminated with 120 ohm resistor Console Terminator switch or plug on final fixture Fixture or dimmer Failure to terminate causes signal reflection back up the cable and intermittent problems

DMX Cable Low capacitance required to maintain wave form Belden 9842, 9729, 9829 Pro. Plex, Showplex Cat 5, Cat 5 e, Cat 6 Not microphone cable What they say about barb wire isn’t true

Wave Form Proper square/digital wave form Sawtooth wave form – likely caused by capacitance in the cable or slewrating in the transceiver Wave form overlay (typically caused by reflection) Multiple overlays are possible

DMX Data Packet High Start Code 44 u. S Slot 1 (lvl=0) Slot 2 (lvl=0) also 44 u. S 1 start bit (low) Mark-after-break 8 u. S 2 stop bits (high) Break 88 u. S Idle time can follow stop bits

DMX Data Frame Line Idle - high 2 Stop Bits - high 1 0 0 1 1 0 8 Data Bits high or low 1 Start bit - low Single Data Frame 11 bits altogether 44 u. S transmission time

RDM Remote Device Management or ANSI E 1. 20 - 2006 RDM Remote Device Management Over DMX 512 -A Networks

Why RDM? Because DMX isn't enough anymore Too much gear Too many universes Too much paperwork Too many places for things to go wrong Not easy to fix things on the fly

How RDM Works Does not make legacy DMX-only gear obsolete Uses a packet structure, like DMX RDM messages are interleaved or inserted between regular DMX packets DMX does not need to be present for RDM messages to be sent Requires all devices be transmitters as well as receivers

RDM Packet Structure Start Code Hex CC: indicates RDM Packet Sub-Start Code Hex 01: basically for future use Message Length Number of slots used by message Destination UID of intended recipient Source UID Transaction # Port ID/Response Type Message Count Sub-device Message Data Checksum Not sure why: only one controller allowed Used to match query and response Identifies controller's sending port and responder's type of message Incremented by responder – tells controller number of queued msgs IDs device within responder ie dimmer within the rack Payload! At last! 16 -bit checksum of all above fields

RDM Message Block Command Class Get, Set or Discovery Parameter ID (PID) i. e. : Network Mgmt, Status, Sensors, DMX 512 Set-up, others, or manufacturer specific Parameter Data Length Number of slots used by next part of message (can be zero) - responder needs to know when check sum begins Format depends on the PID Parameter Data

New Rules for System Design No more than 4 in-line devices between a responder and the controller In-line devices include opto-splitters, mergers, repeaters, anything that reprocesses the signal In-line devices must be bi-directional Timing changes to DMX E 1. 11 Break time extended to 132 u. S Each in-line device to reduce break by 22 u. S

Legacy Equipment DMX distribution gear developed prior to 2000 will likely need to be replaced no provision for bi-directional signal end gear will depend on manufacturer as purchasers you should be demanding support for older gear DMX-over-Ethernet likely will be okay currently no programming consoles with RDM

RDM and Pathway Support for firmware upload over RDM DMX/RDM over Ethernet via Pathport In-line Devices: DMX Repeater Pro Bi-directional opto-splitter Can also act as a controller e. DIN 1009 RDM opto-splitter Responder Devices: EDIN 1003 DMX to Contact Output e. DIN 1004 DMX-to-Analog e. DIN 1006 Analog-to-DMX e. DIN 1008 DMX LED Driver

ACN ANSI E 1. 17 – 2006 Architecture for Control Networks

Remaining Problems - sheer size of lighting installations (think LED) causing infrastructure problems - cost of wire and connectors for DMX/RDM - management tools not covered by RDM - multiple universe management - distribution management (merge, priority) - everything still mapped to 512 channels - maybe the answer is. . . Ethernet?

Ethernet Advantages - Cheap wiring and distribution gear - available everywhere - 10 Mbit = 40 universes at 250 baud (we get back to this one) - flexibility of star wiring - cheap (did I mention cheap? )

Proprietary Protocols (again) Strand Shownet ETC Net 1 ETC Net 2 Art. Net Pathport. . and less often AVAB Compulite Enttec Colornet Ki. Net. . . and none can talk to each other

DMX-over-Ethernet Advantages signal management - merging, splitting, priority switching unlimited outputs (dependent on network architecture) up to 128 universes of input (typical 2008) number of fully active universes varies from protocol to protocol but typically 12 - 15

Ethernet Limitations finicky installations sensitive to electrical interference not robust (compared to Belden/XLR) 100 m cable runs versus 500 m for DMX

Enter ACN media agnostic – use whatever cable you want intended as a generic language to control devices allows for plug and play

Alphabet Soup (1) CID – Component IDentifier DDL – Device Description Language DMP – Device Management Protocol SDT – Session Data Transport RLP – Root Layer Protocol Three letter acronyms – not just for audio anymore

Alphabet Soup (2) CID – Component IDentifier - unique identifier for each device on system DDL – Device Description Language - an XML file describing device properties and associated ‘behaviours’ - controller can pick and choose what it wants depending on sophistication and need

Alphabet Soup (3) DMP – Device Management Protocol - how to get and set properties of the device SDT – Session Data Transport - heart of ACN - allows efficient, reliable (error-checking) data transmission to one, a few or all devices on the network, depending on need - created specifically with the typically assymmetric lighting data flow in mind

ACN Overview - information not bound by 512 data slots - formatted or configured according to need - device reports native resolution - end devices can report abilities, parameters to the controller - no searching for libraries anymore - configuration using terms that make sense to the user - devices not limited to lighting equipment

How Will it Fit Together? - Ethernet backbone carrying ACN signals - some devices such as media servers, dimmer banks and LED drivers will sit natively on the network - gateway nodes will provide ACN-RDM control over configurable devices - gateway nodes will provide ACN-DMX control over legacy and 'dumb' gear

What’s on the shelf now? - DMX, obviously - RDM, increasingly - streaming ACN Ethernet protocol is available as Net 3 (ETC), s. ACN (Pathway) and soon others (MA Lighting, Pharos) - in the near term (5 years or less) s. ACN will replace the proprietary protocols - open. ACN group working on open source code modules (www. openacn. org)

Ethernet Design Tips (1) - structured wiring - IDC termination - TIA/EIA-568 certification - Cat 5 e vs Cat 6 -STP and conduit - observe cable lengths - max 90 m for copper - copper versus fibre

Ethernet Design Tips (2) - Power-over-Ethernet (802. 3 af) - device classes and sufficient power - switches vs routers - current lack of Etherner protocol converters

Troubleshooting (1) - managed vs unmanaged switches - bad things, maybe: - broadcast storm control - IGMP packet sniffing - multicast filtering - spanning tree protocol

Troubleshooting (2) - maximum traffic for 10 Mb devices - 24 universes for broadcast protocols - traffic patterns - Ethernet component reliability issues - RJ 45 vs Ethercon vs XLR - segregated traffic -VLANS - media converters