Aug 142021

For real, I’m still shaking my head about this one. The details are weird but it’s a fun story.

The original email we received was similar to so many which have come in before. “We’re trying to control a handful of Grafik Eye 3500 wall panels via DMX. Can you help?”

We’ve done this before and it’s pretty standard stuff. By adding a QSE-CI-NWK-E interface to an existing Lutron system, it becomes easy to talk and listen to their control bus via RS-232. We’ve used this method for many years to easily control Lutron equipment via DMX.

The control syntax is nicely documented, human readable, and not difficult to implement. For example, the command #OUTPUT,1,3,75,0<CR><LF> sets dimmer #3 on device #1 to 75% with a zero second fade time. For ease of use, as per their documentation, <CR><LF> means each command is terminated with the carriage return and line feed characters. So that’s two bytes at the end of each command. No big deal.

In our normal firmware, we generate these commands easily on-the-fly as monitored DMX channels change their various states. Lutron does suggest that commands be sent with a 100mS delay between packets, and we definitely respect that that advice. Years ago we learned that some of their controllers would crash, hard, if we pointed a firehose of serial data at them.

Anyway, we emailed a firmware update file to the customer, in a different country several time zones away. And sadly, after the update, nothing worked. In these situations it’s not unusual to troubleshoot: Is the serial cable correct? Was a null cable installed by accident? Does a null cable need to be added? Are the baud rates equal? Did we get the Lutron device ID numbers correct? And so on and so forth. Usually after half an hour on the phone, or a couple emails back and forth, everything just works.

I suggested that if I were sitting on-site, I’d connect a laptop and serial cable to the QSE bridge and send some control strings manually, just to confirm the syntax was correct, etc. At that time, they didn’t have those tools nearby, but the Lutron system does accept the same commands over the network via Telnet. After an hour, the client replied replied that he could correctly control the lights using this syntax:

#DEVICE,5<CR><LF>,6,14,88 <— That is, dimmer/channel 6 on device #5 set to 88%. 14 is the command for ‘assign level’ in Lutron syntax.

Ok, no big deal. We sent new firmware which generated output like this:

Setting dimmers 1 & 2 on device #1 to different levels.

That is, #Device,device ID, carriage return, line feed, then channel number, set value, value, time, carriage return, line feed. The terminal program, RealTerm, uses those micro-characters to represent non-printable characters. It’s a neat tool and makes it easy to tell if there’s non-ASCII garbage mixed in with a data stream.

No luck! The Lutron system only responded with random errors, which I forgot to screenshot as part of a TeamViewer session.

Finally, we went back to the notes the client took about their known-good control strings. Could it be that <CR><LF> is meant to be eight separate ASCII characters instead of the regular two bytes we’ve been using for years? This was such a strange idea, running counter to every set of Lutron firmware we’ve ever shipped, as well as all of their documentation. Ever. In the last ten years we’ve helped an awful lot of customers with this type of integration.

And thus, a new set of firmware was compiled and emailed. Check this out:

It works. No idea why, because it shouldn’t. We need to open a ticket with Lutron themselves to learn more. But until then, if you need help controlling their equipment with a DMX lighting console, please reach out. We’re always happy to help.

 Posted by at 9:51 pm  Tagged with:
Aug 142021
The nIO X Interface

Well, this was new!

Originally, the customer ordered one of our Field-Programmable DMX to RS-232 Bridges. It was shipped and delivered with no issue. Then the support email came:

“For example if I wanted DMX channel 245 to send the hex string A5 08 7A 01 01 00 21 F6 when the channel is at 1 should that string in the txt file look as follows?”

245 1 1|$A5$08$7A$0101$00$21$F6

This, happily, was the correct syntax. But upon further discussion with the customer, we learned that they wanted to control 8 channels of Acuity nLight dimmers via the nIO X bridge. The proposed setup would require several thousand unique control strings. That’s… a terrific pain to program and calculate by hand. And further, our existing firmware doesn’t support more than a few hundred field-programmable commands.

