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
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
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
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.
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
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:
Although these encoders
don’t support multiple, “interleaved RT+” packets at this point, the second RT+
packet would be transmitted this way:
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.
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
encoders support this.
Next time, we’ll discuss
RT+ broadcaster and vendor support.
To comment, write me at: firstname.lastname@example.org
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.