Station FAQ

Station Equipment and Operations (Updated 03/07/07)

Q: What equipment did my station receive?

A: All PRSS interconnected stations in good standing received equipment from the ContentDepot project during the rollout in 2006. Much like the case-by-case review that was done under the Earth Station Refurbishment Project (ETRP), the exact complement of equipment provided was based on each station's current configuration. In January 2005, we conducted a survey to begin collecting the data required to plan the rollout to stations.

All qualified stations received a base package that included the new satellite storage receivers and streaming decoders. These replaced the existing ABR 700 demods. SOSS will be discontinued along with the ABR700s.

Since the new system uses an L-Band interconnection from the antenna to the storage receivers and streaming decoders, no downconverters or IF bus switches are needed. This requires that each station has installed the L-Band conversion kit and downconverter provided by the ETRP project. If your station is using the Satellite Systems Corp. SSC-4421 downcoverters and they are physically installed next to your Comstream ABR700 demodulators, you are ready for the new storage receivers and decoders.

Q: What is the timeline for equipment to be sent to stations?

A: ContentDepot equipment to started shipping in March 2006. All stations in good standing should have received equipment by May 8, 2006..

Q: Will the Content receiver/demods be "smart" to work off an internal template for routine capture items, or will an external (LAN) be needed to fire each event?

A: In the ContentDepot, stations will subscribe to programs. The act of subscribing will initiate the capture of the files for that series by the receiver with no further station action required. Local automation, either already existing at the station or a basic version provided by the project, will use a LAN connection to copy the files from the receiver to the automation for playout based on the station's schedule.

Q: Will the "A" "B" switch boxes (the IF Bus Selectors) for the transponders go away or will they become part of the local automation setup?

A: Transponder switching and downconverters will no longer be needed for public radio program reception. If you are using other services, such as reading services or regional services (typically not using an ABR700), those demods would remain behind your downconverter. You would simply split the L-band signal for the new receivers and downconverter(s) input.

Q: Will the new satellite demods have an analog output?

A: The stream decoders currently specified will have professional-grade analog audio (and AES/EBU digital) outputs. To be clear, these are different devices than the storage receivers. The current complement of equipment for a typical station installation includes:

• Two storage receivers with L-band inputs
• Two stream decoders with L-band inputs (each decoder has two stereo outputs and associated cueing relays—four per stereo audio channel).

Q. Is it better to change the time zone on the storage receiver, or to leave the receiver in its default setting of Eastern time and compensate for the shift to Central Time in AVTime on the AudioVault?

A. Unlike the current system, the ContentDepot's time streams—both to and from the receivers—are delivered in UTC (aka GMT). You apply any offset for local time zone at the 'end' device; in this case at your AudioVAULT.The 'time zone' setting on the Time & Date page is for local display on the receiver itself.

Q: Are the digital outputs on the streaming decoders AES?

A: The digital outputs on the SRPro2000 follow the AES3.11 specification as far as voltage and impedance values are concerned. For many AES or S/PDIF interfaces this is all that is necessary for a connection. The balanced (transformer) output and 110 Ohm output impedance allow for much longer cable runs than the SPDIF specification calls for. AES audio and S/PDIF audio are formatted exactly the same. The only difference between the two; beside the voltage and impedance values discussed above, is the formatting of the 24-byte channel status block. We have found in testing 5 DAT recorders that all but one of the devices (Panasonic 3700) locked up successfully to the signal. In the case of the Panasonic 3700, we added an RDL format converter ( FP-DFC1 or RU-UDC1) and the recorder synched up and performed flawlessly. We have tested four AES/EBU to / from SPDIF converters that range in cost between $100-$420. After it was discovered that the channel status block was formatted as S/PDIF, we worked with the decoder manufacturer to turn off the copy protection bit allowing subsequent copies of recorded audio. If you need a format converter make sure that's what it is, there are many devices that only change the voltage levels and the impedance.

Q: Is NPR Distribution endorsing or recommending any particular automation system? If not, are there particular features or protocols a station should be concerned with as it shops for an automation system?

