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
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.
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.)
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.
Priority 2
Second-priority errors are those that could affect individual programs, but the TS is still intact. The types of problems these errors can cause are frozen frames and loss of lip sync. Tests for these faults on the stream analyzer include:
- Transport error: This flag is set in the TS header by the demodulator if it can't correct errors in the stream.
- CRC error: This indicates that a CRC error (data corruption) occurred in any of the following tables — CAT, PAT, PMT, NIT, EIT, BAT, SDT or TOT.
- PCR error: This flag is raised if the primary clock reference (PCR) is not seen for more than 100ms. The time interval between two consecutive PCR values should be no more than 40ms. This type of error can cause the decoder to lose lock on the 27MHz clock.
- PCR repetition error: This error occurs when the time interval between two consecutive PCR values is more than 40ms and can cause the 27MHz clock to drift or lose lock.
- PCR discontinuity indicator error: If the difference between two consecutive PCR values is outside the range of 100ms, this error can occur.
- PCR accuracy error: This error can occur when the PCR accuracy of the selected program is outside the range of ±500ns.
- PTS error: This occurs when the presentation time stamp (PTS) repetition is more than 700ms. The PTS is contained in the MPEG-2 program stream and is used to aid the decoder in presenting the program on time, at the correct speed and synchronized. The PTS is compared to the PCR.
- CAT error: This is used for conditional access programs (paid programming).
Priority 3
Third-priority errors are application dependent and are concerned mostly with errors in the network information tables (NIT), buffer over- and underruns for the transport, multiplexer and elementary streams.
The most likely error under priority three is “unreferenced PID,” which is a packet with a PID that is not listed in the PMT. This is not critical, but it indicates that packets are being disassociated from the PMT, possibly through remultiplexing.
PCR monitoring
A very important parameter to monitor is the PCR and its relative advancement or delay in the transport stream. This can be shown as a graph that displays this timing variation in a variety of ways. The point is to know how close the PCR is to arriving at the correct time and if it comes close to causing an error. Each program or channel must be selected and monitored separately because each has its own PCR. (See Figures 4 and 5.)
ATSC recommendations
The Advanced Television Systems Committee (ATSC) has its own publication entitled “ATSC Recommended Practice: Transport Stream Verification” (document A/78a) that provides a common method for describing TS parameters that should be verified for it to be considered decodable. While A/78a does overlap with TR 101 290, the ATSC recommendation specifies five groups of priority tests, each with a range of deviation. The five groups are:
- TOA (transport stream off-air): In this case, the station is technically off-air, because the TS errors are so severe. Receivers will not be able to tune and decode anything within this broadcast — e.g., repeated absence or complete absence of sync bytes.
- POA (program off-air): Here, a major service is in error to the point where decoders will not be able to decode the program — e.g., the absence of an entry in the virtual channel table (VCT) for a service.
- CM (component missing): Typically, in this case, one of the audio or video elementary streams cannot be found, like a mismatch between the video PID signaled in the service location descriptor (SLD) and the actual PID used for the video elementary stream.
- QOS (quality of service): In this error, parameters are out of specification by such a margin that a significant fraction of the receivers can be expected to produce flawed outputs — e.g., the master guide table (MGT) cycle time being somewhat longer than the specification, which would cause slower than normal tuning.
- TNC (technically nonconformant): In this case, the error violates the letter of the standard, but in practice will have little effect on the viewing experience.
Monitoring equipment
Today’s stream monitoring devices come in a variety of configurations and price ranges. Some devices will continually monitor the stream and alert an operator to any error or potential error, while other devices must be monitored manually by an observer with a screen. Most, if not all, of these devices will list the TR 101 290 parameters for reporting, because they are used in virtually all transport streams, while some others will have the ATSC A/78a parameters as well.
For more critical tests involving the PCR, look for the following in a stream analyzer: PCR accuracy, which looks for accuracy in the originating 27MHz clock at the encoder; PCR drift rate, which looks for slow changes in the PCR frequency; and PCR jitter, which covers high-frequency changes in the 27MHz clock. These last two measurements cover errors introduced at the encoder/multiplexer and in the transmission path. The PCR accuracy test is only meant for testing of the encoder/multiplexer, however all these tests require highly-accurate local 27MHz clocks, which will be found in only the more expensive test equipment.
Some lower-cost devices connect to a computer through a USB connection and use the power of the computer to do the hard work of decoding the stream. Some are also capable of recording and playing back a transport stream, which is useful for later analyses of a suspect transport stream. If the device will also play back, then it can be used to feed the transmitter with a prerecorded transport stream when maintenance needs to be performed on the STL or data link from the studio. It also can be used in case the studio link is lost. In this case, a hard disk at the transmitter with evergreen programming can be kept and used in an emergency.
References
Tektronix has a thorough booklet entitled “MPEG Fundamentals and Protocol Analysis.” It covers a variety of MPEG formats as well as transport stream fundamentals. It can be downloaded at http://www.tek.com/Measurement/programs/mpeg_fundamentals/.
The ATSC has all of the specifications for DTV broadcasting available for download at www.atsc.org/.
The Digital Video Broadcasting (DVB) Project is the repository for the specifications for MPEG TS as well as satellite and cable transmissions. Many of the specifications can be downloaded at www.dvb.org/.
Next time
The next “Transition to Digital” tutorial will cover fiber-optic cabling for broadcasters.
