Demilight Version 0.8.1

The newest round of Demilight PCBs and 3D-Prints have taken shape as version 0.8.1. Here’s a brief video overview of the current state of thing:

The biggest change, as I mention in the video, is that I tried out JLCPCB’s surface mount parts assembly service for the firs time. Overall, I’m very satisfied, and I’m delighted to have such a useful shortcut for assembly of these PCBs. The version 0.7 and 0.8 prototype boards, which are essentially the same as 0.8 with their 0603 passives and tqfp ATmega, took between 60 and 90 minutes each to assemble. I wouldn’t say they were an enormous challenge to assemble, they just took time and concentration.

But now, with JLCPCB assembling the surface mount components, each of the 0.8.1 PCBs took just 3 minutes to finalize assembly, and it’s all easy thru-hole parts. As I’m considering making a little flock of these, or providing them to folks who aren’t as practiced at soldering, finding ways to accelerate the assembly process is a huge boon.

Of course, there’s some additional cost to getting the boards machine-assembled. And for ordering just two assembled boards, of course the unit-cost is going to be high. But it drops off quickly with any kind of scale. I just put in an order for some 0.9 PCBs, and getting 10 of them instead of 2 dropped the unit-cost by almost 70%. All the fixed costs – DHL shipping, extended-part-charges from JLCPCB – start to amortize real quick. Most of the components themselves have a 10- or 20-part minimum order, due to part-loss loading and unloading the pick-n-place machines, so the component cost didn’t actually increase all that much except for the expensive IC’s (ATmega, AL8860).

Looking forward to 0.9.0.

Video: Demilight Version 0.8

It’s been quite awhile since the mini-moving light project (now renamed The Demilight) has been written up on the blog. The project was in hiatus for a few months while dove into the technical challenges of a new job, but as the job isn’t keeping quite as busy at the moment (here in early summer 2020), it’s back on the workbench. I’ve put together a video showcasing the current state of the project, now in version 0.8:

The video does a pretty decent job of capturing the current state of things. So what’s next?

Firstly, the goofs I alluded to in the video that I consider to be must-fix items before the files are ready for primetime. Theu mostly have to do with the 3D-printed parts – I adjusted the access holes and programming slots from version 0.5 to 0.8, but I didn’t do a great job double-checking everything, and things don’t line up very well. That’ll need another few test prints and some adjustment to alleviate the all the filing that’s currently necessary.

I’ve also been having some issues with mechanical assembly – I’ve been using some M2 insert nuts to hold the case and case-lid together, and to secure the PCB into the case, but that doesn’t seem to be a particularly good system. It’s possibly my nuts and bolts are just really high-tolerance, but they’re constantly cross-threading and not inserting all the way. I think a more robust solution is in order.

The other main error has to do with the footprint for the 5V buck-converter module – somehow, my pin placement is off by .2″ on the PCB footprint, which makes the part overlap with the attachment points for the servos unless you bend the voltage-regulator’s pins over. Not insurmountable, but really annoying. That’ll have to get fixed in version 0.9. Once those two most-egregious errors are corrected, though, I think the unit will be decent enough to publish as a beta version.

It’s a pretty simple part… how did I goof this up?

There are several more substantial improvements in the pipeline as well. In no particular order:

As I mention in the video, I’m working on a miniaturized programmer interface based on some little 0.05″-pitch pogo pins. The results, so far, have been mixed – I have been able to confirm that the interface is providing gnd/5V to the ATmega328, at least enough that its 16 MHz ceramic resonator is oscillating, but I can’t seem to program the chips in-place. Further experiments will be necessary.

Some iterations of the Demilight have incorporated a heatsink to help manage the heat-output from the LED emitter chips. To be honest, I’m not sure how necessary it is – I would love to set up some tests with the unit running at its full 1 Amp current and see just how hot things get. Perhaps the first test would be in free-air, then inside the case in multiple orientations. I know from some tests I did on a livestream last summer that with enough heatsinking the LED stars can handle up to about 5 Amps, but they dump a huge amount of heat at the point.

If the heatsink comes back, should it still be in candy-apple red?