So we offered to automate the entire process and provide a custom firmware personality that they could load in the field via USB. In this case, DecaBox is generating transmitting the proper serial messages live, in real time, based on 8 sequential DMX channels. The start address, of course, is user-selectable using our LCD and pushbuttons. This is much, much more efficient than reading data from an SD card, checking to see if it’s valid, transmitting if yes and dumping if not.


As a side note, the Acuity control syntax is a bit more involved than some we’ve worked with, but definitely not terrible. The messages are all around 8 bytes long, (in straight hex, so not human readable) and there’s a fancy two-byte checksum at the end of each message

Here’s a screenshot of live output. The messages start with $A5, top left corner. The fourth byte, $01 in this case, means dimmer channel one. $0E is the level, then $25 $F8 are the checksum. At first, DMX channel #1 was run up and down, then later dimmer 2 ($A5 $08 $7A $02…) changes level as well.

Anyway, all is well. Need something similar? Let us know.

DecaBox MIDI Triggered Triple IR Blaster

 Case Study, MIDI  Comments Off on DecaBox MIDI Triggered Triple IR Blaster
Feb 112021

The phone rang a few days ago:

“We’d like to have our MIDI gear trigger IR codes, so we can discretely control three different TVs on stage during a live touring show.”


For many years, we’ve offered DMX triggered IR playback, but this was new. Further, this customer was building a rack and wanted everything to be rugged and portable. The TVs were mounted as far as 30′ from the equipment rack, so standard CAT5 cabling made sense to use as IR bug extension cords.

Over the course of an afternoon, we edited the main DecaBox circuit board in our CAD library, replacing the standard Neutrik XLR-5 connectors we use for DMX in, through and out with three Neutrik EtherCON jacks.

These shiny CAD files were sent to Asia on a Friday evening. Two days later, we received a DHL tracking number for our small order. In the interim, I locked myself in the programing cave and merged our existing IR and MIDI libraries. When the dust settled, here’s how everything runs:

  • Up to 16 IR codes can be captured. These commands are totally arbitrary. We don’t care if it’s Sony or NEC or Samsung or LG or bargain-bucket Asia Amazon stuff. We simply store the raw IR timing data internally.
  • The user can set the desired MIDI channel, which can be anything between 1 and 16. All MIDI data on other channels is ignored.

As far as mapping goes, there are 128 notes in a MIDI scale. They are divided into octaves of twelve notes. Notes can be identified by their name and octave, like this: C3, F#7, B8. Also, each MIDI note is assigned a number. Note that these are zero-based, so the range is [0 127]. Classic Middle C (orange) is #60 or C4. C-1 is 0. G9 is 127. Etc.

The DecaBox maps MIDI ‘note on’ messages to IR commands and directs signals to its three hardware outputs like this:

Thus, any command can be sent to any output, or to all outputs, depending on what’s needed. All other MIDI data, such as note off, patch change, continuous controller, etc is ignored.

There’s also some tricky wiring in our RJ45 jacks which may be useful for a future project. Assuming a 568-B cable, the blue pair corresponds to pins 4 and 5. IR data is a buffered +5v output relative to pin 5 (ground). Most standard IR bugs handle 5v signals without any issues. However, it’s possible that in the future, this customer, or someone else, may need long-distance IR capabilities. For that reason, the three remaining wire pairs are set up like this:

  • 1 pair is ground
  • 1 pair is DC +9v
  • 1 pair is IR data, but driven by an RS485 (balanced) line driver, similar to how DMX works. This makes it easy to transmit complicated data long distances, without worrying about induced noise.

So all we have to do is design a 1″ square circuit board to accept power, ground and RS485 data, then output standard IR. Presto! Remote IR playback on cable that could be several hundred feet long.

Need one? Let us know.

 Posted by at 8:32 pm

A Handful of Weekend Wonders

 Case Study, DMX  Comments Off on A Handful of Weekend Wonders
May 242018

In addition to the standard products listed in our web store, we do quite a bit of custom / one-off work.  Here’s a collection of recent quick-turn projects we’ve recently shipped.  All images here can be enlarged with a click.

The DMX Triggered DMX Selector Switch

