Quantcast
Channel: Talk Unafraid » rds
Viewing all articles
Browse latest Browse all 3

Engineering FM – Part 3

0
0

This is the third part of my series on engineering an FM install at a community radio station. This section will be looking mostly at metadata to be encoded in your FM transmission using the Radio Data System (RDS).

There’s a lot of metadata you can put out in your transmissions, even in the land of analog radio. While your total information carrying capacity is only around 1,200 bits per second, it’s still enough to provide listeners with loads of useful information, especially if you’re clever about what you encode.

First let’s have a think about how we actually encode this metadata into the signal. The Radio Data System, RDS, is a subcarrier 57kHz up from the base frequency (57kHz being the third harmonic of the 19kHz pilot tone used in FM stereo transmissions, leaving room for the stereo transmission above that pilot at the second harmonic with 4kHz lower sideband to spare). This means your RDS encoder typically is fed with a raw MPX signal and outputs MPX for the transmitter. Usually the encoder comes after the processor, if any. A combiner can also be used to achieve the same result. We’re using an Audessence RDS PRO-1 at Insanity which is working out very nicely and is a well-engineered, well-documented bit of kit.

Long story short, then, we’ve not got a lot of room or bandwidth to play with. Also limiting what we can do are the actual receivers. In-car receivers typically only have an 8-character display, but support other RDS features like TA/TP and AF. Desktop receivers typically have a scrolling display (I have a Pure ONE Classic as my general listening confidence receiver, which has a scrolling display for DAB/RDS messages) but don’t usually support the TA/TP flags. The result of this is that RDS has quite a tight specification, and you’ll have to make some sacrifices in how you present your information.

A quick rundown of the main RDS attributes we’re interested in as a community station, then:

  • PI – The programme identifier. This is unique to each station and never changes.
  • PS – The displayed name of the station, limited to 8 characters. Used for DPS (more on that later).
  • TP/TA – The TP flag indicates that the station regularly produces traffic reports. The TA flag is set when a report is being broadcast, allowing radios to automatically tune in for the duration of the report.
  • EON – Enhanced Other Networks, allowing ‘referral’ to other frequencies for traffic reports. Not too handy with CR, but potentially useful.
  • PTY – Programme Type. Used to indicate what sort of show is on at the current time.
  • CT – Clock Time. Allows you to provide an accurate (ish – limited to 100ms accuracy) clock time source for radios that support it.
  • RT – The interesting one, Radio Text, allowing arbitrary 64-character messages. Along with RT+, a tagging system for RT.

There’s a few other things like AF (Alternative Frequencies) which can be useful for larger stations but don’t have much application in typical CR installations.

So, some easy ones, then – PI and PS are set once, forget about it. A note on DPS or Dynamic PS – this is when you frequently update the content of the PS attribute to produce ‘scrolling’ displays. Don’t do it! It’s against the spec, illegal in some countries, and just plain stupid in any case as it can be distracting for drivers and annoying even for static listeners. Pick a shorter name instead, and keep it nice and simple – nothing fancy. This is what people are going to see when they’re listening to you, all the time.

TA/TP flags are also probably easy for community stations – off and off. The TP flag basically says “I may be putting out some reports sometime, keep checking back” to a receiver. TA actually forces TA/TP enabled receivers onto your station while it’s set, so make sure to be careful with this one. Some encoders have a “Don’t let me put out TA=1 for more than X minutes” option – I strongly recommend you set this to one minute or as low as it will go otherwise if you’re not planning on TA. This will at least make sure accidental activations are limited in impact.

The PTY field is rarely used in most receivers but is worth keeping up to date regardless. If your station has an EPG or other scheduling system you could ideally plug in metadata from that to this field. It’s a numeric code which refers to one of a number of types of content – pop music, varied, talk show, etc, defined in the RDS spec (though Wikipedia has a list).

The CT field is one you should aim to provide if you can do so reliably. Most RDS encoders contain a real-time clock circuit which will keep relatively good time but needs updating every month or so. At Insanity, I’ve always been careful to keep accurate time throughout the station – we run our own Network Time Protocol server (stratum-2) and all the computers synchronize to that server, keeping us within about 30ms of the GPS time signal at worst case. This is plenty accurate enough for CT, which is limited to around 100ms accuracy in any case. Every night at around 3AM, the computer at our TX site checks that NTP is all well (using ntptime), and if so, sets the encoder’s internal date and time, keeping things nicely up to date. The status of the machine’s NTP synchronization is monitored via Nagios so a fault will be drawn to our attention if something goes wrong. It’s worth checking NTP before setting the time – in some situations (imagine a power outage, followed up with a network outage, and a dead CMOS battery) the computer’s clock can become reset and an incorrect time would be set and broadcast. The key thing here is to make sure that you’re setting the CT field accurately or not at all. If you can’t set up something like the above and can’t guarantee a human checking it once a month or more often regardless, don’t broadcast it. It is, however, useful for consumers, and you should strive to provide it if you ask me.

For the purposes of actually getting information to your listeners, though, in terms of stuff which really adds to the listener experience, Radio Text is where the party is at, if engineers ever had parties.

Right now I’m writing this listening to my FM radio (actually listening to an IP stream from the radio via another computer so I can use my desktop’s DT100 headphones, but it’s sat on my desk so I can see the display), and I’m being told which show this is I’m listening to (Lunchtime Jellie), the URL for the station’s website, which show is coming up next (Liv and Nat say ‘Relax’), plus I get the station slogan once in a while. Once our playout system (P Squared’s Myriad, grrr) is licensed (grrr) properly so we can export ‘Now Playing’ data to the website, we can also pull that information out and show artist/album/title information in the broadcast.

This sort of information really does add a lot to listener’s experiences and it’s a great way to bring ‘offline’ listeners into new services like your station’s website and all it can offer.

So, how do we best do it? Well, it’s a bit complicated. Radiotext fields have a type (A or B), and in some receivers there is a memory for each and both messages are looped consecutively. In other receivers there’s only memory space for the last transmitted RT string. To actually achieve all this, then, especially with a 64-character limit, we need to update our encoder’s output regularly.

The way I’ve settled on for now is to use a script, running every 2 minutes, which sets our encoder’s two RT memories. The encoder toggles between them every 30 seconds, broadcasting one, then the other. One memory always shows the show title (but will be used to carry Now Playing information, too). The other memory rotates between a few static strings and our ‘coming up next’ show.

This gives a nice, readable duration for everything, usually providing 2-3 displays of each message before a change occurs depending on a receiver’s scroll speed, which is accessible enough for most listeners and yet still manages to pack in a lot of information. It’s also a quick enough update interval to allow for song information to be kept up to date.

So, that’s a short and sweet guide to RDS from a community radio perspective. Lots to tinker with to get just right for your station, but a useful system in all regards. My next post will be looking at the complex field of audio processing for FM broadcasts.


Viewing all articles
Browse latest Browse all 3

Latest Images

Trending Articles





Latest Images