This post is the first in a series of posts I’m going to do covering some of the engineering aspects of setting up a Community FM Radio station in the UK, and the lessons I and others learned while setting up the system.
First a bit of background. The station I helped set up, Insanity Radio, will be launching its FM transmissions in the coming weeks, and is a station run and operated entirely by students at Royal Holloway, University of London. The station started back in the 90s broadcasting on FM using a low-power rented transmitter, licensed under Restricted Service Licenses (RSLs) which only allowed for a week or two of broadcasting at a time. The station eventually moved to full-time AM operation, under a Low Power AM license. Back in 2006, a previous manager applied for a license for Community Radio, to permit FM broadcasting on a permanent basis, and in 2009 that license was awarded to Insanity by Ofcom, the UK’s radio regulatory body.
Our license was awarded for a 25 watt EIRP mast to be installed on campus. So in 2009/2010 we got the ball rolling with planning.The license came with a set of funding information, which went on to define our operating budget (dual-funding stuff came into this, too). The budget, however, didn’t cover a studio transmitter link, because nobody involved with the application had considered we needed one. We figured out we needed one pretty rapidly after deciding on a location for the mast in conjunction with the fine people over at Radica, our RF people. The mast was to go up on a building the other side of campus, and we determined the best option would be to use an IP codec.
Coming from an AM operational background, FM introduces some complexities which have to be considered. Processors in the AM world typically deal with analogue or AES audio all the way to the transmitter. FM, however, introduces MPX connectors to the game. To understand why it’s helpful to understand what FM modulation looks like.
In AM, we (typically) just modulate a single carrier and that’s our audio. It’s a very simple modulation and works well, but is susceptible to interference. In FM, for stereo (which we decided to transmit using), we actually modulate a lot of different bits of carrier, or subcarrier. A 19kHz pilot tone (indicating the presence of stereo audio), a double-sideband suppressed carrier transmission to carry the stereo audio data, and RDS data further up the spectrum. The mono audio is simple baseband audio. The stereo audio is actually not carried as two independent channels, but instead is actually L-R (with mono being L+R). This is more efficient, effectively providing mono and stereo in the space of one stereo channel. Mono is thus available even on stereo transmissions when signal quality is low enough to merit its usage.
However, to encode all this requires multiple boxes (typically) and their interconnects are on MPX, a 75-ohm BNC format which carries the raw modulation data.
The system we’re running looks a little like this – audio from PC into processor, processor MPX into RDS encoder, RDS MPX (which now has RDS data in it) into the transmitter, transmitter to antenna.
The main considerations for engineering all of this are how you get the audio to the TX site and how you manage and monitor everything in the TX site.
Getting audio there is pretty simple these days what with IP networks being as reliable and as widespread as they are, but things can get very expensive if you go for codec hardware. Entry-level codecs will set you back about £1000 a pair, and the cheap pair of Sonifex PS-PLAY and PS-SEND units we got were full of issues and wouldn’t pass PCM audio (it’s a known issue, and a firmware fix will be available ‘soon’). Professional codecs will cost more like £5k for a pair. Or you can do what we’ve done while we wait for BarixSonifex to fix their products and set up two computers to pass audio around. There are various tools like NetJACK which let you pass around PCM audio. We went for a lossy solution, using the CELT low-latency codec, implemented in OpenOB, a system I’d written for doing outside broadcasts some time ago.
The processor has an IP interface, and the RDS encoder is available with one (but we ended up with the serial-only version, annoyingly). The codec is also IP configurable. There’s a backup power supply (and APC Smart-UPS 1500) which has a serial interface. Then there’s the processor’s trigger interface for switching presets – 8 GPIOs – and the transmitter – serial, plus 3 GPIO alarms. All in all there’s a lot to keep an eye on and lots to monitor. I’ll be going into more detail on how to manage all this lot in part 2.