- General New System Information
- General Receiver Information Including Pricing
- Receiver Roll-Out
- Receiver Features & Integration
- Receiver Technical Data
General System Information
Are the ContentDepot systems redundant? What failure protections are there?
The ContentDepot systems are currently fully redundant and will remain so in the future. Redundancy is implemented end-to-end including:
- front-end servers supporting the ContentDepot portal
- database and file storage backing all content and scheduling information
- automation and audio routing system
- hot-standby audio delivery chains
In addition to local redundancy in Washington, D.C., a full disaster recovery (DR) site is in warm standby in Minnesota in the event that the D.C. site must go off air. All data is continuously replicated between the DC and Minnesota sites.
Most of the redundant systems support automatic failover when possible. Systems that are either not capable of automatic fail-over or need a human decision maker are monitored and controlled by our 24/7 NOC.
In addition to these existing capabilities, the future system will also support more robust audio encoder and delivery chain redundancy as well as more receiver tuning autonomy by storing and executing the schedule locally rather than the current head-end tuning model used in the current system.
What is the schedule for the Future System roll-out?
Key dates on the roll-out schedule are shown in the table below. Please note that all dates are tentative and subject to change.
|March 2019 - November 2019||Head-End Build: Development of new NOC and Back-up NOC|
|July 2019||NPR Distribution Webinar - Future Systems Deep Dive: ContentDepot Broadcast Systems|
|August 2019 - January 2020||Station Beta Test: ATX Receivers Shipped to Participating Stations to Perform Beta Tests|
|Fall 2019||NPR Distribution Webinar - Future Systems Deep Dive: New ATX XDS Receivers|
|October 2019 - January 2020||Receiver Rollout: New Units Shipped to All Satellite Interconnected Stations|
|February 2020 - April 2020||Dual Operations: New Receivers Now Live, All Stations Must Move from Current IDC Receivers to ATX receivers|
|May 2020 - June 2020||Dual Ops Ends: PRSS is live on Future ATX system, Current IDC System Sunsets|
General Receiver Information Including Pricing
What is the cost of an additional receiver?
$3,175 plus $35 shipping per unit
Will stations still be expected to pay the extra fee for a third receiver at a backup site?
Pricing for the future system is still under consideration. We will inform you of new pricing when final decisions have been made.
Will the "two port" rule remain in place with the future system?
No, we are pleased to inform you that the "two port" rule will be phased out with the future system.
Will the future system change the way that files are sent over the satellite or the bandwidth made available for file transfers?
File delivery via satellite will be handled in a manner similar to the current system. The file delivery service may however be allocated additional bandwidth periodically on a real time basis. This is made possible by a feature in the XDS system that allows currently unused service (audio) bandwidth in the transport stream to be utilized for file delivery during lighter system (headend) program schedule periods.
This means that files may be delivered a bit more quickly in the future system, but not "available earlier" for download.
Will PRSS alert stations if there are local receiver issues?
PRSS will not notify stations of local or isolated receiver issues. However, having access to station receivers will enable PRSS to troubleshoot issues with station engineers when issues are escalated.
With the FCC trying to take the lower C Band frequencies for mobile, how concerned is NPR with its satellite distribution to the NPR affiliate stations? The new receivers rolling out will have both C band and internet reception for the stations. Is this an effort to get off C Band?
PRSS continues to talk with Intelsat, the FCC, industry experts, station technical and business leaders and others to monitor a range of technical developments and improvements, including use of C Band frequencies. The new receivers were designed to provide flexibility in transmission methods and to accommodate a range of new features that have been requested by station engineers, developers, program directors and general managers. PRSS approached the design of the IDC receivers in a similar way.
Do current Internet-only FTP stations qualify for receivers?
The short answer is no, because FTP Internet-only stations do not need receivers.
How and when can stations purchase additional receivers?
Please contact Earl Johnson at EJohnson@npr.org or 202-513-2613 to place an order. You can place your order at any time, however, we will not begin to ship receivers until the 4th quarter of 2019 and this process may continue in 2020.
What is the protocol if the receivers require service?
Please contact the Help Desk at 800.971.7677 or email@example.com. They will be happy to help resolve your issue.
Will splitters be provided to connect additional receivers?
No, we are not planning to provide splitters to connect the new receivers.
Receiver Features and Integration
Should stations plan to retire their existing automation servers?
No. The automation features of the future system will not be available for some time. Our immediate focus is transitioning the stations to the ATX system as smoothly as possible.
The automation features we hope to offer will delay live programming within a receiver and spot insertion. Both are current features of the ATX system, but we need to integrate these features with ContentDepot and do thorough testing to make sure they work for our public radio programming.
Will the audio and relay outputs in the new receivers be the same as the current setup?
We are providing a dongle to be backward-compatible with the current set-up. There will be no charge for the dongle. If you prefer, you can purchase a connector kit from ATX.
How do I configure a primary and backup receiver with broadcast services in the future system?
Unlike the current system where subscriptions were directly tied to a receiver and port, subscriptions in the future system are associated with a broadcast service that will serve as the broker/middleman between subscriptions and receivers. Stations can have multiple destinations assigned to a broadcast service and can move these destinations around as desired without needing to subscribe or unsubscribe from programming. This provides more flexibility when a receiver needs to be replaced and, more importantly, makes creating a backup receiver extremely simple.
Once a broadcast service is created and subscriptions are created, any number of destinations can be assigned to the broadcast service including existing IDC receivers, FTP sites, and eventually ATX receivers. When a receiver is assigned as a broadcast service destination, all subscribed content will be delivered to the receiver. Therefore, to create a primary and backup receiver for all subscriptions on a broadcast service, a station would simply add two receivers/ports as broadcast service destinations. The content will then be delivered to both receivers and any subscription modifications will apply to both receivers automatically.
This change should also make the migration to the future system easier for stations because an ATX receiver can be added to an existing broadcast service to have it immediately start receiving the same content as existing receivers without having to modify any subscriptions.
More information about broadcast services, including training documentation and videos, will be published soon as they will be available before the full future system roll-out.
Can playback on a program overlap the recording of the same program?
The expectation is that the receiver will be capable of both playing a live stream program on an audio port while simultaneously recording it for future playback. For example, a station should be able to play program “Best Show Ever” while the receiver is recording it for a later playback and rebroadcast. This functionality is still in development and testing and the implementation may change before the feature is released for general use.
Will it be possible to populate the receivers with local content? (Such as backup receiver at a transmitter site, loss of STL, ability to populate the receiver with local breaks/IDs)?
No, it will not be possible to populate local content at this time, however, we do have this feature on our future roadmap. Separately, we are researching the possibility of using evergreen content to fill a loss of signal.
Will it be possible to time-shift with the ATX receiver? For example, Live from Here is live from 6:00 P.M. to 8:00 P.M. Will the receiver be able to record and playback Live from Here from 8:00 P.M. to 10:00 P.M.?
No, this feature will not be available when we launch, however, we do have this feature on our future roadmap.
Do Receivers A and Receiver B need to be at the same location?
No. However, if they are located in different locations, there will be extra fees. The two receivers must be in same location to avoid the extra fees.
During the overlap period we have double the number of receivers to hook up. How do we do that without splitters?
Other than receivers, stations are responsible for purchasing their own hardware (e.g. splitters, cabling, racks, etc.) in addition to integration and implementation.
Are any changes planned relative to the availability of LWSF files?
The current business rule is that LWSF files are available after 2 hours. This is not expected to change.
Do the receivers fall back to IP if satellite reception is lost?
Yes, when the receivers lose lock to satellite downlink, the receiver will transfer to IP Internet streaming. There is a Streaming Delay setting that can be adjusted in the receiver.
Can a station elect to receive programming only via IP? Or use one receiver at a remote location via IP and one at the main facility via a satellite dish?
Internet streaming on the receiver is intended as a back-up to a loss of satellite downlink or can be used during scheduled maintenance. Internet streaming is not intended as a full time service.
Will web streaming be an option?
Web streaming is available only as a back-up and uses the public Internet.
How does terrestrial streaming work with the receivers?
Terrestrial streaming can be disabled at each receiver for sites with low bandwidth Internet connections.
A station also can force a receiver into terrestrial streaming if it needs to do planned maintenance to its dish.
What will the station need to do when the new receivers arrive?
Stations will need to install them promptly but they should not put on-air until dual operations begins.
Will the receivers be mirrored?
A station may set up the ports however it likes. If a station would like to mirror the receivers to have a backup of the content, it can do so OR it can choose to have different content on all of its receiver's ports.
Receiver Technical Data
Will there be both AES67 and Livewire Audio?
Yes, both are available however you must select one or the other.
How much delay, if any, do you anticipate between the IP and downlink streams?
We anticipate approximately 30 seconds, but we are still testing to validate.
What is format of receiver audio connections?
The format is DB9M.
What encoding format will the live audio be?
The encoding format will be MP2.
How many receivers will each station get?
We are providing each interconnected station with two receivers. Remember, PRSS needs to receive a station's signed Interconnection Equipment and Services Agreement before it can send receivers to the station.
How will Squawk work with the new system?
Squawk is currently available as a 24-hour program, NPR Squawk, in ContentDepot. Stations can subscribe to that program and assign it to any available receiver port. Squawk is also available from the NPR web stream and the SCPC feed to the current system's IDC SR2000 receivers. Future enhancements to broadcast services on the ATX receivers should allow stations to free up more receiver ports to reduce any current port contention. Furthermore, PRSS is exploring additional options for Squawk delivery to make it more robust and accessible. The plan is to maintain the SCPC feed until one or more of these features is in place, however, this option will be sunset in the future and stations should begin making other arrangements.
What audio outputs (formats) will be used?
We have decided to stay with MP2 to avoid cascading codec issues. The receivers output Analog, AES, Livewire/AES67 simultaneously. The AES output can run at a different sample rate than what is being used for Livewire or AES67.
What information do you have about Ethernet/Internet connections?
There will be three ethernet ports, with one of them reserved for Livewire or AES67.
What Ethernet connections are on the back of the box and what is that purpose of the connections?
One connection will be for Livewire and one will be for internet behind the firewall.
Please remember that the equipment agreement requires that you put the receivers behind a firewall that can gateway to the Internet.
What are broadcast services and how do they effect how I subscribe to content?
A broadcast service represents a radio station’s scheduled programming, intended for air to their listeners. A station may have multiple broadcast services, such as one with a news & talk format and one with a classical format. In ContentDepot, broadcast services are a new way of thinking about how stations subscribe to programs, receive episodes, and schedule content for playback and listener consumption.
Broadcast services will serve as the broker/middleman between subscriptions and receivers. You can have multiple destinations assigned to a broadcast service and you can move these destinations around as you wish without needing to subscribe or unsubscribe from programming.
More information about broadcast services, including training documentation and videos, will be published before the full future system roll-out.
Broadcast services also lay the groundwork for features on our future roadmap including schedule prioritization and delayed playback. These features, which we anticipate to roll out some time after the future system is live, will allow stations to reduce receiver port usage and perform more automation activities directly in the receiver. This functionality is still in development and testing and the implementation may change before the feature is released for general use.
How will the future system handle files, Samba share, and file structure?
The future system will automatically re-send files via the Internet to receivers which should require less manual retrieval from Content Depot. Our plan is that the receiver will have a Samba mount just like the current IDC receivers, and mounted on the PC, needs only a change to the drive letter or UNC path it pulls from. This method is still being tested.
Will there be an ice or snow alarm?
There is an alarm if the signal level goes below a threshold. We requested a global threshold that we would set just above the level at which the audio starts dropping out. It should output via SNMP, and email.
Will the receivers continue to act as NTP servers?
The receivers can act as an NTP server sourced from our NOC with latency added to align with the audio just as we do currently.
How will terrestrial streaming be handled?
We are still testing terrestrial streaming to ensure that we can provide the most robust functionality with a minimal delay. Once we have concluded our testing, we will provide more detailed information.
What SNMP/Email alerts will be available.
The standard ATX alarms will be available. We are also adding two new signals - "Low signal" and "Terrestrial sourced signal".
Is this a special receiver designed specifically for PRSS?
No it is not. We are working with ATX to enhance its next release model, the Pro4S. Please keep in mind that we will not authorize receivers that a station acquires elsewhere (a merged or acquired commercial station, eBay, etc.)
What are the Technical Specifications for the ATX Pro4S Receivers
|Physical Details||2 RU 19” Wide x 10.75” Deep x 3.5” High
Rear fan, side panel vents, IEC power cable and separate grounding lug
Front panel display, controls, speaker, and headphone jack
1 terabyte SSD hard drive
|RF||2 “F” connectors for L-Band input but we only intend to use the RF - 1 connector
Signal level alarm that can output several ways with a user controlled threshold
LNB power (20V 500mA) available and switchable via front panel or GUI
|Analog Audio||4 DB9 Males on rear of receiver, 1 DB9 per Analog Audio Port with Left and Right outputs
Different pinout from IDC receivers – we will offer an adaptor that matches IDC pinouts
|AES3 Audio||1 DB9M on rear of receiver, 4 AES3 Audio Ports on one connector
Different pinout from IDC receivers – we will offer an adaptor that matches IDC pinouts
|Livewire / AES67 Audio||Choice of Livewire OR AES67 (the receiver has a checkbox to toggle between them)
Active at same time as other audio outputs
Station can change the Livewire mnemonics and channel numbers
Livewire GPIO available at same time as physical relays
The sample rate can be set to be different than AES3 (Livewire needs to be 48kHz)
|GPIO||There are 32 relays on the box, we plan to reserve 16 of them for program cueing
We will provide a mimic adaptor that will convert the ATX DB37 connector to 4 DB15’s that match the IDC pinouts
Livewire GPIO will be available and active at the same time as physical relays in case a station needs to use both
We will provide the relay assignments and pinouts soon, it is still under design
|Ethernet||3 Ethernet ports with 1 dedicated to Livewire/AES67
All Ethernet ports need to be behind firewalls, but at least one needs a gateway to the internet
The receiver can act as an NTP server sync’d to our headend
All ports will have access to the WebGUI, SNMP, SMTP, and the network drive for file show access
|Terrestrial Streaming||The receivers will automatically fallback to web streams that include embedded relays and tuning data
An alarm will be available to signal that the audio is from streaming and is delayed from the clock
After a 5 second confirmation that the RF has failed a buffer will start and then audio will output the same ports
Default buffer time will be somewhere between 10 and 40 seconds, but it can be set independently per receiver
If we use full resolution streams (256kbps each) the payload for each receiver would be around 1.25 – 1.5 Mbps
Terrestrial streaming can be disabled per receiver for sites with low bandwidth internet connections
Stations can force a receiver into terrestrial streaming if it needs to do planned maintenance to its dish
The receiver will return to the satellite signal after it stabilizes. We are researching if we can delay that return to a break or top of the hour.
|File Delivery||The plan is to have the ATX act as a network drive and provide the files just as the IDC receiver does
A station should just have to modify the drive mapping on the ingest machine and possibly in the ingest software