QRZ! Ham Radio 5

home *** CD-ROM | disk | FTP | other *** search

/ QRZ! Ham Radio 5 / QRZ Ham Radio Callsign Database - Volume 5.iso / files / mac / hfpcktrn.hqx / HF Packet tutor / hf_packet.txt < prev next >

Wrap

Text File | 1993-06-28 | 17.9 KB | 341 lines

A BRIEF TUTORIAL ON HF PACKET OPERATION by Norm Sternberg, W2JUP 1. TNC PARAMETER VALUES RULE 1: DON'T USE THE FACTORY DEFAULTS IN YOUR TNC The values stored in your TNC's EPROMs are totally unsuitable for HF packet operation; they are tailored for the average VHF case. Here is a set of recommended "non-default" parameter values for general purpose HF operation on 40, 20 and 15 meter packet operation. MAXFRAME 1 to 2 PACLEN 32, 64 or 80 TXDELAY 40 or 50 FRACK 6, 7 or 8 MAXFRAME Choose a lower setting for poor conditions, a higher value for better conditions. We have very strong mathematical and experimental evidence (papers by Phil Karn and others) that MAXFRAME 1 provides better long- term throughput even on VHF! If you send FOUR frames in one packet and the distant station ACKs only frame #1, then you're going to resend frames #2, #3, and #4. If he ACKs frames #2, #3 and #4 but bombs #1, you're going to resend all four of them again anyway. What's the point in cluttering the channel with two, three or four un-ACK'ed frames when the first one hasn't been accepted? Each frame imposes a fixed "overhead" on the packet. This "overhead" is the synchronization, timing, clocking, control and address information stuff that you DON'T type; the stuff that makes the protocol work. The simplest frame you can send has at least 19 bytes (152 bits) of overhead. Each BIT of each BYTE is tested by the error correction process. Unless you have a definite need to maintain a specific document format, don't waste bandwidth inserting blank lines because you think it may "look good" on the other station's screen. If you're operating in the CONVERSE mode as most people tend to do, your packet frame is actually sent by the CARRIAGE RETURN or ENTER key. That single CR/LF you type to make a blank line creates a frame that has exactly the same overhead as a frame that has 80 typed characters. This "overhead" is the packet protocol stuff like the sync, callsigns and con- trol information - stuff that you don't see, that conveys no "user" in- formation. Every blank line must be ACK'ed just the same as the fully typed lines. (It hurts to see a link time out retrying a blank line.) PACLEN Choose a lower setting for poor conditions, a higher value for better conditions. This is the number of typed characters that makes ONE frame. The lower the number of characters or bytes in the frame, the higher the mathemat- ical probabilities of getting through without taking a hit. Each byte in the overhead mentioned above has eight bits. Each of the characters you type has eight bits. If any one of those bits in any one of those overhead bytes (or in your typed characters) takes a noise hit, then the error correction process fails, and the whole frame is thrown away. Let's say that W2JUP is directly connected to W2HPM and sends the simple line: Hello, Joe, how are you?>> That small packet frame actually consists of at least 20 bytes (160 bits) of overhead, plus 27 bytes (208 bits) of your typed data, a total of 376 bits. If any one of those 376 individual bits is trashed at any point in the link during transmission, then the entire frame is thrown away by the receiving station. Now let's assume that you're still using the factory-default value of PACLEN, 128 bytes, and that you're NOT typing any CR/LF so that your TNC is automatically sending the packet at your 129th typed character. Your frame might look like this: Joe, I wanted to let you know that I wouldn't be able to go to the club meeting tomorrow night and you'll have to get a ride from The same simple arithmetic tells us that you've just sent 20 bytes of overhead, plus 128 bytes of the characters you've typed, resulting in a frame that has 20 + 128 * 8 = 1184 bits. Simple common sense says that the chances of getting 1184 bits through the link "unharmed" - are much lower than getting only 376 bits through without damage by the typical noisy HF radio environment. Now - if you happen to be operating with the factory-default settings (as your TNC is shipped from the factory): MAXFRAME 4 FRACK 3 PACLEN 128 Let's look at MAXFRAME first. Arithmetic tells us that you've just sent a packet of FOUR frames, each one containing 1184 bits, totalling 4736 bits. The chance of ALL 4736 bits surviving the journey in typical HF conditions is a wee bit small. We're limited by Part 97 to a maximum 300 bit-per-second data rate on HF packet. At 300 bits per second, each BIT of each BYTE (or character) has a duration of 3.3 milliseconds. You can see that it doesn't take much of a noise pulse to smear one of those many bits and thereby kill an entire frame. Have you ever measured the length of a single pulse from either the "Woodpecker" or your local power line noise? Now, let's look at FRACK. The FRACK timer sets the amount of time that your TNC will wait for an ACK after the instant your PTT keys your rig. Contrary to a common misunderstanding, FRACK time is NOT counted from the end of your burst; it's counted from the beginning. Let's assume you're still using the factory supplied default values FRACK 3 (3 seconds) TXDELAY 30 (300 milliseconds). Let's say that you send our sample short line shown above: Hello, Joe, how are you?>> That packet frame contains 376 bits of stuff. More arithmetic: 376 bits @ 300 bits per second = 1.25 seconds 300 milliseconds TXDELAY = 0.30 seconds Length of burst = 1.57 seconds minus FRACK delay = 3.00 seconds Available response window for ACK = 1.47 seconds This appears to be logically possible - but is it really? Is this enough time for the other station to send you the ACK you need? The other station's TNC must send an ACK whose minimum length will be 20 bytes or 376 bits. If he's using a slightly lengthened TXDELAY (say 400 milliseconds, a longish DWAIT of 320 milliseconds, a RESPTIME of 5 (500 milliseconds), or if his TNC hears anything on the channel and delays the ACK for even a few hundred milliseconds, we have an interesting problem. Let's assume that the other station's TNC received a valid frame from your system, the channel is clear, and his TNC is going to send the ACK back to you. Now we've got a very cute "CATCH-22" situation: 376 bits @ 300 bits per second = 1.25 seconds Distant station's TXDELAY = 0.40 seconds Distant station's DWAIT = 0.32 seconds Distant station's RESPTIME = 0.50 seconds TOTAL DELAY before other station's end-of-data = 2.47 seconds Remember that your system won't know if his ACK is valid until your TNC has received and decoded his entire frame. The combined delays intro- duced at his end now approach your FRACK time. You can't decode and val- idate his ACK before your FRACK timer runs out. Your TNC RETRYs your frame because the other station's ACK didn't arrive on time. And all this relates to his sending an ACK frame of only 20 bytes. Now that we've had a taste of timing concepts, let's see why HF packet doesn't work and what happens if you're still using the factory-default values: MAXFRAME 4 PACLEN 128 FRACK 3 Our arithmetic said that you would send a packet of four frames, each one containing 1184 bits, totalling 4736 bits. 4736 bits @ 300 bits per second = 15.79 seconds 300 milliseconds TXDELAY = 0.30 seconds Length of burst = 16.09 seconds FRACK delay = 3.00 seconds Available response window for ACK = minus 13.09 seconds You cannot fit a 16-second burst into a 3-second FRACK window. Your FRACK timer expires before you've finished sending the packet! This is not going to work! Now, let's use the same arithmetic to see how our suggested values fit in here. MAXFRAME 1 (Only ONE un-ACK'ed frame allowed on the air) PACLEN 64 ((64 * 8) + (20 * 8)) = 672 bits FRACK 6 (6 seconds) 672 bits @ 300 bits per second = 2.24 seconds 300 milliseconds TXDELAY = 0.30 seconds Length of burst = 2.54 seconds FRACK delay = 6.00 seconds Available response window for ACK = 3.46 seconds This will work. Your single frame packet burst of 20 bytes of overhead and 64 bytes of your typed data adds up to about 2.5 seconds. About 3.5 seconds remain available as the interval during which you must receive the ACK from the other guy before your TNC will retry the frame. Below 28 MHz you're limited to 300 bits per second. On VHF you've been using 1200 bits per second. Everything on HF takes FOUR TIMES LONGER to send, and FOUR TIMES LONGER to receive. TXDELAY Don't assume that TXDELAY relates ONLY to your radio's switching times. It also relates to the switching and other timing factors in the other station's radio. In our real world of HF packet radio, TXDELAY relates to the radios at both ends of the link. Nearly all phase-locked-loop synthesized radios have some measureable "settling time". This delay is introduced by some PLL frequency setting systems when switching from transmit mode to receive mode and vice-versa. We also note that many HF transceivers have a significant delay - even with "fast" AGC. This additional delay occurs while the receiver's AGC circuit is "relaxing" and returning the receiver to full sensitivity. One more cause of delays appears when the sending station uses AFSK in the single-sideband mode. Some operators are not careful to avoid driving the transmitter into ALC action. ALC (Automatic Level Control) tends to reduce the transmitter's power output at keyup time and, if excessive, can actually destroy the first few bytes of the transmitted packet frame. Those first bytes of each packet frame are the FLAG field, the information that marks the beginning of the frame and provides timing or synchronization information to the other station's TNC. If the flag is smeared during transmission, the receiving TNC can't use that frame and throws away whatever it receives after it. In addition, the more sync you have on the front of each frame, the higher the probability that the other station's TNC will successfully decode your frame in conditions of noise and propagation effects. Extra flag also seems to help combat the effects of multipath and select- ive fades. Don't fall for that "Too much TXD cuts down my throughput" nonsense. If the other station doesn't decode your flag correctly, then all the bytes after the sync are trashed; the frame is thrown away. So much for your "throughput". 2. FREQUENCY CONTROL AND STABILITY RULE 2: HF PACKET DEMANDS PRECISE OPERATING FREQUENCY CONTROL!! You've operated VHF packet without problems, so you've probably ignored your TNC's transmitted tones and calibration. You've probably devoted the same benevolent neglect towards your TNC's demodulator calibration. You connect to your buddies and to the local BBS; your rule has been "if it ain't broke, don't fix it". On FM, the the tones you receive are directly generated and controlled in the other station's TNC and vice-versa. Your TNC's tones are transmitted directly, unaltered, by your FM transmitter and received unaltered by the other station's receiver. Your synthesized radio's LED frequency display tells you you're on the same frequency as the other station. But HF packet is a different story. The tones produced by your TNC may no longer be the same tones that come out of the other station's radio. The frequency of the tones recovered from the other station's receiver depend on how the other station's operator tunes his receiver. Whether you and the other station are using AFSK or direct FSK, the tones from the receiver will always be determined by receiver frequency tuning. Tuning accuracy on HF packet radio is generally more critical than in the other operating modes. Tuning errors as small as 20 Hz can result in failure to decode packets successfully. The more selective the receiver and the TNC's filters, the more critical the tuning accuracy. Some IF filters can be too narrow to handle data at our usual HF packet rate of 300 bits per second. In general, IF filter bandwidths should be greater than 500 Hz for packet operation at 300 bits per second. HF packet operation also imposes greater demands for overall transmitter and receiver stability. Unless the rig can hold frequency, plus or minus 20 or 30 Hz for more than just a few minutes, you may drift right out of a useable HF link and "die" from excessive retrys. There are other interesting problems. Unlike conventional Baudot, ASCII RTTY and AMTOR, packet signals use a data format called NRZI (non-return- -to-zero-inverted), which in effect ignores data sense (mark-space polar- ity). On HF packet, you can use upper sideband or lower sideband equally well. The only difference will be in the frequency shown on your rig's tuning display. You can be on USB while your link partner can be on LSB. Your rigs will appear to be on different frequencies. In general, most stations using AFSK tend to operate on LSB. It's best to use the same sideband as the station you're working. To set up a schedule, or connect to a PBBS, or link in a network system, you can't always go strictly by the frequency displayed by most modern HF rigs. There is no industry-wide standard as to the exact meaning of the numbers shown. Some transceivers display the frequency of the suppressed carrier in SSB; some show the frequency when your rig is tuned to Mark (lower) tone, some show tuning for Space (higher) tone. Some HF rigs even provide front-panel adjustment of the digital display to whatever the user wishes; carrier, USB, LSB, FSK either tone, etc. For the AFSK packet operator, this situation is somewhat complicated by the lack of an industry-wide standard for HF Mark and Space tones. AEA's PK-64 and PK-232 TNCs use 2110 Hz as Mark and 2310 Hz as Space, about in the same range as the traditional RTTY tones at 2125 and 2295 Hz (plus and minus 15 Hz). Most licensed clones of the TAPR TNC-2 (including the AEA PK-80) use 1650 and 1850 Hz for Mark and Space respectively. TNCs using the AMD7910 "World Chip" modem (including AEA's PK-87 and PK-88) provide a choice of 1075 Mark and 1275 Space, or 2025 Mark and 2225 Space. When using AFSK, your rig's displayed frequency will literally depend on the tones being transmitted by the distant station, and also on the fre- quencies to which your TNC's demodulator and filters are tuned. Check your TNC and transceiver operating manuals to determine what audio tones your TNC uses for Mark and Space, and how your rig's digital display re- lates to the received and transmitted frequencies. There are some subtle problems in HF packet radio. You may see lots of interesting packet signals, send repeated connect requests - and nothing! You check your timing parameters; they're all what they should be. You set AGC to "FAST", you verify that "ALC" is not active. VOX is turned off, the rig is putting out power, the antenna is connected, everything appears "normal - and still nothing! What can be wrong here? You've probably assumed that your rig is receiving and transmitting on the same frequency shown by your digital display. This is not always true! Some of the most-recent HF transceivers seem to have as much as 200 Hz difference between the receive and transmit frequencies. This is enough to guarantee your inability to establish and maintain a decent packet link. Don't assume anything! Be prepared to tweak your RIT/XIT controls to make the link work. Be prepared to recalibrate your rig's reference oscillators if neede. You may require either a good counter or a patient partner to determine how your rig is behaving and if you're really sending and receiving on the same frequency. 3. CONCLUSIONS You too can work HF packet successfully. Remember these general principles: o Assume nothing o Take nothing for granted o Check everything twice o Recognize that there are major operational differences between VHF and HF packet radio. o Remember the two most-critical factors for success on HF packet: TIMING and TUNING /30 W2JUP