In the March 1 issue we dug 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.
Now, let’s discuss RT+ broadcaster and vendor support.
A Kenwood DNX7190HD navigation receiver on the author’s workbench displays RT+ for New York station WHTZ(FM), ‘Z100.’
Broadcaster support
Unfortunately, broadcaster support for RT+ in the United States has been lacking. While several major broadcasting corporations have implemented RT+ on some of their FM stations, there are still many in the United States that do not encode with RT+. I attribute this primarily to its relatively recent introduction in this country, little understanding among the broadcast engineering community on how it works, lack of communication of what the standard entails and the relative lack of RDS products that support RT+.
I think the RT+ standard holds great promise for our industry, and unlike other recent technological improvements, this standard is supported by actual popular receivers on the marketplace. We all know that analog FM broadcasting will be with us for many years.
If you do not already have RDS on your station, you should consider getting it. If you have RDS, you should consider exploring ways to add RT+ to your existing RDS data stream. That, coupled with the royalty-free open standard nature of the RT+ specification, means this should be a low-cost, one-time investment to your station.
If more broadcasters add RDS and RT+ support, I think more receivers will come to market with support for the standards. RT+ is a natural fit for inclusion with portable FM radios, MP3 players, desktop, mobile receivers and the more advanced car entertainment centers.
In the past few years, several RT+ receivers have come to market in the United States. Most notably is Apple’s implementation of an FM tuner with RDS and RT+ support in its fifth-, sixth- and seventh-generation Nano players. Kenwood has supported RT+ on various FM receivers with RDS since 2007, including 18 models for 2012. The discontinued Microsoft Zune product line also supported RT+.
If broadcasters rapidly start implementing RT+ on their stations, receiver manufactures will have an incentive to include this in future designs.
A call to action
As I mentioned, part of the reason why RT+ has not been fully adopted yet is the lack of public information and discussion of the standard in the United States. I have not seen a comprehensive overview of RDS and RT+. I hope that my articles on this topic have given everyone a basic understanding of the concepts required for RT+ tagging.
In order for this standard to be successful, it requires cooperation of station owners as well as automation system, third-party software and RDS encoder manufacturers.
When this standard was introduced in 2005, there wasn’t a single RDS encoder that offered integrated RT+ support. You needed to implement a combination of software/hardware in the middle to create the RT+ RDS ODA packets and send them to your RDS encoder.
To my knowledge, one of the first products on the market to do this was Jump2Go’s JumpGate. This was released in April 2008; itworks with multiple automation systems and virtually any RDS encoder. Later that year Inovonics introduced its 730 RDS encoder, the first encoder I saw that had integrated RT+ support.
At the same time, Artic Palm released a version of their Center Stage Live CSRDS software that could address the Inovonics 730 and provide it the RT+ tagging information. In June 2009, AirRDS, a software-based RDS management system, started supporting RT+ on virtually every encoder too. But all things considered, in 2008–09 there were few RT+ encoding products available.
Since then most RDS encoder manufacturers have stepped up, with many of them offering new models that support RT+ directly through their command line interface.
In early 2010, Audemat/Worldcast Systems introduced a firmware upgrade that can be purchased to add RT+ into its flagship FMB80 encoder. New FMB80 encoders that are purchased also include integrated RT+ support.
In March 2010, BW Broadcastintroduced an RDS2+ encoder, and in July 2010 offered a software upgrade for their RDS3 encoder, enabling both products to have integrated RT+ support.
In October 2010, the low-cost Pira32 RDS encoder offered a free firmware upgrade that adds integrated RT+ support. In March 2011, Kvarta added RT+ to its RDS500 and RDS1000 products.
And at the NAB Show in April 2011, Audemat introduced a new lower-cost RDS encoder model, the FMB50 that supports RT+.
However, many of the major broadcast automation vendors do not yet directly support these encoders’ RT+ features. While most automation software can send basic commands to the RDS encoder, there are additional lines or a different syntax needed so the encoder knows the proper Content Type, Start and Length markers for RT+ tags. In time, especially with customer demand, these systems will adapt to address these encoders.
Get the Most Out of RDS This is one of a series of articles to help you get the most out of RDS. Read them all at radioworld.com/RDS
Many older RDS encoders cannot be upgraded to support integrated RT+. Understandably, it might not be in the budget to buy a new encoder just to support RT+. I think there’s a large market for solutions in this area. There are a couple of software and hardware products mentioned above that can work in conjunction with older RDS encoders to provide RT+ tagging without necessarily replacing the encoder; but I think more vendors should consider offering solutions in this area.
Overall, all vendors should support this standard in order for it to be deployed widely by all broadcasters. Costs associated with implementing RT+ should not be significant, and they should be one-time fees.
Over time, as RT+ encoding demand grows and this need is relayed to software and hardware vendors, more solutions will come to market. Interoperability among automation systems, third-party software and RDS hardware manufacturers will improve.
Ask your vendors for RT+ support when seeking new products or making upgrades/changes to your systems. And I would encourage everybody to look into the options at adding RT+ to their RDS broadcasts. Having RT+ computability should be a requirement for any new purchases.
I covered this topic in my NAB Broadcast Engineering Conference paper entitled “Understanding and Deploying RT+” at this year’s spring show.
In our next article, we’ll discuss things we all should be doing to ensure the information we display via RDS is informative, clear and concise.
Alan Jurison is a senior operations engineer for Clear Channel Radio Engineering and Systems Integration Group in Cincinnati. He holds several SBE certifications including CSRE, AMD, DRB and CBNT. Opinions are his own and not necessarily those of Clear Channel or Radio World.
