Last year we discussed the promise of the RadioText Plus tagging standard. Now let’s dig deeper into some of the technical details of RT+ for engineers.

RT+ is an additive data stream you can add to your RDS encoding that identifies the text that you are encoding in your RadioText (RT). The RT is a 64-character description that you can change anytime.

Some RDS encoders on the market support integrated RT+. If you have one of these encoders, a lot of the work I’m going to describe has been done for you by the manufacturer. In these situations, the software addressing the RDS encoder just needs to supply the content type, start markers and length discussed later. The RDS encoder handles creating the rest of the Open Data Application (ODA) packets and takes care of how frequently they need to be broadcasted.

But I know many engineers are curious to know more about the details. Perhaps you have your own “home-brew” RDS installation, or you’re considering creating your own solution to add RT+ to an older encoder that doesn’t have integrated support.

To add RT+ to an existing RDS stream, you need to broadcast two Open Data Application packets in your RDS stream from your RDS encoder. ODAs are part of the regular RDS/RBDS standards and are a way to add additional functionality.

You can have multiple ODAs running on a single RDS stream, but they must each be in a different “logical” numbered location. In the United States, the NRSC standard specifies valid ODA group locations of 5A, 6A, 7A, 8A, 9A, 11A, 12A, 13A.

Note: Due to a software issue I described back at the beginning of our series (see link to those articles in the sidebar), the initial fifth-generation Apple iPod Nano software release cannot decode RT+ tags in groups 8A and 9A unless it is upgraded to firmware version 1.0.2. I recommend avoiding 8A and 9A ODA groups for RT+ because of this issue.

RT+ Identification Packet 3A

(click thumbnail) Fig. 1: RT+ Identification Packet 3A, sent every 10 seconds, as defined in the RT+ Standard. Reprinted with permission from the RDS Forum.

The first type of packet is the 3A packet, which identifies to an RT+ capable receiver that the station is encoding the RT+ standard. See Fig. 1. This packet must be broadcast once every 10 seconds by the station. By encoding with Application ID (AID) 4BD7, receivers that support RT+ know this station supports the RT+ standard. The contents of this 3A packet have a “pointer” to the ODA group where the actual RT+ tagging packets are located.

Note: If your station is broadcasting any traffic or other leased data applications of RDS, you should check with your corporate engineering staff or your vendor leasing the data to verify what ODA group they are using. RT+ must be put on a different ODA group, or the two will conflict.

RT+ ODA Tagging Packet

The second ODA packet is where the actual RT+ tags reside, and the RT+ standard requires these packets to be sent every two seconds. See Fig. 2.Inside this packet there are several important data fields.

(click thumbnail) Fig.2: RT+ ODA Tagging Packet, sent every 2 seconds, as defined in the RT+ Standard. Reprinted with permission from the RDS Forum.

Item Toggle Bit is an important concept to understand in the RT+ standard. Every time a new “Item” changes, this bit should be toggled. It is a single bit, meaning there are only two values for it, 0 and 1.

Essentially, this bit should only change when a programming element is changing. The best way to relate to this is a song. When a song comes on, this bit should be set to 0 for the entire duration of the song.

When the song is over and the next song is aired, the bit should be set to 1. By changing the toggle bit, the receiver purges anything in memory related to ITEM, which as we discussed in the previous part in this series consists of descriptors of the current “Item” that is on the air. This clears content types 1–11, which includes title, artist, album and other song data from the receiver. The new song will have newer content types and start/length markers that it would then apply.

Item Running Bit essentially states that the current Item being displayed in the RT+ and RadioText is actually running, or “on the air.” In most cases, you would want this always set to 1. (In my opinion, you should not be displaying a song title and artist if the song is not running.)

Content Types and Markers

Each RT+ ODA tag allows for two “tags.” Each consists of a Content Type, Start Marker and Length Marker. The Content type is a number from 0–63 that identifies what type of tag the text is. Looking at Fig. 3 in my April 20, 2011 article, for example (again, see sidebar for the link), “Item.Artist” is Content Type 4.

The Start and Length markers define where in the RadioText that field begins and where it ends. These are both zero-based numbers, so you have to start counting from zero to calculate Start and Length markers. Alternatively, you can just count them and then subtract one.

Let us look at the following example:

Z100 – Fireflies – OWL CITY – CD: Ocean Eyes

We want to tag Title, Artist and Album. Accordingly, we would need two separate ODA packets, because we have three things to tag and each ODA packet supports two RT+ tags each. So, we need to create an RT+ ODA packet for Title and Artist, and then another tag for Album and a blank (null). Because the “Item.Toggle” bit will remain constant, the receiver will cache and cumulatively collect these tags as we interleave the transmission of these ODA packets.

Manufacturers of RDS encoders have implemented various syntaxes to perform RT+ tags.

In the case of the Inovonics 730 and Pira32 (firmware 1.5b or greater) which have integrated RT+ support, the software addressing the RDS encoder would need to send the following line to transmit the first RT+ packet above:

RTP=01,07,08,04,19,07

Although these encoders don’t support multiple, “interleaved RT+” packets at this point, the second RT+ packet would be transmitted this way:

RTP=02,34,09,00,00,00

Audemat/Worldcast Systems handles its RT+ in a different way in the FMB80 and FMB50 models. (Note, older FMB80 models must be upgraded to a new firmware version to have integrated RT+ support; new models have this integrated.)

Assuming you are using the integrated PS/RT formatting of the encoder, as described in the manual, your automation system just needs to send the fields to the encoder separately, whereas before it may have sent them in one line or in a different format.

SONGTITLE=Fireflies
ARTISTNAME=OWL CITY
ALBUMNAME=Ocean Eyes
DURATION=03:37

The above is a brief technical analysis of RT+ for people to understand the concept of how RT+ works. There are many details and nuances covered in the official standard document from the RDS Forum that would be helpful to review if you are developing hardware or software or to understand this standard at the binary level. See Annex P, Pages 151–152 of this document: www.rds.org.uk/2010/RDS-Specification.htm. You must request a password. Unlike some of the differences between RDS (Europe) and RBDS (United States), RT+ is an international standard, and there are no differences when it comes to encoding RT+. Read the latest National Radio Systems Committee RBDS standard at: nrscstandards.org/

While too complicated to cover in this article, performing RT+ operations in binary, hardware/software developers and those who’ve developed their own “homebrew” RDS encoder implementations could implement RT+ on virtually any RDS encoder through their RAW RDS packet transmission command.Most encoders support this.

Next time, we’ll discuss RT+ broadcaster and vendor support.

To comment, write me at: ajurison@gmail.com

Alan Jurison is a senior operations engineer for Clear Channel Media and Entertainment’s Engineering and Systems Integration Group in Cincinnati. He holds several SBE certifications including CSRE, AMD, DRB and CBNT. Opinions are the author’s own.