January 2006 Issue Our downstream 64- and 256-QAM (quadrature amplitude modulation) signals are susceptible to all sorts of gremlins. Many impairments result in degraded bit error rate (BER) performance, which, if severe enough, can seriously impact high-speed data, voice and even digital video services. QAM analyzer One particularly useful tool to combat these problems is the good ol’ QAM analyzer, available from several manufacturers. Most QAM analyzers support a variety of downstream digitally modulated signal measurements: constellation display, digital channel power, pre- and post-FEC (forward error correction) BER, modulation error ratio (MER), adaptive equalizer graph (sometimes called “equalizer stress”), and in-channel frequency response and group delay. The DOCSIS Radio Frequency Interface Specification states that worst-case downstream post-FEC BER at the cable modem shall be 1.0×10-8 or less, at specified signal levels and carrier-to-noise (C/N) ratios. My personal recommendation is that there should be no pre- or post-FEC errors anywhere in a DOCSIS-compliant network, at least as measured on the typical QAM analyzer. It’s important to understand that a QAM analyzer’s pre- and post-FEC BER measurements aren’t true bit error rate measurements, but are estimates based on what the forward error correction is doing. Still, they’re reasonably accurate and are very useful parameters. When bit errors do show up on a QAM analyzer, it’s a good idea to find out what’s causing them and fix it. While tracking down the problem, be sure to look at the constellation and measure MER and digital channel power in addition to pre- and post-FEC BER. Common problems By far, the most common cause of pre-FEC bit errors is sweep transmitter interference. The easiest way to tell if this is the culprit is to temporarily turn off the sweep transmitter—if the bit errors go away, you’ve found the problem. The fix typically involves setting proper sweep transmitter guard bands around the affected digital signal and maybe tweaking sweep levels. The second most common source of bit errors is downstream laser clipping. Here’s how to identify it: Check pre- and post-FEC BER at the downstream laser transmitter RF input. There should be no bit errors there (if you do find errors at the laser input, you’ll need to sort out the cause—more on this in a moment). Next, go to a node fed from that laser and check BER at the node’s downstream output. If you see errors at the node output but not at the laser input, the laser is most likely clipping. If you do suspect laser clipping, you should check and adjust as necessary RF levels on every downstream signal in the headend. Pay particularly close attention to the amplitude of the digitally modulated signal average power levels relative to analog TV channel visual carrier levels. In some instances, you may find that even with each downstream signal’s level correctly adjusted, it will be necessary to turn down all channels—analog and digital—a decibel or two at the laser input. Other problems After sweep transmitter interference and downstream laser clipping, any of several problems may be the cause of bit errors. Start at the cable modem termination system (CMTS) or QAM modulator output. There should be no bit errors there. If an external upconverter is used, check for errors at the upconverter input and output. Improper upconverter setup is a fairly common cause of upconverter-related bit errors. Tweaking input and output levels will usually get things back to normal, assuming the upconverter itself isn’t on the fritz. Over-the-air ingress is another culprit. The constellation display may show the familiar donut pattern if ingress from, say, a paging transmitter or two-way radio is at fault. If digitally modulated signals are carried at higher frequencies in the downstream, they may be susceptible to ingress from UHF TV channels. High-power digital broadcasts can cause all sorts of problems if one of those signals “leaks” into the cable network on the same frequency as one of your digitally modulated signals. If you do have downstream ingress, more than likely you also have at least some leakage. Get it under control, and ingress will be much easier to manage. Also consider moving your DOCSIS channel—especially if it carries voice traffic—to a frequency that will not be affected by strong over-the-air signals should ingress occur. In-channel spurious beats from other headend equipment is a possible cause of degraded BER, as is adjacent channel interference from an upper or lower adjacent analog TV channel or digitally modulated signal. JDSU’s (formerly Acterna’s) SDA-5000/Opt. 4 has a feature called “ingress under the carrier” that removes the digital haystack from the display, allowing ingress and even beats near the system noise floor to be seen. This is a good way to track down in-channel interference without having to remove the affected signal from service. Headend combiner isolation problems have been known to result in degraded BER performance. This is a little harder to troubleshoot and may require temporarily removing one or more signals from service. Be sure to carefully check wiring. (Was something changed recently?) I penned a column on headend combining and ways to improve combiner isolation back in February 1999: www.ct-magazine.com/archives/ct/0299/ct0299j.htm. Loose connectors are another source of degraded BER performance, and like anything that is intermittent in nature, may require a little divide-and-conquer detective work to troubleshoot. Loose connections can occur in the headend and outside plant, including drops. Yet another source of poor BER is linear distortions—micro-reflections, amplitude ripple and group delay—in the headend or outside plant. For more on this, see my two-part feature in the July and August 2005 issues: “Linear Distortions, Part 1”: www.ct-magazine.com/archives/ct/0705/0705_lineardistortions.htm and “Linear Distortions, Part 2”: www.ct-magazine.com/archives/ct/0805/0805_lineardistortions.htm. Weird stuff And then there are the really unusual problems. I was recently involved in discussions with a cable operator who found that the weekly emergency alert system (EAS) equipment test caused intermittent bursts of downstream errors. The EAS gear was apparently improperly adjusted, and when it went into test mode, system distortions (and probably also laser clipping) briefly went through the roof. Ron Hranac is a technical leader, Broadband Network Engineering, for Cisco Systems and senior technology editor for Communications Technology. Reach him at firstname.lastname@example.org.