A: NPR Distribution does not endorse any particular automation system. It is our goal to have the ContentDepot interface "generic" enough for virtually all automation vendors to write a compliant module. This will allow us to focus development dollars on automation system interfaces instead of replicating functions automation systems provide. We've had initial conversations with many of the major automation vendors already.

To interface with the ContentDepot, your automation system must be capable of performing the following tasks:

• Decode and play MPEG 1, Layer II audio
• Automatically repeat a playout schedule
• Automatically import/convert audio files from a network-viewable folder

We will post as soon as possible a detailed file specification and sample audio files on prss.org for you to download and test with your automation system.

Q: How do I find out what I need to do to make my automation system compliant with ContentDepot receivers?

A: We have published the current specification and sample files to 16 vendors. For now, the best thing to do is to contact your favorite technical person at your automation system vendor. As details of what's needed—including minimum version numbers, known issues, and short procedures—are finalized, they will be published on this site.

ENCO
BE (AudioVAULT)
BSI
Dalet
Prophet Systems
OMT (MediaTouch)
Scott Studios
Arrakis
OnAirWare
WireReady
AirForce/Macromedia
Pristine Systems
DAVID Systems
Genesys Technologies
Salem/Rivendell
Smarts Broadcast Systems
RCS

Q: Can the new system support as much live content as today's? If the receiver is in use for a streaming audio program, does that reduce the number of digital file transfers that can occur?

A: The ContentDepot will be capable of supporting more traffic in the aggregate than today's system. The receiver is capable of receiving up to a full transponder's worth of data—in any combination of streaming or files, leaving lots of room for growth. The only limitation on the number of concurrent program streams a station can receive is the number of streaming decoder outputs (four stereo outputs to be provided by the project). A station can purchase additional decoders should their needs require it. Similarly, stations can utilize other storage or purchase additional storage should their needs require it.

Q: What speed LAN is the target station system transfer rate? 10mb or 100mb or 2GB?

A: 100mb - 100baseT

Q: Will the ContentDepot require a station to have Internet connectivity?

A: The ContentDepot will at least require minimal (dial-up) Internet connectivity to request programs. Stations with more robust bandwidth will be able to utilize additional tools available via the ContentDepot portal to manage and research programs and confirm their delivery. Stations with full time connectivity will be able to use the system's file repair capabilities and enjoy an even greater level of reliability (see the next question).

Q: Will the receivers check for file delivery errors and how will they be reported?

A: As the XD client on your storage receiver starts to ingest a file from the satellite channel, it receives a bit of data from the headend that describes the upcoming file—including packet count. Each packet that comes into the receiver is examined and either put in a destination file or rejected.

The content file is created on the receiver at the beginning of the process, but it's stored as a temporary file (with a .xd extension) until all the expected packets are received, error checked and accounted for. If a packet is corrupted, XD waits to rename the file with its actual file name.

Two delivery techniques deployed in ContentDepot release 1.0 act to replace any 'missing' packets in addition to usual error correction techniques on DVB satellite carriers:

1. File FEC (Forward Error Correction)—basically sending additional data with a file that can then transparently self-repair on receipt. We're currently testing with a 10% FEC on file deliveries which means in practice that you can miss up to 10% of a file's packets without losing any data. This is very handy for overcoming short-duration losses.



2. File resends, which are also loosely described as 'carouseling'. XD will extract any missing packets it needs from a file resend without needing a perfect receive of the file in question. This is not managed exclusively by filename; there are other parameters that allow for file updates.

The original design also called for a backlink whereby the receiver requests 'missing' packets as they fail their integrity checks. We're not going to deploy backlink in the 1.0 release.

System and acceptance testing have demonstrated that the two delivery techniques employed are extremely robust— even during sun transit outages.

Q: My broadcast systems are not connected to my office LAN. Will I be able to get non-broadcast content (e.g., web modules) delivered to my web servers?

A: Non-broadcast content available through the ContentDepot—including promos—will be available for download over the Internet.