Controlling a Microframe Ethernet Visual-Pager® LED Display from Medialon Manager for the Gravesend Inn Queue Line

IMG_20190719_140307.jpg

Our Gravesend Inn haunted hotel has been getting about 6,000 visitors per year for the last few years, and the queue line has been becoming unmanageable. To alleviate this, our house management staff started taking names and sending people up to out second floor cafeteria area; this too became unwieldy. So I suggested a “take a number” system, and found the Microframe 3-Digit Ethernet Visual-Pager® Display. We got two model D4500 displays; here they are in action.

I spec’d out the units over the winter, and then one of my senior students, BaiLin He, did the original work on getting the unit to respond over ethernet from Medialon. I’ve found that every time I add something like this, it takes many hours of figuring out and inevitably contacting the manufacturer to straighten something out. In this case, the design engineer at Microframe was extremely helpful and very responsive; their protocol document is here.

Here’s our notes.

Initial Configuration

Set the IP address

  • The IP functionality of the displays is provided to the Microframe units by an add-on board made by WIZnet. So to set the IP address, use the java “WIZnet Configuration Tool”, which is labelled “D4600 Ethernet Software” on the microframe website here: https://www.microframecorp.com/download-software

wiznet2.PNG

To use:

  • Click “Search” to find the device on the network

  • To save the setting click “Setting” then type the password 

  • Default Password: WIZnet

Set the Device Parameters

There are several parameters in the unit that you might want to set. These settings are stored in EEPROM in the unit.  To configure, use the “WIFI_Display” software which is listed on the Microframe website as “”WiFi Visual Display Desktop Paging Software”

parameters.PNG

“Rollover”, which is how many numbers will loop on the display. We only want to show a single number at a time so we set this to zero. “Auto Delete” sets how many minutes the display will wait when displaying a number before blanking out. Chime volume is of course sets the loudness of the chime and the pull down list allows you to set for single or double chime, or turn the chime off.

NOTE: I discovered that this software is very erratic for parameter setting—it only works some times and then other times not at all with no indication.  It seems that it is most likely to work if you remove any existing units, and then search for new units and click on the unit you want to configure (but this doesn’t work 100% of the time).  In order to see when it’s working, I ran Wireshark with this filter to verify that commands were actually being sent. tcp.payload and ! (tcp.payload contains “GLA”)   This filters out the get lists commands (GLA) that the software constantly sends out and the other TCP housekeeping.

Controlling the Unit 

