Arduinos and Telemetry for Radio

So, those of you who come here expecting EVE Online content – well, this blog started out as a personal blog and that’s all it ever has been. I’ve moved on, so here’s stuff on what I’ve moved on _to_.

Recently I’ve been building equipment for Insanity Radio, the student radio station where I currently serve as Head of Technology. We’re a student radio station and this poses lots of problems to successful technology implementation:

  • Cost – our budget is very small, and mostly goes on licensing fees to PRS/PPL/MCPS.
  • Reliability – the station as a whole has to be able to operate unattended for months at a time over the summer holidays
  • Ease of operation – the station is typically only crewed in the live segments of our programming by the presenters doing their show. We have no full-time or on-shift producers or crew
  • Ease of expandability, upgrades and maintenance – the technical staff of the station changes on a year-by-year basis

Bearing all these in mind we have to be careful when implementing new tech or building new systems that we don’t make anything that the technical staff after us won’t be able to handle, and which (where relevant) can be operated by an unskilled user.

We’ve recently been granted a FM license by Ofcom, and are currently waiting on lots of paperwork and things to be done so we can get the ball rolling on that particular project – namely, setting up a complete FM STL and new transmission system. Of course, the transmission system is something we’re getting outside broadcast engineers with a lot more experience than us to do (namely Radica, who did our AM mast many years ago). But facets of the system- namely, the STL (Studio-Transmitter Link) and telemetry (allowing us to, via remote operation pins and monitoring outputs on equipment, remotely monitor the status of equipment and control equipment where needed) can be done without needing to splash out on consultants. In fact, most of the solutions you can buy off-the-shelf for transmission site telemetry are quite restrictive, using proprietary protocols that only work with the supplier’s software. In my mind this completely doesn’t fit the bill for a telemetry system. What you basically need is an open, non-proprietary protocol that you can use to query devices.

Is this sounding familiar? It should be – datacenters got this problem solved years ago. And the networking industry came up with SNMP. It’s extensively used on switches but also on UPSes, environmental monitoring gear, and more.

SNMP is the Simple Network Management Protocol and it supports a very flexible schema for remotely monitoring equipment. And somebody’s rather handily built a library to run on an Arduino microprocessor platform with an Ethernet shield for the TCP/IP component.

Now, going back to the issue of cost – £30 for the Arduino Mega and £40 for the Ethernet shield brings us to £70 per node. But now to interface with all that gear we need pull-up resistors (trivial), relays (not so much – £4 each for DIL mounting reed relays) and optoisolators. All of which brings our total cost closer to the £100 mark once we’ve bought all this and soldered it up on to a breadboard and interfaced it all. In theory. I’m currently working on an Arduino Shield to provide the relay and optoisolator etc outputs on screw terminals, and I’m looking to get the PCBs made by BatchPCB.

I have yet to actually build one of these nodes but plan to do so soon as a proof of concept. We have roughly 125 pins of I/O from our mixing console to interface (mostly on 25 and 15 pin d-subminiature connectors), 15 pins of I/O on our silence detector, 15 pins of I/O on the AM transmitter, and soon we will have an entire remote transmission site to monitor. The first one of these devices will be a proof of concept, and hopefully will pave the way to future development of this sort of technology.

Of course, the huge benefit of SNMP is that it can be tied into anything. Let’s go back to the reliability and ease of operation points in the list above – we’re now using Nagios for monitoring all of the station’s IT resources (Not a small challenge in and of itself), and we’ll be expanding that to cover the STL and network itself. Now imagine we can bring hardware and environment into Nagios – now we have complete monitoring, end-to-end, from the studio playout computer being happy and running the radio playout program, all the way to the transmission site, all in one open and extensible monitoring system. No proprietary systems, no vendor lock-in, nothing – just a flexible and reliable system that many people are already familiar with.

There’s another huge benefit of keeping things flexible, of course. We’ve recently installed a set of RGB LED lights in the studio, as well as a LED matrix display. These are driven by a pair of Arduinos hooked up to serial over USB on our monitoring PC. We can have the monitoring software feed presenters information, or set the lights to indicate problems. This has already yielded fruit – we have the silence detector alarms hooked up so the lights go red when presenters are being so quiet (ie getting their levels wrong) that the studio fails over to a backup playout system. This quick visual feedback has provided presenters with real instant feedback on their show and lets them correct a problem, rather than the issue going unnoticed. In the world of student radio that means you’ve now saved several phone calls and potentially large swathes of missing content, not to mention made presenters happier because they now get positive feedback when everything’s going well! Lots of small steps like this can lead to big changes in the professionalism and quality of shows and allows presenters to be more daring and experimental in their shows, meaning better and more interesting shows and content. And if that’s not a huge success for a few simple additions, I don’t know what is.

Arduino Strobe Controller

So, we decided we wanted to use some strobes at the theatre this week. Unfortunately, we found them in a skip. They work fine, but there’s no remote control.

While the manufacturer (ANYtronics) does indeed provide their own controller, we wanted one in a hurry, so I put together a box which does the job quite nicely when all’s said and done.

At present it does:

  • Variable speed with preview
  • Keyswitch on/off
  • Momentary SPST trigger

It’s single-output for now. Considering the strobes have master/slave and can daisychain just fine, I didn’t see much point in doing this, at least for the initial version. The SPST momentary switch and keyswitch were both what I happened to have lying around in my box ‘o electronics stuff, and could easily be swapped for another solution. The SPST could be merged onto a switching rotary pot if you wanted to mimic the control on the back of the strobe precisely, but that wasn’t what I was aiming for- I wanted something that could be easily frobbed and adjusted in advance without having to guess at frequencies. That’s done via the three LEDs- green for power/system on (turns on with keyswitch), red for firing, and the third yellow LED pulsing exactly as the strobe would.

The whole job is fairly simple- it’s all active low TTL circuitry, using an Arduino Diecimila board as the brain. The Arduino manages the pulses, LED logic and switching logic.

The only complex bit of this came with the interfacing to the strobe.

The strobe’s interface is on a mono jack lead. After finding a socket, I needed to work out the pulse length and minimum interval. Given the specs list a 16FPS maximum, I settled on 64ms delay between pulses as a minimum. The pulse length I guessed at from the master-slave interface, again listed in the docs. Fortunately it seems the external trigger works on this too, so that ended up being the delay of choice therin. Code follows after the break.

Continue reading Arduino Strobe Controller