This is the second in my series of posts looking at the engineering side of running a community radio station broadcasting on FM. For part one, look here.
This post will be focusing on telemetry, focusing on doing telemetry over IP and integrating bidirectional telemetry for radio metadata.
In our TX system we’ve got a fair few elements – a codec, a silence detector, a redundant playback device (a CF card MP3 player on our budget), a processor, a RDS encoder, a transmitter and a redundant power supply, plus an off-the-shelf (well, out-of-the-skip, actually) 1U rackmount computer. All of this is locked in a rack in a building we have limited physical access to outside working hours (normally – exceptions can be made in emergencies), and it’s not exactly in a convenient place to check by just wandering past it. Additionally, there are periods where the station’s staff are much reduced (over holidays). All in all this means we have to be able to monitor all of the equipment remotely somehow. It’s also convenient for us to be able to control things remotely, and for some things like the RDS encoder we need to be able to control it remotely nearly 24/7.
So, let’s go through what we’ve got, and look at what we have to control each element or monitor it.
- Sonifex’s PS-PLAY codec, which has a web interface and GPIOs plus a RS-232 control protocol
- Sonifex’s SD1 analog silence detector, which has GPIOs and analogue switches for control
- A simple CF card reader+MP3 decoder, which has GPIOs and an RS-232 port for control
- A BW Broadcast DSPXmini-FM SE FM processor, which has a proprietary UDP based IP control protocol and a proprietary RS-232 control protocol bundled with Windows software
- An Audessence RDS PRO-1 RDS encoder, which has an open RS-232 control protocol plus UECP support
- A Broadcast Warehouse TX-50 FM transmitter, which has an open RS-232 control protocol plus GPIO alarm outputs
- And last but not least, an APC Smart-UPS 1500 SC, which has an RS-232 control and monitoring protocol
In all but two cases, we’ve got a serial port with some form of control protocol on it. In several of these cases the correct thing to do to have remote control of these devices is not to buy them, and to get the IP-enabled versions instead. This is actually what we put in our original spec to our supplier, but somewhere down the line this got lost. For instance, the RDS PRO-1 has another model, the PRO-2, which has an ethernet port. The APC Smart-UPS isn’t an on-line version, but APC has SNMP-supporting on-line models equivalent to the 1500 SC.
Some stuff, though, is locked to GPIOs, such as the SD1. It’s a simple analog device and doesn’t have much of a brain for a serial interface or IP. You can get codecs which have audio switching and silence detection built in, but since most things have GPIO support, we’re probably just better off supporting GPIOs properly.
We also have one device, the DSPXmini-FM SE, which is just broken (if you ask me) in that it has no documented control protocol and is locked into a single GUI control application which requires a Windows PC. It does have a ‘trigger port’, which lets you pull one of 8 pins low to select one of 8 user-defined presets, which should just about do for the purpose of most stations. But there’s no feedback on the state of the unit, no alarm GPIOs, and no control interface you can talk to easily.
So, we can’t monitor the DSPX, just hope that it works. We can at least control it to a degree. Everything else we can monitor to an extent by querying their RS-232 interfaces or GPIOs. The main things we’re interested in are:
- APC – incoming power failure, so we can sort out a generator or at least notify the facility managers
- SD1 – Loss of audio from codec or redundant player (or both – if we lose audio altogether we’ve got dead air, which is an emergency that needs fixing)
- RDS – PI/PS/unit failure – The RDS unit must be encoding our station ID and PS at a minimum
- Processor – Audio/Pilot failure – The processor must be on-air and not clipping massively, and must be putting out the 19kHz stereo pilot tone
- TX – FM modulation failure – Obviously the FM transmitter needs to be happy and putting out the amount of power we want
- TX – Reflected power – If we have too much reflected power we may need to turn down the forward power
We ideally want to be able to monitor every parameter on all these devices, though, to permit closer inspection to diagnose fault causes before a visit to the TX site. So now we need to think about how to get all this data out.
Any serial port is actually easily turned into a TCP/IP port via the computer we have in the rack – this and a USB to serial device lets us plug in as many serial connections as we need, and the ser2net daemon for Linux lets us convert these to TCP/IP sessions. We can then telnet into the serial port on a device, which is very convenient. We can then control or monitor devices via simple scripts using telnet libraries in your favourite programming language – we’re using Ruby at Insanity for most things so I stuck with it when writing our device controllers.
Here’s a sample script showing how we can easily set the date and time on an RDS encoder attached via ser2net.
// ]]>
And this script shows how we can easily glue in outside infrastructure and information, in this case just page-scraping a website, to put things like the current show name into the RDS metadata.
// ]]>
So this technique is very flexible as it means we can easily remotely access the devices. We can do monitoring in the same way – if we can’t query the device we know something’s wrong, and we can query and monitor parameters via simple scripts, too, exposing hardware devices via Nagios compatible plugins to be queried via NRPE to integrate with our station monitoring system.
The other thing we want to be able to query and control are GPIOs. To achieve this we’re using an inexpensive microcontroller development board, the Arduino Mega, which provides us with over 50 TTL inputs and outputs which we can interface with custom hardware like relays and optoisolators. We can program the device in C, and communicate with it via a serial connection. This should give us an easily usable interface for monitoring device GPIOs, and allow us a degree of control over the otherwise opaque processor. Another option is the Nanode, an Arduino with fewer I/O ports but integrated ethernet. This provides only 6 ports of GPIO but this is sufficient for some tasks like single device monitoring, and we’ll be using one to add IP monitoring capability to an AM transmitter in the future. Once we’ve gotten everything on this front written, installed and tested, I’ll publish circuit diagrams and code to demonstrate how we’re doing it.
In the third instalment of this series I’ll be looking at RDS metadata.