RGB or RGBW dimming capacity would be really neat – as spiffy as the pure-white versions are, there’s something about color-changing light that feels like it would take this project to the next level. I would need to free up some more PCB space, and possibly move from a single-channel driver to a 3 or 4 channel driver, but finding those in the ~1A current capacity range seems a little tricky.

There are also a couple of purely aesthetic things which could get bumped up to something better. I’ve ordered some 1/4″ white wire sleeving to take the place of the gaff tape covering the wires that run from head to base. And I need to invest a little time dialing in my 3D printer – after 3.5 years of printing, it’s starting to show its age a little bit, and a little extra tightening and lubrication wouldn’t be a bad idea.

So many of my projects during quarantine have focused on building my digital communication mediums – building out this video feels very much like a continuation of that skill-building. The weekly Arduino/Electronics classes I’ve been teaching for 15 weeks now have been a serious crash course in live digital video. That learning process deserves a write-up of it’s own, but if you compare the following two frames from Episode 0 (testing) and Episode 14 (Wireless Signals), I think the improvements are pretty clear:

Epsiode one was…. pretty rough. The audio is really crunchy too – turns out I had two microphones on (lav and webcam) and they did unkind things together.

We’ve got things pretty well dialed in by now.

It’s been a joy to build some more digital video skills putting this video together, like putting together a basic script, recording a voiceover, learning the editting, effects, and color-grading processes… it’s been both fascinating and time-consuming. The video definitely has some rough edges, but I’m thinking of it as good-enough, and I’m excited to take what I’ve learned from this early creation and apply it to future videos. Much like the tiny-light itself, it’s good to just make a thing, anything, a small thing, and iterate from there.

ETC Console Output Counts

What follows is a list of output-counts for ETC Eos Family consoles. Because I’m always needing to reference this information, and I want to be lazy when I need to find it. So, without further ado, here’s the current output capacity for different ETC consoles, as of July 24, 2019:

ConsoleVariantBase Output CountUnlocked Output CountLegacy Consoles Upgraded to 2.6 Software
Eos TiDisplayPort4096
(8 * 512)
(48 * 512)
Eos Ti DisplayPort at 5K or higher now @ 24,576
Eos TiDVI4096
(8 * 512)
(32 * 512)
Eos Ti DVI at 5K or higher now @ 12,228*
Eos RPU3DisplayPort4096
(8 * 512)
(48 * 512)
Eos RPU3DVI4096
(8 * 512)
(24 * 512)
Eos Classic  4096
(8 * 512)
(8 * 512)
Eos Classic at 5K or higher now @ 8192
Eos Classic RPU  4096
(8 * 512)
(8 * 512)
Eos Classic RPU at 5K or higher now @ 8192
(8 * 512)
(48 * 512)
Gio Displayport at 5K or higher now @ 24,576
(8 * 512)
(24 * 512)
Gio DVI at 5K or higher now @ 12,228
Gio @5 4096
(8 * 512)
(48 * 512)
@5 at 5K or higher now @ 24,576
Ion XE 2048
(2* 512)
(24 * 512)
IonWindows 71024
(2 * 512)
(12 * 512)
Ion Win 7 at 1536 or higher now @ 6144
(2 * 512)
(6 * 512)
 Ion XP at 1536 or higher now @ 3072
Ion RPUWindows 72048
(2* 512)
(12 * 512)
Ion RPUXP2048
(2* 512)
(6 * 512)
ETCnomad 512 6144
(12 * 512)
Nomad 256 now @ 512; Nomad 1024 or higher now @ 6144
ETCnomad Puck4 USB512 6144
(12 * 512)
Nomad Puck 256 (3 USB) now @ 512; Nomad Puck 1024 (4 USB) or higher now @ 6144
ETCnomad Puck3 USB5122048
(2* 512)
Nomad Puck 256 (4 USB) now @ 512; Nomad Puck 1024 (4 USB) or higher now @ 2048
Element 2 1024 (2 * 512)6144
(12 * 512)
Element 1024 (2 * 512)  
ETC Nomad “256 1024 (2 * 512)  

