Station Services PSD Implementation Overview
This document proposes a structure to enable stations to insert various types of local PSD text with a minimum of extra work for the engineering and/or operations staff.
Section 1: Current Implementation Options
Section 2: Future Implementation
Section 3: Station Service Fields
Section 4: Sample XML
According to our survey of station interest around PSD, many stations wish to present text information concerning their local operations -- such as upcoming programming, promotions, pledge numbers, and PSAs -- via PSD. Generally speaking, this data falls into two categories: static (relatively unchanging, such as schedule information) and dynamic (relatively frequently changing such as PSA's or event announcements).
Content which changes moment to moment such as weather, stocks, and headlines is discussed in the document Real-Time Services .
Section 1: Current Implementation Options
Currently, the simplest option for deploying station service PSD messages is to manually enter them into the scheduling software on the TSU. The TSU is typically a component of the station's automation system and is described in detail in the document PSD Implementation Overview . For more static elements like station schedule information ("Up next: Fresh Air with Terry Gross" or "Tune in Sunday at 6:00 for Car Talk"), this type of manual data entry may not be a huge burden, as these messages would theoretically only have to change when the program schedule changes.
However, even with this minimal approach there are some potential downsides to watch out for. As the TSU is part of the broadcast chain, this data entry task would likely fall to engineering personnel, who may have serious concerns about the impact on their workload. And while a number of our test stations were able to implement basic versions of this functionality with relatively little impact on their engineering staff, there is no way (short of additional fields testing) to forecast how long these operations might take on any given TSU, particularly as PSD information becomes more complex.
More dynamic elements, such as timed promotions referring to specific events on specific dates, would need to be updated on a more regular basis, perhaps weekly or daily, possibly causing an unacceptable time demand on engineering or operations staff.
Alternatively, access to the TSU could be given to the departments responsible for the particular PSD messages that need to be modified. This has its own set of issues. If the TSU is a single unit located in engineering, there is the annoyance factor of additional people walking in and out of engineering. This issue is at least partially addressed by browser-based TSU systems that can address the TSU hardware from anywhere on the station's LAN. However, the IT administrative overhead of such systems for a multi-user scenario is currently unknown. Lastly, there is the somewhat-thorny issue of non-engineering staff having access to a component of the broadcast chain.
In order for stations to determine the appropriate trade-off between the extra workload caused by frequent updating of PSD content and the added value this content would give to listeners, there will need to be an installed base of HD Radio receivers with known display characteristics and back-end systems to serve text data to them. While there is significant development in both of these areas, it is, in our opinion, simply too early to make any kind of informed decision on this issue, and there will almost certainly be no single correct answer for all stations.
Real-world information on how other Public Radio stations have begun to address these issues can be found in the Reports section of this Cookbook.
In the next section we outline some ideas of what an advanced implementation of station services PSD might look like and how it would work. We recognize that this approach would require a level of IT investment and involvement that many stations cannot afford at this time. However, for the purposes of looking farther forward, we include this scenario to illustrate an automated approach to these services, in which various departments remotely modify text for insertion into the PSD stream.
Back to the top
Back to main Cookbook menu
Section 2: Future Implementation
Given the above discussion, what would an optimal scenario for station services PSD implementation look like?
In the course of our research we have modeled such a system. Generally speaking, this hypothetical system would require only minimal attention from engineering, creating presets which are changed quarterly or even annually. Various departments would update their text inserts with a minimum of involvement by engineering and this updating would be done without direct access to the broadcast chain. In order to accomplish the above goals, we found that three elements were required:
- A standardized container for this type of information (in this case an XML document)
- A simple way of creating these documents (in this case a simple web form)
- A TSU which can ingest this information.
In this scenario, engineering or ops would schedule all the inserts for a weekly schedule into the TSU. Each schedule event would be numbered sequentially, such as "PSA 5" or "Station Funding 8." The departments responsible for each type of content would then create a daily list of spots with the corresponding numbers. This list would be stored at a known location on the stations local area network accessible by the TSU as an XML document. The TSU would find, for example, "PSA 5" and insert that text at the appropriate time.
This scenario addresses most of the difficulties cited above. Given that spots are scheduled at the same time each day, engineering must only schedule a spot once. Departments responsible for a given spot could change content as often as necessary without any involvement from engineering. And XML documents could be validated as they are created to ensure compliance with PSD.
We have provided below a beta version of the projected fields for station services in XML format. We have also created an open source tool for generating this text. A working version can be viewed here or downloaded here .
Back to the top
Back to main Cookbook menu
Section 3: Station Service Fields
Station services are organized into four elements: StationScheduleInfo, StationPromo, StationFunding, and StationPSA. Each element contains four sub-elements:
-
<DayOfWeek> The day of the week that the insertion is used on.
-
<InsertNumber> The identification number of that particular insert. For example, there might be 20 "StationScheduleInfo" elements in a given day. This field allows the TSU to locate the specific one to be used. "InsertNumber" is a child of "DayOfWeek."
-
<Description> A human-readable description of the spot. "Description" is a child of "InsertNumber."
- <Content> The actual text to be displayed on the listener's receiver. "Content" is a child of "InsertNumber."
StationScheduleInfo
This element is used for text that relates to a specific program aired at a later time.
Examples:
-
Local programming promos ("Coming up at noon, Jazz with Arturo G—mez on Jazz89. Arturo welcomes Nicholas Payton, live from KUVO's studios")
-
"Tomorrow at same time" forward promos
"Later today" forward promos (going to work, listen when you get there)
-
Way forward ("Listen for Whadd'ya Know? this Saturday at noon" -- run on Monday)
StationPromo
This element is used for text that relates to station promotions.
Examples:
-
Station tag line ("Your favorite Classical Music on 89.9, KXYZ")
-
Station website plug ("On the air in FM and HD at 91.5, and online at KXYZ.ORG")
-
Member listener services ("Got a question? Call KXYZ Member Services from 8 to 5 at 333-5555")
-
Member benefit blast ("Members call now for advanced tickets for Harrison Schmeeler. Non-members, call now to join! 888-8765")
StationFunding
This element is used for text that relates to station fundraising.
Examples:
StationPSA
This element is used for community and public service announcements
Examples:
Back to top
Back to main Cookbook menu
Section 4: Sample XML
Forward Promotion
StationScheduleInfo.XML
<StationScheduleInfo>
<DayOfWeek>Monday</DayOfWeek>
<InsertNumber> 1</InsertNumber>
<Description>Car Talk forward promo</Description>
<Content>Listen to Car Talk Sunday afternoons at 4 PM</Content>
<InsertNumber> 2</InsertNumber>
<Description>Up next promo "fresh air"</Description>
<Content>Up Next at 2PM Fresh Air with Terry Gross</Content>
<InsertNumber> 3</InsertNumber>
<Description> </Description>
<Content> </Content>
<InsertNumber> X</InsertNumber>
<Description> </Description>
<Content> </Content>
</StationScheduleInfo>
Back to top
Back to main Cookbook menu
