RF Column 27 - January 1994 Copyright (c) 1994,1995 H. Douglas Lung ALL RIGHTS RESERVED TOPICS: Survey of satellite digital video compression RF system requirements for digital video transmission Comparison of analog and digital RF performance "Cheap Remote" software upgrades (NOTE: I am no longer distributing software by disk - download it here!) --------------------------------------------------------------- Digital video compression is coming soon to a satellite near you! Judging from the mail, e-mail and phone calls I get, it's a favorite topics among TV engineers. This month I'll tell you how to check out your satellite installation to see if it is "digital ready" and give a glimpse at compression at the Western Cable Show in Anaheim. Also, I'll talk about software for the Cheap Remote 2 I wrote about a few months ago. If you didn't read my original cheap remote article, you'll be surprised how much this little box can do. After reading about equipment HBO, Viacom and TCI are buying that can put four or more video channels on one satellite transponder, you might be wondering if you can use the technology to get more use out of a microwave or cable path. The short answer is "yes". The long answer adds "if you can afford it". High quality MCPC (multiple channel per carrier) video compression equipment like that offered by General Instruments and Scientific Atlanta costs over $100,000 per video channel for the encoding equipment! General Instruments is planning a less expensive single channel per carrier (SCPC) system that will be a bit less. Why is the encoding cost so high? Because the compression is asymmetrical. Most of the work is done in the encoder, so under $2,000 integrated receiver / decoders (IRD's) are possible. More symmetrical systems are available, although the cost still isn't cheap for full bandwidth video. Compression Labs Inc. is one of the companies offering this type of equipment. The major manufacturers of video compression equipment are moving towards the MPEG-2 compression protocol. Currently IC's are available for "near MPEG-2" compression from C-Cubed, LSI Logic, Thomson and Pioneer. There may be more, but these are the ones I've heard of. Does this mean that one manufacturer's MPEG-2 IRD will receive a channel encoded with a different manufacturer's encoder? Not anytime soon. MPEG-2 equipment will start shipping in mid 1994, but compatibility is not assured. While the compression scheme is the same, it is likely manufacturers will package it differently - perhaps different forms of modulation, different conditional access, different transport protocols. What MPEG-2 will mean is that any MPEG-2 equipment should be compatible at the compression level. It should be possible to obtain a digital data stream that can be moved between different manufacturers' equipment without decompressing the video. While not important now, think about how many times a news feed might have to be compressed and decompressed before you transmit it. As encoder costs drop, more Ku-truck field and international feeds will be compressed to save transponder space. These are then collected by a news bureau (like CNN, Reuters, ABC NewsOne or Conus, for example) decompressed, then re-compressed for transmission to their customers. If its a network, at some point they will probably decompress and re-compress the signal again for transmission to affiliates, where it will finally be decompressed. While my tests show only minor problems with concatenation (as multiple compress/decompress cycles are called) at higher data rates, news gathering will likely try to use the least transponder space possible. With MPEG-2, the compressed video data should be able to be moved between systems without degradation. What's missing here from this scenario? A way to record MPEG-2 compressed digital video. At the Western Cable Show in Anaheim (December 1-3) Scientific Atlanta showed a system they developed for StarNet which uses pre-MPEG-2 encoder / decoder chips to record video on computer hard disks. Pioneer, whose analog laser disk recorder has become something of an industry standard, is moving into MPEG-2 digital. Soon after MPEG-2 is finalized in mid 1994, they plan to have their own chip set as well as a play only MPEG-2 digital disk player. By 1995, that unit should have record capability as well. Judging from the number of companies pre-announcing MPEG-2 compatible products at the show, I feel much more comfortable predicting MPEG-2 will dominate the compression market by the end of 1994. NAB is going to be very interesting this year! Most of my readers won't have to worry about encoding digital video compression for a year or two. Many, however, are now wondering how they will handle decoding digital video signals. The past month I've been testing both General Instrument's Digicipher 1 decoder and Scientific Atlanta's first generation digital video decoder. Here's what I've learned in real world tests. It should help you plan ahead for satellite digital video at your station. First, there's a lot more to go wrong with digital satellite signals. Your antenna system may produce excellent analog video but fail to reliably receive digital signals. Both G.I.'s and S.A.'s digital systems use QPSK modulation spread over most of the transponder. Unlike analog signals, where the carrier and subcarriers are clearly visible on a spectrum analyzer, the digital signal should look like a flat-topped hay stack or like the frequency response curve from a good bandpass filter. On a satellite receiver, it will look like noise. As I'm writing this, there are digital compressed video signals on Galaxy V, transponder 24, Galaxy I, transponder 18 and Galaxy III, transponder 24. There are also digital signals on the Morelos satellite. If you have a Tektronix spectrum monitor or a spectrum analyzer that will cover L-band, take a look at one of these transponders on your satellite system. If you see a nice, flat frequency response across the transponder without significant sloping or ripple (under 2 dB), congratulations! This response is essential for low bit error rates (BER) on digital reception. Note that flat response on one transponder doesn't mean your system is flat on all of them. If the tests show ripple (one dish I looked at had 5 dB of ripple across the transponder) or sloping response, here are some things to check. When troubleshooting some problems with the engineers at Scientific Atlanta, they kept talking about unterminated splitters on the L-band input to the receiver. This seems to be one of the most common causes of reflections in the downlink RF system. Other suspects include RF adapters - especially when joining two different types of coaxial cable, DC taps, polarity relays and line amplifiers. A clean run of low loss coax between the LNB at the dish and the input of the digital receiver is the best way to avoid these problems. G.I. includes a DC block or supply along with a splitter in their DSR-1500 receiver/decoder. Use it! If you must use an external splitter, purchase one made for L-band satellite work and if you can't avoid leaving outputs unused, make sure they have good 75 ohm terminators on them. Remember, most cable TV signals stop around 700 MHz. and the UHF TV frequency band ends at 806 MHz. The L-band output from most LNB's runs from 950 to 1450 MHz. Cable and UHF TV splitters might work okay for analog satellite work, but will probably cause problems with digital L-band signals from the LNB. I did some tests to see how robust the digital video signals were. While monitoring the output of the digital compressed video IRD's, I also looked a second receiver up to the dish and monitored analog transponders on the same satellite. I didn't have the equipment to do a scientific test, but in general I found that if the analog signals on the same satellite displayed a good picture or one with only a slight amount of sparkles, the digital signal gave a solid picture with no breakup. I reduced the signal to the receiver by moving the dish slightly off of the satellite. The threshold on the digital receivers was very sharp - a slight nudge on the dish and the digital signals became unusable, while the analog signal remained (though with the sparkles I wouldn't have broadcast it). My conclusion - if you are getting clean reception of the analog signals on the same satellite you plan to receive digital signals and the system is free of reflections that can cause ripples in the frequency response (as checked before), you should not have any problem with digital reception. Theoretically the G.I. system should be more robust than the S.A. system, which uses a little wider bandwidth. In my tests, I didn't notice any significant difference. The S.A. signals, however, were both on transponder 24, which will receive less interference from signals on the opposite polarity than the G.I. signals with carriers on either side of them. Here's something else to worry about. Interference will destroy your ability to receive digital signals. Here's the problem - radar interference, which causes a group of fine white lines to appear on a analog picture every twelve seconds or so, will probably wipe out enough of the picture data to either cause the picture to freeze, display "blocks" of video or break up altogether. Electrical interference from a noisy transformer, neon sign or gasoline engine will have the same effect. If you experience these problems on analog signals or require traps in the IF of the receiver to eliminate the garbage, fix it now before you have to receive digital signals. It may require moving the dish to another location or erecting shielding around the dish. My network will be converting to digital compressed video around NAB time, as will a number of other networks, including P.B.S. I'm sure its going to be interesting and I'll report any interesting discoveries from switch here. Last month I promised some tips on the program I wrote for controlling the Cheap Remote II. I described the main software with the original article in 1992, but for those that didn't read or don't remember that article, here's a summary of what my RMTCTL.BAS program can do. The program is designed to work with a conventional external modem. As I wrote it, many of the "off line" features won't work if it is kept "on line" all the time. When off line, the program loop monitors the day of week and time of day and looks for some wake up data on the RS-232 lines. Every couple seconds, it takes a set of readings. These readings can be tested for fault conditions and if a fault exists, it logs them in an array that can hold up to 30 faults. It also logs when the fault clears. I have the program set up to page me if a fault exists at the top of the hour. It can be modified to page immediately, if that is necessary. To make it easier to see what the problem is, the page generates a pseudo phone number that is sent to the pager. It identifies the transmitter and gives me a series of readings. Currently I've got it set up to display visual power, satellite AGC voltage and room temperature. While its checking these readings, it compares the current time against a table of times for the transmitter to be on or off and for the fault monitoring to be on or off. Each day of the week can have different times. I kept the fault monitoring and turn-on times separate to avoid generating alarms at sign-on when things were warming up or at sign-off as the meters were settling down. At the top of the hour, it takes a full set of readings and stores them in an array. While I only store 24 hours of readings, there should be enough memory left over to double this. On line, the program gets more complicated. Blue Earth Basic doesn't handle strings very well, so I had to keep commands short. I did include password protection and time outs to help prevent someone from breaking into the system. The Blue Earth micro I used in the remote can be programmed to not response to CONTROL-C commands and I strongly recommend you use that feature. A couple characters and the password wake up the computer. Once the caller is verified, a press of the "RETURN" OR "ENTER" key gives you the current time and readings. CONTROL-F gives a listing of the last 30 faults and CONTROL-G sends the log for the last 24 hours. Other keys or combinations permit transmitter on/off control or whatever else you want to do with the three command outputs. The new version of software is now available on the BPFORUM (GO BPFORUM) on CompuServe. Look for the file RMTCTL.BAS. If you see two versions, the latest is the one with the December 1993 date. I can also supply copies of the program via mail if you send me a blank disk (DOS format), preferably 3.5 inch and a label and enough postage to return it to you. Send it to my mail service at 2265 Westwood Blvd., Suite 553, Los Angeles, CA 90064. A self addressed stamped envelope will get you a printed copy, or I can fax the listings or put my computer on the fax line so you can download it from me. Call me at work in Miami at 305-884-9664 if you're interested. The best times are after 6 PM or before 10 AM. Things get too busy during the day. Copyright (c) 1994,1995 H. Douglas Lung ALL RIGHTS RESERVED