Wegener Communications 6420 User Manual
iPump 6420 User’s Manual
www.wegener.com
800070-01 Rev B
Chapter 1, Page 9
TimeZone Delay
Most radio networks span several time zones. Because of this, to keep the same scheduled
Most radio networks span several time zones. Because of this, to keep the same scheduled
“feel” at all affiliates through all those time zones, they, once again must do their own recording
and re-broadcasts, using extra satellite bandwidth. The iPump6420 TimeZone Delay (TZD)
feature allows the central radio network manager to avoid these complexities. Using TZD, the
radio network manager can broadcast one feed over the satellite, with all the correct localization.
At those sites in “later” time zones, the i6420, implementing TZD, will hold the entire
compressed audio feed, along with all associated Compel commands (like ShowShifting) in a
rolling recorded buffer. At the precise buffer depth corresponding to the hour difference in time,
the original feed is heard, sounding and feeling the same as the live feed in the most eastern
zone.
and re-broadcasts, using extra satellite bandwidth. The iPump6420 TimeZone Delay (TZD)
feature allows the central radio network manager to avoid these complexities. Using TZD, the
radio network manager can broadcast one feed over the satellite, with all the correct localization.
At those sites in “later” time zones, the i6420, implementing TZD, will hold the entire
compressed audio feed, along with all associated Compel commands (like ShowShifting) in a
rolling recorded buffer. At the precise buffer depth corresponding to the hour difference in time,
the original feed is heard, sounding and feeling the same as the live feed in the most eastern
zone.
MP3 Codec
In addition to the standard wave (PCM only), mp2, and mpg files, iPump6420 may also
In addition to the standard wave (PCM only), mp2, and mpg files, iPump6420 may also
support the popular mp3 (MPEG1 L3) files. This is convenient for the extra flexibility in file
types for the local spots. And it is also required in order to make use of OAR, since files must be
compressed as mp3.
types for the local spots. And it is also required in order to make use of OAR, since files must be
compressed as mp3.
1.3. Functional
Description
This section is to describe the functional theory of operation of the iPump 6420. The iPump
6420 is basically a Linux-based x86 computer with advanced peripheral devices. How this
hardware works together to fulfill the i6420’s missions is shown in Figure 1-3.
hardware works together to fulfill the i6420’s missions is shown in Figure 1-3.
The RF input from the satellite antenna LNB is brought in to a DVB receiver subsystem.
This stage takes the incoming L-band carrier, demodulates the carrier to FEC-encoded data, then
decodes and de-interleaves the FEC data into the original MPEG Transport stream. This stage
also provides the main Local Controller function with key status information, including carrier
lock, error’d-second data quality, and RF signal level.
decodes and de-interleaves the FEC data into the original MPEG Transport stream. This stage
also provides the main Local Controller function with key status information, including carrier
lock, error’d-second data quality, and RF signal level.
After this, the Transport stream is brought in as a serial byte-stream to the Linux-based
application software that runs the iPump 6420. There, a software Transport demultiplexer
recovers the PSI tables, the COMPEL command packets, MPE/IP data streams, and the desired
live audio PES streams. The PSI tables are used to determine the locations of audio streams,
finding their Packet IDs (PIDs) from the user-designated Program number and Audio Language
Descriptor (LD). The COMPEL packets are parsed to find addressed commands for execution.
The MPE/IP data streams are captured and recorded to the HDD storage, as commanded. The
desired audio PES streams are identified by their PID, and then fed to software-based MPEG
decoders (not to be confused with the unit’s audio outputs).
recovers the PSI tables, the COMPEL command packets, MPE/IP data streams, and the desired
live audio PES streams. The PSI tables are used to determine the locations of audio streams,
finding their Packet IDs (PIDs) from the user-designated Program number and Audio Language
Descriptor (LD). The COMPEL packets are parsed to find addressed commands for execution.
The MPE/IP data streams are captured and recorded to the HDD storage, as commanded. The
desired audio PES streams are identified by their PID, and then fed to software-based MPEG
decoders (not to be confused with the unit’s audio outputs).
The “Local Controller” shown in the Figure is, functionally, the application software
running on the Linux-based x86 processor. The Linux OS and this software boots from a
Compact Flash card installed to all iPump 6420s. (This way, in the event of HDD failure, the
unit can still continue operation as a traditional IRD.) All the functional blocks not associated
with specific hardware are executed, in real-time, in this software system.
Compact Flash card installed to all iPump 6420s. (This way, in the event of HDD failure, the
unit can still continue operation as a traditional IRD.) All the functional blocks not associated
with specific hardware are executed, in real-time, in this software system.
As stated, the Compact Flash is the booting device, from which first Linux, then the
operating application will boot. The writes to the Compact Flash are limited to downloads of