Understanding HD Radio: The program audio chain - Part 4

PSD Harmonization with RDS
With the development of IBOC radios that also could receive RDS⁶ transmissions in the U.S.A., manufacturers sought a way to harmonize the program associated data coming via RDS and MPSD. It was observed that when a radio was in a blending zone where the hybrid IBOC signal was blending back and forth between digital and analog reception, the PSD would be inelegantly replaced by RDS data that was formatted differently or had different content. When the receiver makes a transition from IBOC reception to analog reception with RDS (or vice versa), it repopulates the IBOC text display with RDS text (or vice versa). When the text elements differ between the two transmission formats, the transition causes disconcerting changes in the displayed text.

The RDS Open Data Application for Program Associated Data (ODA PAD) was adopted in April 2005 to address this problem. It is Annex U of the NRSC-4-A standard. The ODA PAD specification intended to let stations continue to transmit their RDS Radiotext (RT) to conventional RDS-equipped receivers, while providing a separate "map" indicating what parts of the RT can be matched to PSD. A station might program its RT to say: "Now Playing <title> by <artist> on the Best Mix Station," in which the title and artist name are inserted in the text string for transmission.

In this example, the separately transmitted text map indicates to the ODA PAD-equipped receiver which part of the RT character string is the title and which is the artist. This was an ingenious proposition to create a backward compatible protocol, and was incorporated into the NRSC-4 standard. It would use the Radiotext on RDS to harmonize IBOC and RDS text in the same receiver. However, internationally, other events caught up with this idea.

The RDS Forum adopted a feature called Radiotext-Plus (RT+) in late 2006. It included some prospective harmonization for RT+ with IBOC PSD and SIS data. RT+ employs a mapping protocol similar to the NRSC-4 ODA protocol. RT+ contains a richer mapping of text attributes to make Radiotext more useful to a new generation of RDS receivers. Kenwood proposed a harmonization scheme to provide uniform treatment of RT+ and IBOC text. Table 4.10 shows how Kenwood suggested the IBOC PSD and RDS RT+ fields can be paired.

Broadcasters may wish to consider the length of the RDS fields when populating their IBOC PSD fields. Check www.nrscstandards.org for the latest RDS harmonization recommendations from the NRSC. (Also, see Chapter 10 for more on Station Information Service (SIS) data).

PSD Transport
Once PSD ID3 tags have been generated, they are fed to the next layer of the protocol stack, the Program Service Data Transport. This transport is described in NRSC-5 Reference Document (9). It makes reference to "PPP in HDLC-like framing" as the source of the transport's structure. Attached to the document is an informative Appendix from the Internet Engineering Task Force that discusses this concept. The goal of the transport is to transmit a continuing series of packets in a manner that enables the recipient to enter the stream at any time and recognize when the next whole packet begins to arrive.

The Internet Point-to-Point Protocol (PPP) provides content-agnostic methods for transporting packets of data over point to point serial data links. A technique for framing information from a PPP protocol was outlined in the IETF Network Working Group's Request For Comments 1662, PPP in HDLC-like Framing. This is the informative reference attached to the PSD Transport document. HDLC stands for High-level Data-Link Control, which is a link frame structure standardized by the International Organization for Standardization (ISO).

The long and the short of this soup of acronyms is that the authors of the PSD Transport relied on the accumulated knowledge of two standards bodies to come up with a tried and true way to transport PSD packets. HDLC-like framing is a method of sending a stream of placeholders, null characters, until a packet is ready to send. The packet is encapsulated in some transport information. In the case of PSD, the packet is preceded by a Protocol Field. This field tells the receiver that the packet is formatted as a PSD packet. If in the future other information is to be sent over the PSD transport, requiring a different packet protocol, the value of this field would be changed, and existing receivers should be smart enough to ignore the contained packet.

The protocol field is followed by a port number indicating a logical port to which the receiver should be open for the data. There is a sequence number (two bytes) to ensure the order of the packets is maintained in the buffer. This is followed by the actual PSD packet, which is up to 1024 bytes long.

The HDLC-like framing wraps up the encapsulation with a 16-bit Frame Check Sequence for error detection. This a CRC-16 value computed on the entire encapsulation, from the Protocol Field to the end of the PSD packet.

Following the Frame Check Sequence, one or more null characters are transmitted until the next encapsulated PSD data begins with its protocol field. The null characters are called Flags. The Flag has the binary value equal to an ASCII tilde character (~). The transmission of a series of Flags is called an Idle Pattern, indicating that the stream is still coming in but no new data is being transmitted. Unlike other protocols discussed in this chapter, this protocol has no file size indicator or end pointer. At the receiver, this information is fed serially into the PSD Transport layer, where data between Flags is steered off to a buffer. If a packet is no good, it is discarded and the receiver waits for the next data following a flag to begin to arrive.