*The listed Eos Ti DVI count for previously-smaller-output-count consoles doesn’t match the new Unlocked output count. This may be a typo by ETC.

This info comes from: the EOS Software 2.6 Release Note, the Upgrading Eos Family Output Counts page, the Element Tech Specs page, the Element 2 Tech Specs page, the Ion Xe Tech Specs page. As always, information from ETC will always be more accurate than the blog of some guy in the Midwest – this is meant to be a helpful reference, not a definitive source.

The legacy consoles section indicates the new output counts for consoles that were available before Eos software version 2.6, when consoles were available for purchase with much more granular output counts. The 2.6 software upgrade standardized all consoles to either a Base model or Unlocked, with all consoles moving to the next higher output count available (e.g. no one lost output capability with this upgrade).

Some background, and an explanation of why output counts aren’t round numbers: ETC’s line of Eos-family lighting control consoles can be purchased with different numbers of parameter outputs. In an older way of thinking of things, one might have had a limited number of universes. As I’ve featured in my post about lighting control protocols, each universe contains 512 “slots” of information, and individual devices (dimmers, intelligent lights, other controllers) can be told which slots to listen to by giving each device an “address” (or range of addresses).

The key difference is that now, with lighting data being largely distributed over a network and only turned back into ‘hard’ serial DMX near its endpoint, limiting a controller’s output to only 2 or 6 or 24 physical universes would be a little unnecessarily constraining. Instead, the output count is how many total DMX slots one can control, spread across as many universes as the user desires. So, a basic Nomad, for example, could control all 512 slots in a single DMX universe, or a single address in each of 512 universes, or anything in between. Only addresses which are patched count toward the total output count.

For more info on addresses and parameters, see ETC’s article: Addresses and Parameters in Eos Family Consoles

DMX Mini Moving Light First Assembly – Live Stream

With the shell 3D-printed and the PCB assembled, I went ahead and put together my first “completed” mini-moving light, live on camera:

It went fairly well – everything mostly worked and nothing caught fire!

There are a few mechanical and electrical takeaways for the next version, including:

  • Mechanical:
    • Ennlarge the hole for LED wires in the lower case
    • Make a brief instruction manual for myself of what needs to be assembled/installed/solder in what order
    • Hole for program/enable switch access
    • Fix tolerances on the tilt-servo/yoke interface
    • Lengthen the body to accommodate a heatsink for the LED star
    • Figure out mounting/hanging hardware
  • Electrical:
    • Increase the spacing between Pan and Tilt Servo pads
    • Order higher-current 5V regulator (1.5A 7805)
    • Select a new inductor for up to 1A of current
    • Select a new schottky diode for up to 24V
    • Combine the transmit/receive control lines onto a single pin of the Arduino.

But all in all, for a first assembly, even tripping over a couple of silly mistakes on my part, things went pretty well. Onward to V0.4.

DMX Mini Moving Light Shield V0.3

As I hinted to in my original post about the Arduino Pro Mini DMX Shield, and then talked some about in my PCB Assembly Livestream, the latest version of my DMX shield is geared toward driving in miniature moving light. This means that, in addition to being able to receive DMX, the Arduino driving the device will need to be able to drive a couple of servos and dim a relatively high power LED. There are many way of skinning both of those cats, so let’s look at the solutions that are present in V0.3 of the DMX shield.

Servo Control

Of LED dimming and Servo control, the latter is the easier problem to solve. While there are dedicated servo-driving IC’s, and modules, almost any microcontroller, including the ATMEGA238/Arduino can control a hobby servo in a straightforward way using minimal additional hardware.

A typical hobby servo needs only three wires running to it – +5 for power, Ground, and a control line. The control line carries the position data for the servo in the form of pulse width modulation. The servo expects to see a pulse every 20 milliseconds. A pulse of 1.5 ms corresponds to the center (90°) position of the servo. A 1 ms pulse rotates all the way in one direction (0°) and a 2 ms pulse rotates fully the other direction (180°). There is a standard Arduino Servo Library that translates degrees inputted into the appropriate duration Servo pulses.

Image Credit: Wikimedia Member Hforesti, CC-SA-4.0

