A Manager's Guide to PSD

Think of it as tiny billboards for your station:  two fields of text that appear in a window on your listener’s HD Radio receiver.   The industry term for this text stream is Program Service Data, or PSD for short.  At a minimum, a PSD stream can describe what’s currently playing on the air—a basic consumer expectation in the digital media world.  

But PSD can also be used to support a variety of other station priorities (such as forward promotion, fundraising, branding, traffic/weather, or emergency broadcast messages) during both program broadcast and interstitial programming.   Like your on-air inventory, your station’s PSD inventory will need to be approached strategically from both a work-load perspective and a clear programming philosophy. 

Since PSD strategies potentially affect the work of every department, it’s important not only for engineering and ops staff but also for station management, programming, development, and web staff to be up-to-speed on PSD basics. 

The PSD Consortium, led by PRI and funded by CPB, was created to help facilitate the efficient and effective launch of PSD across the system.  Our Consortium partners are Public Interactive, PRX, NCAM, KUVO/Denver, WBEZ/Chicago, and WGBH/Boston.  This article provides a “quick guide” to PSD issues at the station level and to the work the Consortium doing to help you address them. 

How PSD Works

Let’s start with a simplified overview of how PSD is generated.  Just like audio programming, PSD will be generated from a variety of sources:

• National program producers will provide program- and segment-level descriptive text to accompany their audio programs
• PSD for your local programs will need to be created by station staff, just as similar descriptive text is currently created for your website
• PSD text that is not directly related to programs may come from the outside (a website, for instance) or from internal sources (e.g., your marketing department)

 At the heart of PSD implementation is a piece of equipment that we refer to as a Text Scheduling Unit, or TSU. This device receives PSD text from your automation system or from other outside sources (or can be used to generate PSD locally), The TSU stores that text and schedules it to be broadcast at the appropriate time in synch with your audio broadcast. 

According to your schedule, the correct PSD is then transmitted to the PSD Importer, where it is joined with other data such as PSD for second or third audio channels.  This “bundle” is transmitted to the Exporter, where it is matched up with the audio stream(s) and sent on for broadcast.

On the consumer end, the HD radio receiver separates the digital broadcast into the audio stream and the text stream.  PSD text appears in a window on the receiver along with Station Information Service (SIS) text.  PSD text is limited to two fields of 64-charaters each; it can be updated as frequently as you’d like.  SIS text is static, and is typically used to display call letters and frequency.  You can see both the SIS and PSD fields on the graphic at the top of this article.

If you’d like to read a far more detailed overview of the PSD food chain, see our PowerPoint presentation from the iMA Conference, February 2006. 

What Are the Issues?

So what does it take to implement PSD?  The issues sort themselves into four main areas:  the necessary technology, programming code, expense, and staff time.

Technology Interface:  This is, of course, the area that is changing the most rapidly—it’s tough even for the Consortium members to stay on top of changes that are sometimes occurring daily.  But as of this writing, two pieces of equipment are necessary at the station level to make full PSD implementation possible and manageable:  an automation system, and the TSU (which may simply be a component of your current automation system or may be a stand-alone device).   As with most technology, the hardware and software needed to get this work done is likely to become more efficient, user-friendly, and inexpensive as the technology evolves.   You can read a more detailed discussion of technological issues in our documents PSD Implementation Overview and Station Services Implementation. 

Programming Code:  A critical component of public radio’s PSD food chain will be the widespread adoption of a consistent but flexible text format that producers and stations can use to create PSD, and that automation systems and TSUs can read.   PRI has taken the lead within the PSD Consortium in proposing a specific “grammar” for fields in XML (a common programming language) to cover a wide range of potential station uses – not only program title, segment, song, artist, etc. but also underwriting credits, forward promos, pledge messaging, and more. 

We’re currently in enthusiastic conversation with automation system manufacturers, who assure us that their systems can currently (or will shortly be able to) interpret our recommended XML specification. 

Others in the PSD Consortium are playing key roles in supporting this recommended coding system.  Public Interactive has created a prototype extension to its PI Composer tool to deliver program-level PSD for station schedules, as well as song-level PSD for Classical 24, in the XML format.   PRX has successfully prototyped a modification to its producer interface to generate PSD in our proposed XML spec for all of their programming offerings. 

