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

 Case Study, DMX, RS232  Comments Off on The Most Bizarre DMX to Lutron Bridge Firmware We’ve Ever Shipped
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:

DecaBox DMX to Acuity Systems nLight

 Case Study, DMX, RS232  Comments Off on DecaBox DMX to Acuity Systems nLight
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.

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.

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

DMX Control of a Daktronics Venus 7000 Video Controller

 Case Study, DMX, RS232  Comments Off on DMX Control of a Daktronics Venus 7000 Video Controller
Feb 142017
 

Canucks Arena & Video Ribbon. Photo from GLOBETREKIMAGES / 604 NOW FLICKR POOL

This was a fun one.  Turns out, the Daktronics Venus 7000 video controller can be trained to play content based on incoming RS-232 messages.  And, the trusty DecaBox can receive DMX and output all manner of RS-232 content.  When the dust settled, we ended up shipping a somewhat-modified version of our DMX to ASCII firmware.

Here’s the story, straight from the customer:

Recently, I was given this task of creating a lighting board to Daktronics Venus7000 lighting trigger and started out by looking at my relevant device ‘gozintas and gozoutas’ (ins and outs). 

I do not dabble too much in lighting control technology although I knew we are using a Grand MA on PC. I do provide in-house second tier support on our Daktronics LED systems and servers so I also knew that I needed to create some simple ASCII data strings on an RS-232 serial port. 

After asking the Google, I was able to find some articles about converting DMX to serial. This is the link that came up: http://response-box.com/gear/decabox-protocol-bridge-overview/ and this Decabox looked like the exact piece of ‘glue’ needed to convert lighting transitions to a Daktronics triggers. 

I took a bit of a chance and purchased the Decabox, (John Chapman at Engineering Solutions Inc. was also very helpful in that he returned my call and assisted me in determining a data scheme). I went back a to Daktronics Engineering and they were good with John’s proposed data string.  

Shortly after submitting my order, I received the Decabox which John had  pre-programmed and we were ready to test. We were very quickly able to see the appropriate serial data in our Dak server room and soon after got Dak to remotely configure the serial listen port. 

Success! 

This has solved an ongoing issue with playback synchronization of Daktronics content playback, and our house lighting.  We now have consistent and repeatable triggers during our game start opening sequences, whereas before we relied on an intercom countdown to mouse click (which was not very tight!). 

I would not only recommend this device, but also have kudos for John Chapman’s support and timely follow ups to our questions. 

GS | Broadcast Technician
Canucks Sports & Entertainment | February 2017

Need something similar? Contact us and let’s get started.

 

 Posted by at 11:07 pm