Engineering Solutions Inc – Since 2003! Protocol Converters, Projector Shutters and Electronic Curiosities.

The Most Bizarre DMX to Lutron Bridge Firmware We’ve Ever Shipped

Case Study, DMX, RS232 Comments Off

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.

DecaBox DMX to Acuity Systems nLight

Case Study, DMX, RS232 Comments Off

Aug 142021

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.

Success!

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

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.”

“Ok.”

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.

DMX Engine – New Output Selection XLR3 + RJ45

Uncategorized Comments Off

Nov 022020

We’re proud to use genuine Neutrik connectors.

Since lower-cost DMX equipment often uses either XLR3 or RJ45 connections, we’re pleased to release a version of the DMX Engine which supports both types of cable with zero adapters.

The RJ45 output follows the standard ‘568-B’ wiring scheme, where brown / brown white are tied to ground and orange / orange white contain the data signals.

As always, the pinout for the XLR3 connector is 1 = GND, 2 = D-, 3 = D+. same as the USITT standard that’s been around for nearly 30 years now.

Each output is driven by it’s own set of circuitry, meaning that up to 32 devices may be daisy-chained from each output if required. Be sure to terminate your DMX lines at the far end of the chain, otherwise the intermittent gremlins get in.

Grab yours in the online store today. We’re working to add this version to our Amazon marketplace, and send stock to international distributors as well. Thanks!

Adding DMX Scene Recall to a Dolby DS220 Media Server

Uncategorized Comments Off

Jun 102019

DecaBox mounted to the wall like a glowing bat in the night.

From time to time, on the other end of a phone call is a variation of a problem we’ve not come across before. Over the years, our gear has integrated well with equipment from AMX, Crestron, Control4, Lutron, Savant, and many others. This was the first time we’d officially been asked to help with a Dolby-based platform.

In short, this group needed to record a handful of DMX scene presets and recall them using their existing theatre automation system. Though the stock DMX record / playback firmware we shipped worked perfectly, the installed Chauvet LED fixtures downstream weren’t able to handle full-speed DMX, an issue we solved clear back in 2011. (For the curious, that story is described here.)

It took just a few minutes to pull the ‘slow speed’ DMX output routines from our library and recompile the DecaBox firmware. Fortunately, the system updates easily in the field via USB; the installation has worked perfectly ever since.

From the customer:

Our venue features a relatively old DMX network–and a scene recall system that is somewhat of a relic. When tasked with finding a way for our Dolby DSS220 Media Server to trigger lighting changes during film screenings, interfacing with that system’s contact closure system was out of the picture given the tight time frame. After contacting ESINC, it sounded like the Decabox was the easiest way to go. The scene recording procedure was painless and quick, and the separate dmx “output” and “through” makes the system exceedingly simple to set up. In addition, the serial command set is easy to master as well.
At one point, I noticed some glitchiness with some of our Chauvet LED fixtures. John Chapman, having dealt with the exact problem in the past, quickly wrote us new firmware that would slow down the DMX output baud rate, which immediately solved the problem.
Thanks for the speedy turnaround, John!
Julian Amrine, Shoreline Community College Theatre

Our simple RS-232 scene recall syntax is shown here in the Dolby control panel.

Need something similar? Let us know.

Older Entries