You can view our entire proposed XML specification (along with our recommended practices) on this website.  See the Suggested PSD Field Descriptions document for program, segment, and song-level fields and the Station Services Implementation document for fields not related to programs.  If you are not likely to be involved yourself in the coding of text fields (though see Workload, below – you might be surprised on this one), we hope you’ll encourage the appropriate colleagues at your station to take a look at this XML specification and let us know their thoughts and concerns.

Direct Cost:  This is one of the biggest questions, especially for station managers:  What is PSD going to cost us?  Let’s cut to the chase:  An “entry-level” stand-alone TSU costs about $500.  An automation system costs anywhere from a few thousand dollars to tens of thousands, depending on the features you require.  Many stations have received free basic systems as part of the PRSS Content Depot rollout; however, the PRSS-shipped version of the ENCO system does not include a TSU.  Additional software required to support TSU functionality can be added to many existing automation systems.  At this time, such add-on software modules cost from $500 to $2,000. 

Obviously, high-end equipment and software for very advanced applications cost more, but that’s within your control. 

Workload:  Ah, the other big issue.  The good news is that the workload for PSD is largely scaleable, based on the PSD applications you choose to implement.  The bad news, if you choose to look at it that way, is that the most sophisticated uses of PSD are clearly going to be time-consuming and may require the involvement of departments beyond engineering and ops in the coding and scheduling of text. 

            For the most basic level of PSD—say, program/segment information for national shows and program title information for local programs—very little time is needed.  We’re hopeful that with an XML language in place, top-line PSD information for the national shows will be ready to “plug and play” shortly.  After investing in a TSU, station staff will simply enter in their program schedules and the appropriate descriptive text once, since program schedules are static (though obviously if programs in the line-up change, the TSU will need to be updated). 

Segment-level information for national shows will obviously be the next hurdle for program producers, but the workload described above should not change radically for stations as this level of PSD information comes on-line.

Greater detail in local PSD content, however, is a different story.  Song/artist-level information for local programming, for instance, may take a significant ongoing investment in staff time since not all media sources provide compatible descriptive data (older CDs, for instance); a fair amount of PSD content would need to be hand-entered.  The introduction of PSD for forward-promotion or fundraising-related purposes adds yet more levels of detail and complexity for staff.  We predict that other departments at the station beyond engineering and ops would need to dedicate staff time to learn the XML spec and the TSU scheduling process, in order to take over the “care and feeding” of the PSD inventory that relates to their department. 

But we’re here to help with that, too.  Since writing XML by hand is time-consuming, the Consortium is working on a user-friendly, web-based tool (in Beta version) for converting your desired PSD text into our recommended XML format automatically, making cross-departmental involvement with PSD a far more practical option.  Please see our document Station Services Implementation for more detail on the potential impact of XML coding on station workflow.

You’ll also need to devote a certain amount of cross-departmental staff time, just as you do with your on-air inventory, to determining the appropriate proportions of PSD “avails” for each station priority (such as forward promos or underwriting credits).  You’ll also need to determine the appropriate volume of PSD messaging overall that you believe remains consistent with public radio’s core values.  After all, PSD is programming content, just like the content that goes on your air and on your website.

Are We Ready to Launch PSD?

As a system, we’re close.  Some stations are “hand-hewing” their own systems for PSD, but that shouldn’t be necessary for too much longer.  As the ultimate goal of our CPB-funded project, this PSD Cookbook  (based on our 18 months of research, testing, and conversation-managing) of recommended operating practices is designed to make it possible for any station to launch basic PSD within 6 – 12 months.   We hope our XML specification is well on its way to becoming the industry standard (voluntary, of course).

But are you ready to launch PSD?   That is, of course, your call.  The more ambitious your PSD goals, the more complicated the implementation becomes.  But we hope that you’ll make it a priority to begin providing at least a baseline of text information as soon as possible.  Getting started is inexpensive, relatively easy, and very important.  You can always get more sophisticated over time.

Please read through and comment on our Cookbook documents and—most critical of all—start the conversation at your station about PSD and your listeners.  The biggest PSD mistake you can make, we believe, is leaving a blank screen on your listener’s radio.