The only additional hardware present on the V0.3 board for Servo control is, therefore, a bulkier 5V regulator. The 5V regulator on an Arduino Pro Mini isn’t particularly stout to begin with, and I’ve had issues on previous projects with “off brand” Pro Minis having even less 5V oomph than that. So there’s a pair of DC input pads and a TO-220 packaged 7805 to provide a healthy amount of current for the servos.

LED Dimming

The LED dimming half of this project has a wider solution space than servo control. The typical solution is MOSFET dimming. A FET is switched on and off rapidly, with a variable duty cycle to control brightness. This is the solution that commercial DMX LED decoders use, with a bank of 3A-5A fets, one per driven channel. It’s simple and inexpensive.

The problem is heat. MOSFETS with super-low on-DC resistances are expensive, and those with higher DC resistances create more heat. There’s always a balance being struck between cost and current carrying capacity. Which is why most commercial DMX led dimmers sit in a sweet spot between 3A and 5A. And all of them come in metal cases, sometimes mounted to large heatsinks, to help with heat dissipation. Less than ideal for what is ultimately meant to be a 3D-printed moving light made of thermoplastic.

The other problem is overcurrent regulation. For typical, inexpensive 3A per channel DMX LED driver, there’s nothing to protect the FETs if you load up a channel with, say, 5A of load, there’s nothing in the drivers to prevent the FETs heating up to their failure point. Or worse. See, for example, this example from a local theater:

After some investigation, it turned out that there was a wiring error causing a dead-short across one of the channels. Which subsequently burst into flames. No kidding. The Stage Manager reported seeing a cloud of smoke roll out of the vom, which it turned out was discharge from the fire extinguisher the crew was using. Yikes!

With a controlled environment and a defined load, an overcurrent load is slightly less of a concern, but it seemed like there must be a more elegant solution to both the heat and overcurrent issues.

The solution I’m currently trying is the the AL8860 Buck LED Driver. It is essentially a DC-DC step-down converter which derives the average current through its load from a SET resistor between a couple of its pins. It has an input voltage from 4.5V to 40V, and in TSOT-25 form factor a maximum current of 1A. A TTL PWM signal applied to its CTRL pin brings the average current down from the maximum SET current to between 0 and 100% of maximum, depending on duty cycle.

While the IC itself ultimately uses an NDMOS FET to do its switching with a relatively high on-state resistance (200 mOhm), its incorporation of current management and a step-down converter directly into the IC makes it an attractive option. And for the form factors I’m looking at, I’m not likely to be pushing more than 1A through an LED star anyway.

The AL8860 requires a few external components as a buck converter would – an inductor and a schottky diode – as well as a bypass cap and the SET resistor(s). These altogether take up about as much PCB space as a decently sized FET switch would, let a long the voltage conversation IC’s that would allow this to run on a variable voltage.

The portion of the PCB directly responsibly for 1A LED dimming. Approximately 8mm x 8mm. The two large thru holes directly below this are points to solder leads from the LED star directly.


I made the bold choice of testing this IC and hardware on a livestream recently. But not before an unscucessful attempt test attempt.

In an attempt to validate this IC idea before committing to it, I purchased a handful of AL8860s, schottky diodes, 0.1 Ohm resistors, and inductors, and tried to piece together this idea on a piece of copper-clad. That did not, in short, go well. Without proper pads, I couldn’t get the IC to stay in place well enough to solder magnet-wire to it. Even after I super-glued it down, the heat from my soldering iron weakened the super glue and caused it to come unstuck. And release superglue fumes. Fun!

So I pulled the trigger on ordering a batch of the V0.3 PCB’s, this time from JLCPCB. But in my rush, I didn’t run a final Design Rule Check, and the pads for my Pan and Tilt servos overlap. Ah well, this was mostly to validate the LED dimming circuit.

And validate it did! Check out this gif from my testing session:

Now that’s some light! The arduino was just running a simple ramp-up/ramp-down for validation.

