So when I moved in to my current university digs, the previous tenants had left a few things behind. Notably, they’d had Sky. So we had a Sky box in the living room and a dish on the wall. In the UK, if you want fast internet these days, you need Virgin Media. VM gives you cable TV in the bundle, so I didn’t want to pay for Sky. But Freesat’s got some nice stuff on it, including BBC HD and that sort of thing. So how about we get ourselves some free TV?

Now, Sky uses the same satellite for the UK as a lot of Freesat stuff. So ignore the dish- all you need is to leave that bit alone, and make sure that you’ve got a cable from the dish LNB to somewhere you can put your PC. Where it’s pointed is probably 28.2 East, which has a bunch of appropriate satellites.

What you then need is a capture card. DVB-S is the standard for satellite, though DVB-S2 is used for some HD encoding (specifically, BBC HD is now on DVB-S2). DVB-T is for terrestrial stuff, and comes in on coax from a standard TV aerial – you can get combo cards, which will let you pull down extra stuff if you’ve got the coax feed. Stuff from your LNB typically comes on F-type cables/connectors, down 75 ohm cable. I have yet to find a decent UK supplier for patch or extension leads – if you know one, let me know.

The LinuxTV wiki maintains a huge list of hardware compatibility with Linux and capture cards, so check there before you go buy anything. I got a Compro S350 card, which works great for DVB-S – I’ve also ordered a Technisat S2 HD card, which should do DVB-S2, and I’m going to look out for a DVB-T card.

Now, we need to tie all this together next. So we need some software and a PC. The PC wants to be a decent spec – I’m using a Pentium 4 box with 768MB of RAM as my server, which is on the low end of things. A faster machine would be better, obviously, but it’s all I have to hand. I stuck a decent (GeForce 6600) graphics card in there, too. Fast CPU is the priority, really- we’re talking high definition decoding, encoding, transcoding and playback. If you’re on a budget, look into Intel quad-core chips (Q6600s, that sort of thing). Intel is the way to go wherever possible. If you’re doing this properly, high-end i7 would be my choice- that or a Xeon or similar. 6-12 core chips would be just the ticket. High-end (newer 8800 series and above) nVidia cards support VPDAU, which lets you offload video decoding and processing to the GPU.

The software to use is MythTV. I’m using a standard Ubuntu 10.04/11.04 (‘Classic’ mode on 11.04) install, and then installing MythTV atop that. On the server, just install the mythtv, mythtv-themes, xmltv and mythweb packages. On any other clients you can install the mythtv-frontend package, and optionally the mythtv-themes package. The client-server model of MythTV means you can combine backends and frontends to build your system. It’s crazy powerful in terms of flexibility. But the short story is, you can have a very nice TV system in very little configuration.

See this excellent guide for more information on how to set up MythTV with Freesat. Basically you just need to tune it in to the right satellite and set up the input properly so it’ll get the channel list. MythTV’s config options take some getting used to, but it’s eminently doable. And once you’ve gotten everything talking, you have a -very- capable system.

So, well done to the MythTV team. One hell of a package, that’s for sure. And Linux DVRs are now in my mind far, far more capable than any other potential choice for DVRs. With MythWeb, I essentially have my own private little iPlayer- but for every single bit of Freesat’s programming. What’s not to like?

So, what’s the best way to approach all this? With a new set of equipment to monitor, and a lot of old equipment still unmonitored (our desk’s GPIO and the AM transmission gear, for instance), hardware GPIO lines are order of the day. Mostly, this can be done with relays, pull-up resistors, optoisolators and a steady hand with a soldering iron (bolted onto an Arduino – see my last post). This is all well and good – but now you need to get that into a sensible format, record it, log it, and take action depending on the state (emails, indicators in the studio, etc). Which is where Nagios comes in.

Nagios is scarily flexible. It’s also extremely lightweight for small setups, and very easy to configure, with excellent documentation. And since it’s widely used in larger IT outfits, there’s an infinitude of addons, plugins, and so on to expand it. It’s at heart a monitoring program, with support for active checks (where Nagios polls the host or service), and passive checks (where the host/service reports in to Nagios itself). Once you’ve gotten things inside Nagios you can use a flexible set of rules for notifications, and use some of the many addons (we use check_mk’s livestatus) to get data out into other programs. We use CoffeeSaint on dashboards to provide single heads-up displays (with camera displays combined), and we’ll soon have Nagios integrated into the Insanity website’s admin backend so that staff can see a general overview of the system alongside all the other vital information like listening figures and cameras from wherever they are in the world.

At the moment because we’re poor, we don’t have ethernet shields for our Arduinos, so we have an Arduino Mega and an Arduino doing two things- driving a matrix LED display, and monitoring our silence detector. The latter is done by the Mega, which will later be expanded with ethernet and various boards to break out the DB25/DB15/DB9 connectors from the mixing desk into Arduino-compatible levels. For now though it’s just hooked up on USB. The Mega also drives a set of Bliptronics LED RGB modules- these are currently spread along the top of the mixing desk in the studio where presenters can see it.

The Mega is set up to simply watch the two inputs of the silence detector and their alarm states, and to display one of four messages describing that state to serial over USB, where it’s picked up by a small Ruby script, which then sends a NSCA (Nagios Status Check Acceptor) packet to the NSCA daemon on the monitoring box. This packet contains the information about the silence detector in a format that maps to the host and services described in Nagios. This means we get very rapid updates on the silence detector compared to active monitoring. Even more rapid is the LED strip, which is controlled wholly in C. If the station’s output gets switched to the backup source because the silence detector thinks the studio is too quiet, then the strip goes red (normally green) – and if a presenter is in there, he/she now knows that there’s a problem, they’re no longer going out on air, and they can either work out the problem by themselves (previously the staff wouldn’t know that this had even happened without going out and listening to the radio) or call for support.

It’s one thing to have standards, and another thing entirely to monitor your performance and hold yourself to them; and when there’s a problem with your metrics, then you can fix it. We’ve dramatically improved the actual quality of broadcast radio that Insanity puts out in the last year; partly it’s a human change, we’ve had some great presenters join us this year and a very determined board, but there’s an element of technical change and a lot of instant feedback for presenters to help them; and this has really helped people spot problems where previously they wouldn’t even have known they were there.

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.