BER: an invaluable tool in integrated-receiver-decoder testing
Bit-error-rate testing plays a vital role in successful integrated-receiver-decoder product development and manufacturing. Error-rate testing verifies compatibility with system requirements and can provide nearly priceless diagnostic information during the critical integration testing.
Tom Waschura, SyntheSys Research Inc -- EDN, March 4, 1999
 Bit-error-rate (BER) testing is commonplace in data-communications systems. In these applications, bit-serial, pseudorandom test-data sequences traditionally transmit through the device under test, and an error detector at the receiver counts any unexpected bit as an error. However, BER testing in integrated-receiver-decoding (IRD) applications is more complicated than in datacomm applications and requires specialized equipment. "BER" refers to the number of errors in a data transmission or recording divided by the total number of bits sent or stored. By extending BER testing to include careful analysis of the bit location of any detected errors in the IRD data stream, a designer can further increase the benefit of BER testing. This benefit goes beyond the familiar go/no-go status of a single BER measurement. Error-location analysis can isolate bit- and burst-error phenomena, identify systematic and random errors, and correlate errors to find their causes. IRD design combines complex data demodulation from RF signals with equally complex software-controlled MPEG-2 decoders. BER is the data-transmission-quality metric that helps designers isolate system problems to individual components. Some systems manufacturers forgo performing their own BER tests when buying ICs or tuner/demodulator subcomponents for IRD development. They assume that manufacturers of these components guarantee subcomponent products' performance, regardless of implementation. Unfortunately, EMI, software programming, power-supply tolerance, temperature variations, data rate, signal jitter, and various other implementation-dependent problems can be the demise of an otherwise-good IRD design. BER tests are easy to implement and can be the basis of incoming subcomponent inspection and problem isolation during integration. Putting the pieces together Several components make up the test suite you need to perform BER analysis in IRD applications ( Figure 1 ). The output of the BER tester must be a valid MPEG-2 transport stream using the normal modulator-input interface. Flexible commercial modulators are available that support quadrature-phase-shift-keying or quadrature-amplitude-modulation applications at various data rates. The output of the modulator must upconvert to the application's RF before going to the tuner within the demodulator inside the IRD. The output of the demodulator is the 8-bit parallel-transport stream that must go back to the BER tester for error detection and analysis. You can add analog RF noise in the modulated and upconverted output and to the tuner's IF output. The bit-serial, pseudorandom data sequences that datacomm BER-testing applications use do not interface to MPEG-2 transport-stream applications because of data-format and interface incompatibilities. MPEG-2 transport streams require a synchronization byte (0X47) to define the boundaries of the 188 or forward-error-correction-enhanced 204-byte packets. Other packet-overhead information, including a program ID, must also follow the sync byte. Test data must be a valid MPEG-2 packet. Bit-serial interfaces found on traditional BER testers do not connect to the interface that modulators and IRDs use. Popular specified interfaces for this application include the asynchronous serial interface (ASI), low-voltage differential-signaling (LVDS) synchronous parallel interface, and Society of Motion Pictures and TV Engineers 310M. Additionally, to reduce costs, TTL-level, 8-bit, synchronous parallel buses in IRDs may not provide direct transport-stream outputs. To operate in IRD applications, a BER tester must use valid MPEG-2 packets as its test data and provide inputs and outputs compatible with ASI, LVDS and parallel-bus TTL interfaces. ISO/IEC 13818-1 defines the MPEG-2 data-rate-stuffing packet as the null packet. ISO/IEC 13818-1 also extends this packet definition for use as a test sequence. Listing 1 provides the definition of the null packet for testing. In the listing, N equals 184 bytes; therefore, this definition creates a simple, easy-to-construct, 188-byte transport-stream packet: 0x47 0x1F 0xFF 0x00 - - - - - - - 0x00. At first glance, this packet's sequence might seem to be a poor choice for digital-channel BER testing, because the all-zeros payload data offers little data-pattern variety. However, a closer look at the overall system details shows that this simple test pattern works well for IRD applications. A data randomizer in the modulators for satellite, terrestrial, and cable applications scrambles the incoming data according to a pseudorandom bit stream (PRBS). The output data becomes the exclusive-OR of the incoming data and the PRBS sequence. By using the all-zeros pattern, the randomizing circuit outputs a PRBS sequence for testing. The sequence still requires overhead bits so that decoding logic can determine what to do with each packet. This packet is so easy to construct that some commercial modulators include a test mode to internally generate it for BER-testing purposes. Bit-error detection To detect bit errors in a received data stream, a BER detector must know the expected data pattern. BER detection starts by establishing the phase of the incoming data sequence relative to the expected data pattern. One way to accomplish this phase detection in MPEG-2 null-packet applications is to load a reference RAM with the incoming data pattern. Testing this loaded data ensures that you obtain an error-free portion of the data sequence. The error detection then remains in lock step with this loaded reference pattern to detect errors in future packets. Once you know the reference, any nonzero result of exclusive-ORing the incoming data with the reference data indicates an error. To calculate the BER, you must count both these errors and the total number of bits presented to the error detector. When any large disturbance occurs that causes the PLL in the demodulator to add or drop clock cells, the demodulator loses synchronization. When this situation occurs, you must establish new packet synchronization before restarting BER testing. Because transport streams come in 8-bit byte-parallel formats, you must implement error detection and counting and bit counting in byte-parallel operations. For every byte received, your design must count 8 bits of data, and the error detector can accumulate zero to eight errors. Serial-stream BER testers are not ideal for this application because the received data stream offers only one clock for every 8 bits. To use a serial-BER tester, you must either multiply the 8-bit clock to create a serial-rate clock or, in applications in which the transmitter and receiver are together, artificially pass the bit-serial transmitter clock to the receiver's serializing shift register to recreate a bit-serial stream for the BER tester. In both cases, elements of the test-equipment hookup can adversely influence BER, especially when you induce noise. DVB-specified BER tests In ETR-290, the Digital Video Broadcast (DVB) Technical Module's Ad hoc Group on Test and Measurement specifies measurement and analysis of MPEG-2 transport streams as well as measurement and analysis of transmission media, such as satellite, cable, and terrestrial broadcast. Many of these media tests incorporate BER testing, and this document provides examples of test setups to perform these measurements. The specified measurements that you can accomplish with BER testing are system availability, link availability, BER before Reed Solomon decoding, BER after Reed Solomon decoding, noise margin (cable), equivalent noise degradation (cable), BER versus Eb/No, and BER before Viterbi decoding (satellite). ETR-290 describes these measurements, including their purposes, interfaces, and methods. Errors in a received stream from an IRD can come from many sources. Separating these sources is key to quickly identifying and fixing design or manufacturing problems. The BER itself is a go/no-go result. Little diagnostic information is available to designers or test engineers to solve this problem after first measuring unacceptable error-rate levels. By studying the exact bit locations of each error in the data stream, you can extract far more diagnostic information from the same measurement efforts. Exact error-location analysis requires a specialized BER-testing system. The same setups that simple BER testing uses are valid for error-location analysis. Error-location analysis allows you to easily classify errors as either bit- or burst-sized groupings. Distinguishing between the two is important because different physical-system phenomena cause them. For example, poor carrier-to-noise ratio (CNR) spreads the constellation diagram for a received signal, resulting in small random-bit errors. Radiated interference from a switching power supply, on the other hand, injects bursty errors at regular intervals. A typical reaction to high BERs might be to improve system noise floors for better CNRs. However, if error bursts cause the poor performance, a larger CNR probably yields little improvement. For example, random noise-induced errors give all bits in a stream the same independent probability of error, pe. The probability of a 3-bit error in this environment would then be pe3. If the random-noise BER was 1X10–4, the probability of a 3-bit error would be 1X10–12. For data rates of 40 Mbps, a 3-bit error would occur every 6.9 hours. If numerous 3-bit or larger bursts occur in only a few minutes of testing, the errors are not random, and you need to investigate further. A selectable definition of the error densities and lengths that constitute burst or bit errors lets you isolate various error-burst types. Burst-length histograms Burst-length histograms let you quickly and conveniently see the profile of error lengths occurring in a digital channel. Bursts are generally short in IRD applications. Error propagation in the demodulating electronics can cause single-bit disturbances in the analog domain to create multiple bit errors in the digital domain, especially with demodulators that use Viterbi detectors. When a Viterbi detector makes a wrong decision because of a signal-level-detection error, the erroneous bit enters the Viterbi's memory for decoding future bits. An error in this memory can cause future bits to have errors. By routinely inspecting the probabilities of different-length bursts, you can establish a signature of normal channel performance ( Figure 2 ). You can quickly identify any deviation from this normal behavior and use it as feedback when trying to correct the problem. However, some burst errors are unsystematic; random physical events, such as lightning, can also cause them. In IRD applications that incorporate convolutional interleave processing, error-correction systems correct bursts as large as 96 bytes. This burst length comes from the correction strength of the defined Reed-Solomon block code (T=8) and the interleave depth (12 packets). However, this assumption is true only if no other errors are present at the same time in the other 19,584 bits of these 12 packets, an underlying BER of 5X10–5. When bursts occur, the random BERs may exceed this limit. If bursts are the phenomena that the error-correction system must overcome, you can employ erasure processing to double the code's burst-correction strength. When your design has unacceptable error rates, you must ascertain whether the errors are systematic; that is, repetitive and, therefore, predictable. Once you find a systematic error, you can usually isolate the interaction that causes the error. After you understand this interaction, it is typically easy to eliminate this error. For example, a switching power supply might generate EMI, which induces enough voltage in the demodulator's circuits to cause bad decoding decisions. This EMI relates to the switching frequency of the power supply and is strongest during a certain phase or certain phases of the switching frequency. In this case, errors would correlate to this switching frequency and often occur at intervals or multiples of intervals of the number of data bits in one period of the switching frequency. An easy way to identify systematic errors is to develop a histogram of the error-free intervals in a system ( Figure 3 ). A high occurrence of error-free intervals of a certain length implies that the errors are systematic. Hence, you should use the autocorrelation of error location to isolate systematic errors. This distribution shows the probability of having an error so many bits away from any other error. Developing histograms of error-free intervals may not reveal systematic-error interactions in the presence of a large background random-error rate. The autocorrelation function can see through these background errors, and you can easily perform it in modern processors. One possible correlation in IRD applications is an error that occurs in certain locations of the 188- or 204-byte MPEG-2 packet. Because the transmission medium has no underlying failure mode that would correlate to the packet boundaries, these errors would relate to electronic failures ( Figure 4 ). These errors cannot result from EMI from switching frequencies in power supplies because the switching frequency also is not synchronous with the packet boundaries. Another possible source of error might be noise from the 50- to 60-Hz frequency of the ac main's power; however, this error also would not correlate to the boundaries of packets. Digital processing before the modulation and after the decision logic in the demodulator is most likely to induce errors that correlate to MPEG-2 packets. Invalid setup-and-hold times and pattern sensitivities from a variety of design choices or manufacturing variations (such as voltage levels, logic families, mutual inductance, and capacitance) may induce errors that correlate to packet boundaries. To isolate errors that correlate to MPEG-2 packet boundaries, you must know the location of the packet boundaries and of errors. This feature of specialized BER analyzers helps you obtain more information from BER-testing setups. When designing a product to be manufactured in large quantities, one goal is to add enough margin into various components to accommodate all system tolerances. Many aspects of IRD applications have variances, and BER testing the stress limits of these tolerances establishes the overall manufacturability of the system. The most common stress test for IRDs is to add white noise to the incoming RF signal. This technique typically measures the BER before and after error correction with different levels of noise. ETR-290 describes error-rate tests with injected noise. These tests simulate in-field operation for signal strengths, which can vary for IRD applications because of transmitter, atmospheric, geographic, and cable-topology variations. Added noise changes the SNR and makes it harder to accurately decide whether data bits are one or zero. White noise causes random bits to be in error. Unwanted noise in the tuner, demodulator, and bit-decision logic can result in poor noise-margin performance. Many factors can cause noise in designs, including bad system components, bad board-level components, and poor assembly. Noise often manifests itself as disturbances in the power or ground planes. To a threshold-detecting circuit, noise on the power rails is indistinguishable from noise on the signal. Power noise can come from a bad power supply or ineffective power-supply filtering. Misguided ground/power-plane splitting in pc-board layouts can also induce local power noise. Fast logic families are also often responsible for power-supply noise because of stray lead inductances and locally high reactance between signals and their return ground paths. Poor noise performance may cause pattern-sensitive bit errors. This behavior stems from the variable frequency content of data patterns. When added noise causes errors, they can come from the data patterns containing frequency content that is mostly marginal. You can adjust equalization to reduce various pattern-sensitive errors. Jitter occurs when a signal edge occurs at a point other than its ideal position in time. Incoming signal jitter in IRD applications acts as frequency modulation to the data signal. Signal jitter can come from any point in the signal's processing path, including poor modulator/demodulator clock-frequency stability. Jitter occurs at different amplitudes and frequencies, and its amplitude is often measured in percentage of unit intervals (UI). For example, jitter of 10% UI means that the edge of a bit window varies in position as much as 10% of the window. You can also express jitter in terms of frequency; low-frequency jitter is called "wander." Some amount of jitter in a system is unavoidable. The jitter tolerance of a system defines the amount of jitter at different frequencies that is acceptable at the IRD inputs before the onset of errors. BER testers can evaluate this error condition. These tests purposely add jitter of varying frequency and amplitude to the incoming signal. Jitter, especially low-frequency types, may cause no bit errors but can still affect system performance. Demodulators typically track to a large range of frequency variations to decode bit-accurate data streams. However, the audio and video data in MPEG-2 packets are also time-critical, and variations that cause data starving or buffer overrun can cause significant problems. Power and temperature concerns Power supplies in IRD applications typically convert 90 to 240V ac to low-voltage supplies that the onboard electronics need. These supplies are typically low-cost, and noise caused by the ac-to-dc conversion can pass directly into the IRD design and affect the noise immunity. Effective filtering yields both clean supply signals and reduced EMI. Testing susceptibility to variations in the power-system design provides information on the allowable and supportable manufacturing tolerances. Varying voltage levels, filter-component ratings, wiring methods, and ripple all generate useful data. Temperature changes during IRD use can cause significant variations in component values as well as in other param-eters, including the value of passive components, such as resistors, capacitors, and inductors; pc-board dielectric constants; crystal-oscillator frequencies; and IC-gate delays. The operating-temperature range is often part of the specification for an IRD, and tests for sensitivity to temperature changes include BER measurements of the basic communications channel in the unit. The typical setup for this test is to cycle the unit through hot and cold cycles and measure error rates before and after error correction. A lack of timing margin or a heat buildup typically causes a design to be unable to operate over the range of specified temperature. You can often improve heat exchange via mechanical changes to the assembly and heat sinks. Insufficient timing margin is typically more difficult to circumvent and often requires a redesign. IRDs operate at different data rates; higher data rates are more difficult to successfully decode because digital logic noise has worse CNRs. BER testers that can sweep over the data-rate range of an IRD design are necessary to test the unit's capability. Pushing the design to operate even higher than its specified range can tell the designer the amount of overhead present. Designs that operate only as fast as a certain speed and then fail typically suffer from insufficient timing margin. Designs that have certain troubling frequencies may have transmission-line reflections of mismatched pc-board traces that can cause harmful standing waves. A video system used to be able to tolerate a large amount of error and still generate what most people perceived as a relatively high-quality output. With the high levels of compression in modern MPEG-2 systems, this case is no longer true. Instead, the operation of an IRD depends on the absolute ability to always receive quasi-error-free data streams from the tuner and demodulator. You can conveniently accomplish testing of the bit-error statistics of IRD designs by using off-the-shelf analyzers for this application. Advanced analyzers can further provide detailed diagnostic information about failure modes and error interactions. Understanding all types of margin analysis helps manufacturers to navigate design and manufacturing problems. |
||
|
|
||
| Author's biography Tom Waschura is a principal engineer with SyntheSys Research Inc (Menlo Park, CA). He has a BA from Hiram College (Hiram, OH), a BSEE from the Massachusetts Institute of Technology (Cambridge, MA), and an MSEE from Stanford University (Stanford, CA). Away from the office, he enjoys camping, boating, and scuba diving. |
||
Talkback