The LEDs are from LEDSupply, a vendor on the east coast that I haven’t used before, but stumbled upon while looking for LED options. They happen to be having a closeout sale on some Luxeon R 3-LED stars, which seemed like a good option for something I might smoke or blow up. The LEDs themselves are Luxeon LXA7-PW40s. And with the appropriate Carclo optic, the beam width is fairly narrow. The heatsink is just something from the junk bin.

At 1000mA forward current (which LEDSupply recommends as the maximum allowed current), they emit around 975 lumens total, around what a 75W PAR16 lamp emits. Even testing at 500mA as I was, it’s a punchy little package!

Next Steps

There’s some CAD time in my future. I’ll need to whip up a case to hold the PCB and accommodate a pan servo. I think the arm and body components I will be able to mostly re-use from my previous design, possibly with a little extra room in the head for a proper heatsink.

The previous tiny moving-light design

At some point, I’ll have to re-order PCB’s with the errors corrected, especially the overlapping servo-control pads. I may also want to rethink the mounting hole locations, and possibly bring the DC and DMX inputs out onto their own little tabs to solder connectors onto. But first, I think it will be satisfying to bring this version of the LED to life.

DMX Mini Mover Shield PCB Assembly Stream

Last night, as I started to assemble V0.3 of my DMX Mini-Mover Shield, I thought it might be fun to switch on my webcam and stream the assembly live to the World Wide Web. What follows is about 80 minutes of unstructured benchwork, chatting about DMX, sACN, and circuitry, and a first test of the new LED dimming circuit. Will it light up, or will it go boom? Watch the video to find out:

Lighting Control Protocols and Standards

The world of stage lighting uses a variety of communication protocols to link control devices (computers, light boards, houselighting systems) to endpoint devices (lights, dimmers, effects). These run the gamut from basic analog control through legacy serial protocols to modern packetized, ethernet-based protocols.

The specifications of many of the most widely-adopted protocols are managed by the Entertainment Services and Technology Association through their Technical Standards Program. Confusing matters slightly, these protocols are sometimes referred to by their ESTA standards numbers, often interchangeably with the common names. Below is a list of the major ESTA standards that apply to lighting control, with their standard number, their common name, and a brief description.

I’m not directly linking to the standards documents, but you can find them all on the approved standards page of the ESTA.

Here are the currently released standards:

Document #Short Name
E1.30-10V Control
E1.11DMX 512

Briefly, the protocols are:

E1.3 0-10V Control: Specifies control of dimmers/luminaries via individual analog control lines. 0 volts is always off, or one extreme of a parameter (e.g. full pan left; minimum blue; focus all the way in, etc). 10V is always on, or the other extreme of a parameter. “0V” is really -0.2V to 0.3V. “10V” is really “9.8V to 30V”. Control lines must be stable to ± 20mV. Minimum load impedance is 50 kOhms. Passive controls have max 2.5 kOhms output impedance; active controls have max 100 Ohm output impedance. Short circuit protection, overvoltage protection, and current supply are also specified.

E1.11 DMX 512: (“Digital MultipleX“) Specifies a 250 kbps serial protocol for controlling equipment, the EIA-485 transmission techniques for the same, physical cable specifications, and appropriate connectors (XLR5). The 5-conductor cables are common, data 1±, and data 2± (rarely used), each not to exceed 6V above common. Data lines are balanced in pairs. Signal line impedance is 120 ohms nominal. Each “packet” of serial data begins with a break, mark, and start code, followed by up to 512 slots of data, each of which has an 8-bit value. No error checking/correction is provided.

E.1.17 ACN: (Architecture for Control Networks) Specifies a series of protocol formats for (generally network-based) interchangeability between control systems and endpoint devices. Generally: the Device Management Protocol (DMP) encapsulates the Getting and Setting of device parameters; a set of Device Description Language standards (DDL) defines the format and language for component description to allow common control and identification; and the Session Data Transport (SDT) protocol allows for multicast delivery of messages with ordering and verification not present in generic UDP multicasting. The Protocol Data Unit is the singular message format for DMP messages.

ACN also provides for device discovery. While typically used with TCP/IP and 802.3 Ethernet or 802.11 WiFi, other physical/link/transport/network layers are incorporated as possibilities, including various serial and RS485 standards, via interoperability profiles.

