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.