Transport stream monitoring
Sep 8, 2008 8:00 AM
Broadcast DTV has only gotten more complex, requiring more and more training and study by broadcast engineers. And just when it looked like broadcasters had a handle on the all-digital plant, the digital transmitter required new training. Most engineers don’t think too much about the actual transport stream that connects the studio output to the transmitter’s input; they’ll keep an eye on the digital microwave or the fiber optic link — but the actual stream is a given.
With the DTV signal is about to become the only signal, it’s time to really look at and understand one of the most vital links in the broadcast chain, the transport stream (TS). Some stations are lucky enough to have their own stream analyzer or even a stream monitor, but how many operators really understand it?
Monitoring the stream
Figure 1
Click to enlarge
The best way to become familiar with the TS is to monitor and study it when there are no problems. What does it look like when there are three SD programs compared to when only one HD program is on the air. (See Figure 1.)
An important point is that the following tests were designed for monitoring the TS at its origination point — the output of the multiplexer. Determining if this is correct is the first step in monitoring the TS. After it has been verified at the source, then tests can be performed at the transmitter or off the air to further verify the TS.
The DVB Group has prepared a technical report (TR) for monitoring the TS, which covers a number of faults from the most critical to the least critical. Most, if not all, stream analyzers incorporate these tests to provide a common set of measurements.
TR 101 290
The technical report TR 101 290 entitled “Measurement Guidelines for DVB Systems” is the basis for nearly all transport or MPEG stream analyzers. The tests are intended for continuous or periodic monitoring of the TS while in operation; they are designed to check the integrity of the TS with the aim to provide a check of the most important elements of the stream. The display of information may change and additional tests may be provided, but there is a commonality between all stream analyzers based on the TR 101 290 document, which is available from the DVB Group Web site.
Figure 2
Click to enlarge
Priority of faults
The tests boil down to a series of tests where different parameters are monitored and measured in either frequency of occurrence or timing variation. The results are displayed on screen as either pass or fail indicators or, in the case of timing, with the use of a scale showing where the parameter’s result is in relation to its maximum allowed value. Other indicators will alert the operator to a pending fault if the values start to come close to the system’s limits. (See Figure 2.)
Figure 3
Click to enlarge
There are three levels of priority for faults in the stream: first priority are considered necessary to ensure that the TS can be decoded, second priority are recommended for continuous monitoring and third priority are faults that could affect certain applications.
Priority 1
First-priority faults are basically faults that will take you off the air. Although the transmitter is operating and producing at full power, there is no picture or there are other major faults indicated by the transmitter. In this case, monitoring the TS arriving at the transmitter would make sense, and the first things to look at are the first-priority fault tests on the stream analyzer, which include:
- TS sync loss — The loss of synchronization with the TS is the most serious fault. When 5 sync bytes have been acquired, the decoder is considered synched, but a loss of just 2 sync bytes indicates a loss of sync. (See Figure 3.)
*Once the decoder is synchronized, the rest of the parameters can be evaluated.
- Sync byte error: If the sync byte is not equal to 47 hexidecimals, then a sync byte error occurs. The system then looks for the reoccurrence of the sync byte (which must be 47 hexadecimals) every 188 bytes.
- PAT error: The program association table (PAT) is the only packet with packet ID (PID) Hex 0000, and it must occur at least every 0.5s to keep this error from occurring. Every program within the TS is listed in the PAT; if it is missing, then no programs can be decoded.
- PAT error 2: If the table has an ID other than Hex 00 or there is more than one table ID Hex 00 inside the packet with the PAT PID, then this error can occur.
- Continuity count error: This error occurs when any of the following faults happen — incorrect packet order, a packet occurs more than twice or a packet is lost.
- PMT error: This can occur if the program map table (PMT) does not come up at least every 0.5s on the PID that is referred to in the PAT.
- PID error: When TSes are remultiplexed, this can occur if any PID doesn’t refer to an actual data stream.
| Want to use this article? Click here for options! |  |