The unit defaults to TCP Server, port 9107.  The unit is designed to store a list of numbers so to display a number you send an “add number” command.  All commands have a 2 byte validation pin (we use the default of !00 !00 and end with a terminator of !00   (! = hex byte indicator in Medialon)

  • To add number “88”: !00!00!0c"S+ 88!00 

  • To clear the list and blank the display: !00!00OCA!00 

Note: Even with the rollover set to zero, I had a lot of seemingly erratic problems with both units where the units would freeze or blank out and stop responding when running overnight (I always do extensive durability testing on any system we add to the Gravesend Inn).  It turns out that the internal list (20 entries if I remember right) needs to be cleared. So now I add a Clear All command each time I send a number out and this seems to be very solid.

Test Program 

Adding these kinds of systems to a large piece of working code for the Gravesend Inn, I always start with a small test program, then import that into the main system. You can download the test program here, and the Low Level Communicator driver file here.

Mainscreen.PNG
EditScreen.PNG
DiagnosticsScreen3.PNG

Circus Knie's Very Cool Indoor Drones by Verity Studios

Screen grab from Circus Knie youtube video

Screen grab from Circus Knie youtube video

I’ve been following the use of drones in live shows since I saw the first Intel drone show at Disney in 2016. When they can be used in a large scale outdoors (which always has airspace issues) the drones have been interesting, but most indoor usage I’ve seen hasn’t been that impressive, because it’s been in a two dimensional proscenium frame.

But I’m a big circus fan, but Todd Robbins posted on FB a video from Swiss Circus Knie that features some very cool drone usage (starting around 1:15:):

The cool thing (at least watching on video) for me is not only the circus element of this usage but also because it fully exploits the 3D nature of the drones and is performed in the round. It turns out the show uses 32 drones from Swiss company Verity, who has done some very cool stuff. I found a couple backstage videos:

I won’t be able to get to Switzerland this year to see this but if anyone does please report back!

An Audio Networking Update After Infocomm 2019: Audinate's Dante and AVB/TSN/Milan

Sunset over the excellent Hillstone restaurant In Orlando—Nothing Network Related Here

Sunset over the excellent Hillstone restaurant In Orlando—Nothing Network Related Here

It's become an annual tradition-since 2009 I've been writing about networking from a live sound perspective after catching up from Infocomm. (Note: In this overly jargon-filled post I'm assuming you're familiar with the A/V networking landscape; if not, much of the terminology I use here was defined in previous write ups). You can see last year's entry here, and the whole series here. In short, I was an early and ardent supporter of AVB (now called TSN (now called Milan?)), and then Audinate came out with Dante which really took over a huge part of the audio networking market, and now has hundreds of licencees. Last year at Infocomm, a number of key AVB live sound manufacturers announced the formation of Milan, meant to clean up some of the under defined things in AVB and make it more useful.

Last year, I wrote: “ … I would describe the state of the A/V networking world to be pretty much the same as last year, with some interesting developments on the horizon. The lion's share of the products on at the show running audio over ethernet are doing so with Audinate's Dante; a few (important) companies are running AVB. “ I could write that sentence today adding that we seem (in the live sound world) for the near future to be heading further into a two-network world, with a convenient and practical dividing line: the mixer/speaker system boundary.

All the partners currently featured on the Milan website are speaker manufacturers:

milanpartners.png

So the leaders include include Adamson, d&b, L’Acoustics, Meyer, and RCF, and Avid is on the list. There were rumors at the show that there would soon be a Milan console, so I would put 2 and 2 together and guess that that will happen (of course Avid also makes an option card with Dante). But if we’ve got to have two networks in our industry, this is not a bad break point: Dante currently owns the console, stage box, mics, processors, etc; Milan/AVB will own the high end speaker space.

Three things still bother me about the Milan effort. First, I don’t know what it is supposed to be called any more. AVB? TSN? Milan? That’s a minor thing that they can fix. Second, as far as I can tell, there still will be no unified patch screen. As I wrote last year, “nothing in the existing standard offers the user anything like the plug and play patching convenience we already have today with Dante (of course I've written a lot about that already). Even in Milan, from what I understand, the way the patching will done--which is what the users actually interact with--is still left up to individual manufacturers (or maybe a third party?) to handle. For competitive reasons there's not really much incentive for clean, unified plug and play multi-manufacturer signal routing that is consistent for the user, and I doubt it will happen any time soon in AVB systems, if ever.“

And the answer I got about this at Infocomm is that there would be some open source solution that on which anyone can develop. That may be noble and flexible, but that does not necessarily lead to usability. I would be more impressed by the whole effort if the companies in Milan offered one single unified cross-platform patching solution. And this brings me to the third thing: these brilliant engineers (some of whom are friends of mine) still don’t seem to get that they are, in the end, developing their products for end users. One of the greatest things about Dante—and, I would argue, what most users actually think Dante actually is—is the unified patch screen offered by Dante Controller. This patch software is the same no matter what Dante enabled product you are patching. If Meyer has a patch software and L’Acoustics has another and d&b has another then this just becomes yet another quagmire of multiple interfaces. Can we make it work? Sure. Is that really better for the end user? I don’t think so. I’ve spent too much time already on job sites with a bunch of people standing around the laptop trying to get things patched and this situation won’t make that any easier.

And related to this is that in all the Milan materials and presentation they continue to act as if there aren’t already tens of thousands of Dante products in the world. In slide after slide, the Milan presentation outlined the functionality we already have today with Dante, but it was presented as if Milan was some radical new innovation, rather than an incremental improvement on a nearly 10 year old networking standard that still requires special functionality in ethernet switches. They also act as if configuring a Dante system is some monumental task needing massive amounts of IT knowledge, which just isn’t true for the vast majority of our applications. This all feels a bit disingenuous to me.

I get it—if these manufacturers don’t want to be tied to a third party manufacturer like Audinate, that’s fine. They view Dante as some transitional bump along the way to AVB networking nirvana. Until that happens (if ever) I wish they wouldn’t act like the competing technology doesn’t exist. Those of us out here on the front lines are the ones who are going to be cobbling together products from a bunch of different manufacturers; we can do that easily today with Dante licencees.

At my school, we have two Yamaha CL5’s; due to our unending budget crisis, those consoles will likely be in place until they die. Given my experience with Yamaha products, that’s going to be 15-20 years; that means we are using Dante for the next 15-20 years. So I asked at the Milan presentation, “Hey my school owns a Yamaha CL-5, if I buy your speakers how should I get signal to your processor?” The answer: Yamaha should support Milan (of course they could make an expansion card but with their structural commitment to Dante even that seems unlikely to me) or I’d have to use some sort of unspecified converter box.

Meanwhile, Audinate continues on (and speaking with their outgoing President, he told me that they have 60 (!) full time developers) and showed product of what they were demoing in concept last year—video over a gigabit Dante network, synced tightly with audio on the same network:

video.jpg

This is really cool.

In other networking news, Luminex was showing their new Milan capable switches which look pretty cool:

IMG_20190613_115356.jpg

I have some random photos of other cool stuff I saw at the show here and a writeup of our time code Geekout here.

So that’s about it for this year. Infocomm continues to be the go-to show for A/V, we’ll see how things continue to develop for next year!

controlgeek.net/Timberspring Orlando 2019 Time Code Geekout Wrapup!

JH-20190613-DSC_7295.jpg

After taking 2018 off, Jim Janninck’s and my geekout during Infocomm was back and better than ever for 2019! (Coverage of past geekouts here). This year, Jim and I decided—instead of doing the traditional case studies we’ve done for many years—to address the issue of time code and the way it’s being used these days on live shows, which seems to be in the show control zeitgeist these days. Alcorn McBride generously offered us their brand new building with a great conference room and open tiki bar (!), and Medialon (which announced at the show its sale from Barco to a new company allied with 7th sense) helped out sponsoring some great food. Having competitors collaborate like this really exemplifies the spirit of the event—we’re all friends and geeks in the end.

First, a bit of background on time code to set the stage. Here’s a couple paragraphs from my book on time code’s background; I also have a free video on the subject here.:

Time code is one of the most widely used synchronization tools in show control, since it is easy to use, allows precise synchronization between multiple systems, accurate repeatability, and makes for straightforward programming of time-based systems. Society of Motion Picture and Television Engineers Time Code (SMPTE TC) was created first, and then MIDI Time Code (MTC) was developed to transport SMPTE time code over a MIDI link. While SMPTE (pronounced “sim-tee”) TC is encoded using analog audio frequencies and MTC is digital, they share many common aspects, so we will cover the basics of time code first, and then get into specifics of each type. As of this writing, the latest version of the SMPTE standard is ST 12-1:2014 - Time and Control Code. MTC was first released by the MIDI Manufacturer’s Association (MMA) in 1986, and consolidated into the overall, unified MIDI standards document in 1996.

TIME CODE BASICS

TC has its origins in videotape editing, so it breaks time down into hours, minutes, seconds, and frames; up to 24 hours worth of frames can be encoded, although it’s important to remember that the TC signal is its own clock, and does not necessarily match real time of day. One discrete TC “address” exists for every frame on an encoded media—a typical address might be 05:20:31:18, or five hours, 20 minutes, 31 seconds, and 18 frames. Time code can be recorded on a wide variety of media and systems, and TC is absolute: If time code for a show starts at 08:00:00:00 and the tape is fast forwarded to 08:18:01:15, the system can quickly determine that this frame is 18 minutes, 1 seconds, and 15 frames from the beginning of the show.

So time code was developed by the film and video industry decades ago, and we used it originally for its intended purpose—synchronizing linear media like audio and video tapes. However, over the years and with the development of powerful digital playback systems with accurate internal clocks, that linear synchronization use case has become less necessary for us, while another application has arisen: triggering events based on a show clock. These events might be lighting cues, pyro, sound cues, motion control—pretty much anything on a show. In addition, since these days we are often running ethernet to connect our systems, we less and less want to run old school XLR’s or MIDI cables to distribute SMPTE or MIDI Time Code. But since so much show gear has a SMPTE LTC input these days we’re often running a network cable for control and an XLR for time code. And time code or a show clock in some form is used on a huge number of shows these days.

So in many ways, we’re at a bit of a crossroads in our industry, with so many shows needing a show clock, but so many using a very old technology that works very well but is distributed over a very inconvenient format And the video production industry too has been affected by the same forces; they now have a bewildering array of frame rates of media created on a huge variety of devices. But in their world, the desire for a “digital birth certificate” is strong, while the day to day show clock requirements of our world aren’t as much of an issue. SMPTE has been assessing the market for several years, and centering development under a banner of “TLX”; they have a webcast explaining that effort here.

So all of this led to a very spirited discussion, and—thanks to Steve Milner of the great Youtube channel and podcast DC Sound Op—you can watch or listen to our entire discussion here!

It was a fascinating and very geeky discussion, but I came away with several useful takeaways.

Transmitting SMPTE Time Code Signals over a Network Today

Several approaches to send LTC currently in use were discussed:

  • QSys: It’s possible to send LTC using UDP and ASCII inside a QSC QSys network.

  • RTP MIDI: It’s also possible to send MTC over a network using RTP over systems like Medialon or KISS Box.

  • Beckhoff: It’s possible to convert LTC to RS232 and send it over a Beckhoff network.

  • OSC: Apparently there is a way to send time code over OSC

July 5, 2019: Update: From Mitch, Director of Technology at Smart Monkeys, describing what they are doing:

It’s very simple: we send out unicast/broadcast UDP packets formatted like “hh:mm:ss/ff0x0d” and then the receiver just takes it and tries to skew to it. We’ve had sources be an LTC->Serial(http://www.adrielec.com/aec-ubox.htm)->Moxa, Q-SYS, and Medialon. Destinations have been Q-SYS and Medialon. We’ve had no real problem with accuracy as the networks are usually <3ms latency.

While these approaches are good work arounds with the existing technologies, to me, none of these approaches are all that elegant, and ideally a simple multi-castable network system would be a lot more desirable.

JH-20190613-DSC_7265.jpg

Synchronization

One big part of the session was a fascinating discussion about the differences between frame rate/show clock and underlying sync accuracy. For a variety of applications we need to maintain timing precision across the network; most seemed to think that that PTP does that pretty well. So that sets the underlying timing accuracy of the systems, but we really didn’t seem to come to any consensus on how to resolve that underlying clock to a show cue clock, frame rate, etc. Of course using PTP and NTP it would be possible to schedule cues dynamically and transmit them with some sort of offset from time of day clock, but that’s a pretty sophisticated approach that, in my opinion, would be hard to standardize and wouldn’t be really desirable for dynamically changing live shows. So there’s definitely something to explore in this issue, but right now it feels so broad that I don’t even know how to put my finger on it. It might be a good topic for a future geekout.

Wish List For a Network Time Code Standard

Towards the end of the session, I tried to get the consensus of the group to create a “wish list” for a network time code standard for live show applications. What interesting, is that—unlike some other older protocols (like DMX)—the frame information sent over LTC is really fine for most of our applications today (we could probably argue about a frame rate) and doesn’t really need to be changed. All we need is a way to cleanly and easily transport the existing information over a network. We came up with this wish list (subject to my interpretation):

  • Base the system on Ethernet, IP, and UDP (this makes it layer 3 which is desirable)

  • Allow either multicast or broadcast—"reliability" in the IT sense (TCP) isn’t that important for our applications. A dropped frame will be overwritten quickly by the next one.

  • Use only simple and minimal overhead (don't include unnecessary check sums, etc)

  • Make the standard profile as lightweight as possible

  • I didn’t put this on the list that day, but it seemed to me that the consensus of the group was that the latency of closed ethernet is probably good enough accuracy for event triggering (I say that because no one really proposed anything like AVB/TSN), and underlying precision, if necessary, could be provided by PTP.

From my reading of the current SMPTE TLX effort, it seems they have been heading toward a much more complicated approach that we don’t really need, and that complexity would likely inhibit adoption in our market. So my prediction for the next few years is that we will continue to use a variety of Rube Goldberg, ad hoc approaches to distribute old-school SMPTE LTC via networks to XLR cables for the last meter, and we’ll hope that the new TLX will evolve to meet our purposes. If not, we might want to look at developing our own, simple standard for the future. The knowledge demonstrated by the attendees in the geekout room alone prove that we certainly have the expertise to do so.

So all in all it was a great session,. and thanks so much to Steve for capturing it and doing all the work needed to edit such a freewheeling session! And special thanks to Loren Barrows from Alcorn and Eric Cantrell from Medialon for their ongoing support.

Jim and I haven’t thought about what to do during Infocomm in Vegas next year—if you have a line on a meeting spot please let us know!

JH-20190613-DSC_7288.jpg