A theatre up north had several lighting control sources (a large lighting console, several wall panels, etc) plus safety rules which require certain channels be kept at a specific intensities 24/7.  Based on their sketch and pseudocode, we designed a five input DMX router.

For any input, setting a specific channel to a specific value lets that DMX source take control, and its full universe of data is passed to the ‘DMX Out’ jack.  In addition to switching between the five inputs, the system forces the safety channels to their proper values and sends the final signal downstream.

If you think about it, in this situation, a standard DMX merger running either ‘highest takes precedence’ or ‘most recent takes precedence’ wouldn’t work properly.  The system contains a USB interface for painless field firmware updates if they’re required.  Each DMX input is optically and galvanically isolated from its neighbor, which should keep lightning propagation to a minimum.

Side note #1: Our stock DMX receive circuitry has been installed in thousands of locations worldwide.  And in over a decade, we’ve never, ever received a report of it being damaged in any way.

A Countdown Timer / High Power UV Trigger System

Though not one of our usual DMX / MIDI / serial projects, we’d worked with staff at this childrens’ museum several times in the past.  It’s rewarding to deliver something which didn’t exist, anywhere in the world, until we made it so.

In a dark corner of the museum’s ‘color and light’ lab, an entire wall was painted with photoluminescent paint.  When excited by a xenon strobe light, flashlight or blacklight, the paint activates and glows green for several seconds, slowly fading away as the energy dissipates.

The designers envisioned a ‘photo booth’ where patrons could press a trigger button and then pose against the wall.  The paint is then activated by the light source, leaving a glowing silhouette.

We sourced a pair of 10W UV lights (395 nm and super intense, causing mild eyeball sunburns after twenty seconds of near-field exposure) and a 4″ illuminated pushbutton.

I felt that standard 7-segment displays looked mechanical and dated, but a quick search online returned a slightly stylized 7 segment font – ‘Modern Mini’ in bold italic.  The ~5 degree slant looked fun, and I liked how the segments jauntily meshed together.


It took a few steps in the CAD program, but the digits were converted to vector data.  On the shop’s laser cutter, we created a 7-segment display measuring 300 x 200 mm.   The display was loaded with LEDs whose brightness and color can be arbitrary controlled, segment by segment.   The finished assembly is a sandwich of several acrylic layers, using black, clear and white stock.  The segments are inlaid in the black layer, then covered with a clear protective layer.  The layers allow the light for each segment to be channeled, diffused and displayed in a pleasing way.

Also, the giant pushbutton contains a white LED which can be set to any intensity.

Our custom circuit board include a small display for changing and storing settings (UV / flash exposure time, countdown time and ‘timeout’ time).  It was somewhat overbuilt, supporting 4 contact closure inputs, 4 buffered logic level outputs, a pair of high power output stages and 4 SSR (solid state relay) outputs, in addition to connections for the countdown display and a smattering of indicator lights.

During normal operation, the display reads ‘5’ in green, and the pushbutton pulses slowly, à la sleeping iMac, drawing attention to itself in a tasteful way.  When the button is pressed, the white LED turns off and the countdown begins.  At time zero, the UV sources pulse for their specified time, the display switches to blue and begins begins counting down from the ‘lockout’ value, giving patrons a chance to enjoy their artwork as the phosphorescence slowly fades away.

Once the lockout time has passed, the pushbutton resumes its quiet pulsing, the display switches back to green and waits patiently for input.

Side note #2: The blue / green color scheme was chosen in a nod to the industrial designers at Disney. Green means go, blue means wait.  Red signifies danger and problems, so don’t bother the public unnecessarily.



 Posted by at 4:53 pm

DMX Multi-Zone Universe – A White Paper

 Case Study, DMX, RS232  Comments Off on DMX Multi-Zone Universe – A White Paper
Mar 092017

Mike Slattery, CTO over at TEKVOX in Dallas, wrote a short white paper about how our DMX Engine can easily control fixtures in multiple physical zones, and shows how the Engine’s ‘mask’ command makes it simple to adjust the look in each zone without affecting surrounding areas.

He writes from a Crestron background, but the principles apply to every major control platform.

Take a look! DMX Multi-Zone Universe [PDF]




 Posted by at 5:47 pm