E1.20 RDM: (Remote Device Management) Specifies an extension to a DMX512 link permitting intelligent, bi-directional communication between devices. An alternative start code in a DMX packet identifies an RDM packet. RDM uses a binary-tree or similar search to identify devices on a DMX512 line. Controllers can use RDM messages to Get or Set parameters of endpoint devices, and communicate to individual endpoints when they may drive the line to respond to Controller commands. Device configuration and monitoring are primary goals, as is identification.

E1.31 sACN (Streaming ACN): Describes a lightweight mechanism for streaming DMX packets over an IP network using a (small) subset of the ACN suite. Describes data format, protocol, addressing, and network management, as well as a synchronization method for ensuring that data arrives concurrently at multiple endpoints.

There are also some subsidiary standards documents managed by the Control Protocols Working Group, including:

  • E1.27-1 – Standard for portable control cables for use with DMX512
  • E1.27-2 – Standard for Permanently Installed Control Cables for use with DMX512
  • E1.30-1 – EPI 23, Device Identification Subdevice
  • E1.30-3 – EPI 25, Time Reference in ACN Systems using SNTP and NTP
  • E1.30-4 – EPI 26, DDL Extensions for DMX512 and sACN Devices
  • E1.30-7 – EPI 29, Allocation of IPv4 Addresses to ACN Hosts
  • E1.37-1 – Additional Message Sets for E1.20 RDM Part 1 – Dimmer Message Sets

In addition to the published ESTA standards, it’s worth mentioning two that are not currently maintained as standards:

The standard for E1.33, RDMNet, has been in draft review since at least 2011. It defines a suite of protocols for the types of device discovery, device management and configuration, and automatic device configuration that RDM provides on a DMX512 link, but across a network. It defines a broad scalable architecture that allows for multiple controllers and “tens of thousands of responders,” as well as a minimal protocol for carrying non-RDM data over the same protocol. The spec defines

  • A Low Level Recovery Protocol (LLRP), used to configure IP settings so that E1.33 equipment achieves connectivity
  • A Broker protocol, which allows for discovery and many-to-many message transport
  • The RDM Packet Transport Protocol (RPT), which defines the primary packet formats and messages, as well as topology and functional requirements for controllers and endpoints
  • The Extensible Packet Transport protocol (EPT), which may be used to carry non-DMX data in a similar way to RPT.

BSR E1.33 Concluded its fifth public review in January 2018 with 68 pages of public comments; no date is known for the next public review session. As noted below, ETC has its own mechanism for transporting RDM and RDM-like data over ethernet via its NET3 suite.

The second ‘standard’ of interest is the former E.1.45, “Unidirectional Transport of IEEE 802 Data Frames over ANSI E1.11 (DMX512). This provided a mechanism for transmitting IEEE 802 packets – including Ethernet (802.3), Wireless LAN (802.11), and Bluetooth (802.15.1) – over a DMX512 link by using an alternative start code, stuffing the packet data into the DMX “payload” area, prepending two byte of sequence numbers and appending a two octet CRC for error checking. Interestingly, it seems that this standard was aimed specifically at Visible Light Communication (802.15.7), for transmission of data in the visible spectrum.

After publication, it was established that key parts of the E1.45 standard were covered by US and Korean patents, and the patent holder would not guarantee that licensing could be made “under reasonable terms and conditions that are demonstrably free of any unfair discrimination.” Therefore, in October 2015, the ESTA withdrew this document as a standard.

Beyond the ESTA-specified standards, there are a handful other vendor-specific or genre-specific communications protocols in use. Electronic Theatre Controls (ETC) has used a number of protocols all their own over the years, including:

ETCnet (Net1): Originally called ETCNet and retroactively renamed to Net1, this was ETC’s first Ethernet based control protocol. It is proprietary, without publicly available specification. It is a raw Ethernet protocol (layer 2), meaning that routers and certain types of switches do not pass Net1 traffic. A hub is recommended. Net1 provdes transport of console video information, up to 4 universes of DMX, tracking backup data, and keyboard command information to ETC products of the era, including Express/Expression/Insight and Obsession 1. Many Net2 DMX nodes can also be configured to operate in Net1 mode, with the concomitant loss of function.

ETCLink: ETC’s Sensor dimmers with a CEM classic controller use this protocol to provide dimmer feedback to the console. Express/Expression and Obsessions 1/2 consoles could receive this data. Connections were commonly a 6-pin XLR connector. This functionality has been supplanted by ethernet-based feedback in modern systems.

ETC Net2: Introduced with the Obsession II console, ETC’s second networked control solution incorporated IP addressing, this allowing network traffic to be switched or routed. Sends DMX data as eDMX, which in its final version incorporates per-“range” priority. Includes EDIMI, ESMPTE, FTP for ETC devices, and video data for remote video units.

ETC Net3: ETC’s current suite of network-based communication. Sends DMX data over sACN. Uses a non-public RDM-over-ethernet protocol to receive RDM data from Net3 DMX Nodes. Incorporates network video data as Net2 did. Many ETC products (Sensor Dimming, Paradigm, Mosaic, Unison, etc) have ethernet functionality, but it is nebulous which of these fall under “Net3” and which are their own Ethernet-based communication system.

ETC also uses LonBus-based networking devices to control various legacy architectural control stations – while their modern counterparts can also usually take LonBus, they are typically served by an Ethernet connection.

Other situation-specific lighting communication protocols include:

Art-Net: A simple implementation for streaming DMX512 and RDM information over IP networks, typically ethernet. Multiple versions exist (1 thru 4) with significant differences – version 1 uses only broadcast packets; version 2 uses broadcast for discovery of endpoints and unicast for data delviery. Version 3 introduced the ability to expand to up to 32,000 universes, and further refinements were made to version 4. Artnet uses specific IP ranges for much of its configuration, which can present integration challenges when it needs to exist alongside other switched protocols.

HogNet and Fixturenet: High End Systems uses its proprietary HogNet ethernet suite of protocols to link its line of Whole Hog lighting consoles, as well as their DMX processors and optionally other lighting control PC’s. These connect to a specific HogNet RJ45 connector on the back of most Whole Hog consoles, with its own NIC. A secondary connection, the FixtureNet ethernet connection, is used for connecting to Art-Net/sACN(E1.31) DMX gateways.

CITP (Controller Interface Transport Protocol): Used by some lighting and video controllers to exchange pictures and video streams over a network. The standard is maintained by Capture.

PosiStageNet (PSN): An open protocol developed by MA Lighting to transmit realtime position information over a network, for example from a tracking device on a moving actor, scenic piece, or prop to allow for video, lighting, or motion-control tracking.

So what does the future of lighting control look like? Clearly, we are living in an increasingly-connected theatrical world, and most of that connectivity is Ethernet-based. I don’t expect to see an entirely new paradigm at the link layer any time soon.

I have expected for many years to see an additional level of automation and abstraction in how we set up lighting systems. When all of the devices in a system can talk to each other, is there still a need to individually plan, address, patch, and coordinate the ID’s of individual fixtures or dimmers? Or can we automate ourselves out of the time consuming business of managing how the devices talk to each other and let the system set up its communication network automatically? We shall see.

No matter what the future holds, we’ve come a long way from Piano Board dimming.

Update: After posting this on Facebook, a friend asked about the AMX protocol that he remembered from high school. Here’s the brief answer I gave him:

AMX (Analog MultipleX) was one of a bunch of protocols (AMX192, CMX, MPX) that appeared in the late 80’s as people were trying to solve the “one dimmer = one wire” problem of E1.3 0-10v. It used 4 wires – two for a (balanced) clock signal, one ground, and a signal line which carried a succession of analog voltages (0-5V) that represented the levels of up to 192 parameters.

Acceptable connectors were 4-pin XLR or TY4F (mini-stupid!). Interestingly, the spec requires “sound-style” Male XLR connectors on the controller and female connectors on endpoints. 

The AMX192 standard was developed and published in 1987 by the United States Institute for Theatre Technology (USITT), instead of the ESTA.

Full spec re-hosted here: