G-TOR (tm)

G-TOR (tm)

by Phil Anderson (1), W0XI, Michael Huslig, Glenn Prescott, WB0SKX,
and Karl Medcalf, WK5M

On New Year's Day, W0XI and WK5M transmitted a 9,718 byte file from Kansas to WA4EGT Jeff, InterFlex Systems) (2) in California on 20-meters in 5 minutes, 20 seconds. The mode was G-TOR. Immediately thereafter, the file was transmitted again, this time using Pactor. It took 20 minutes, 15 seconds. Throughout the month of January these tests were repeated with over one-million bytes transferred error-free. The average character/second rate for G-TOR was 23.7, for Pactor 8.64 (3).

G-TOR, short for Golay-TOR, is an innovation of Kantronics, Inc. It's a new HF digital communications mode for the amateur service based somewhat on concepts outlined in the MIL-STD-188-100 series of documents (4). The error correction coding outlined in 188-141A (ALE) forms the basis for G-TOR. In order to keep costs low yet take advantage of concepts prescribed in the standards, G-TOR makes use of existing multi-mode TNC hardware but establishes a completely new hybrid ARQ system in firmware.

The benefits of these innovations are:

dramatically increased throughput
apparent reduction in the effects of interference and multi-path
low cost

The key features of G-TOR are:

extended Golay forward error correction coding
full-frame data interleaving
Huffman data compression with run-length encoding
link-quality based baud rate: 300, 200, or 100
2.4 second hybrid-ARQ cycle
fuzzy acknowledgements [meaning "error tolerant"]
reduced overhead within data frames
standard FSK tone pairs (mark and space)

BACKGROUND RESEARCH

It occurred to us after porting Pactor into the KAM that this protocol did not go far enough. It did not incorporate any of the potential strengths prescribed by MIL-STD-188-141A. In adition, we knew that commercial and military systems use forward error correction (FEC) and data interleaving. So, we decided to evaluate the potential of using FEC coding with interleaving to increase data file transfer throughput with existing multi-mode TNCs such as the KAM and KAM-Plus.

We collected signatures of HF error patterns by sending Pactor idle characters through a DSP-based HF simulator. The simulator was programmed for various types of channels and conditions. In particular, we gathered error signatures by using the good, moderate, poor, and flutter fading channels prescribed by the CCIR (5) as recommended simulator test channels.

We then exclusive-ORed the error patterns with random data files on a PC and tested various coding schemes. Random data files were Golay encoded, interleaved, and then mutilated by the error signature. The process was then reversed; each file was de-interleaved, decoded and the data displayed. We were encouraged with the results so we moved on to the remaining major design tasks: designing a robust ARQ protocol and determining whether or not the TNC could handle the necessary computing task!

Over several months we evolved a protocol that met the challenge. It was coded and ported into the KAM-Plus and real-time tests were conducted using the HF simulator. Minor adjustments were made - as in all projects - and we began on-the-air tests. Tests showed G-TOR tobe even better than our simulator predicted. Through a combination of coding and interleaving, G-TOR 'hangs in there' when channel conditions get tough.

G-TOR frame structure and ARQ cycle

G-TOR operates as a synchronous ARQ mode 1. Regardless of transmission rate, the cycle duration is always 2.4 seconds, data frames are 1.92 seconds long, and the acknowledgements take .16 seconds. At 300 baud, each data frame contains 69 bytes of data, one control byte, and a two byte CRC. At 200 baud the frame contains 45 data bytes, and at 100 baud 21 data bytes.

Synchronization is established during the linking phase when the calling station (master) sends a G-TOR frame containing TO and FROM callsigns. The information receiving station (IRS), while in standby, synchronizes to the frame by searching for its callsign. Once in step, it acknowledges such to the master and sends to its terminal. Transmission of data may then begin. Sufficient time is left between the end of the data frame and the start of the acknowledgement for propagation between stations over an HF path. A change in information flow direction (changeover) is accomplished by extending the acknowledgement bytes into a changeover frame. Once acknowledged by the other station, changeover is complete. Link quality, dictated by the number of consecutive good or bad frames received, determines link speed.

The effective performance of stations, while communicating over adverse HF channels, relies on the combined use of forward error correction, interleaving, and redundancy. These tools for improvement are incorporated in G-TOR within the firmware of the KAM-Plus (or KAM with enhancement board). We adopted an extended version of the (24,12) Golay code for G-TOR.

Procedures for data formation, transmission, reception, and data recovery are outlined below. Prior to transmission, 300 baud frames are divided into 48 12-bit words and matched and matched with 48 error correction words of 12 bits each. The entire 72 byte data frame is then interleaved bit by bit, resulting in 12 bins of 48 bits, and transmitted. Upon reception by the IRS, the reverse process is carried out. The frame is synchronized, de-interleaved, decoded, and checked for proper CRC. If the frame is found to be in error, the IRS will request that the matching parity frame be sent. Upon receipt, the parity frame is used in combination with the data frame in an attempt of recover the original data bits. If unsuccessful, the ARQ cycle begins again. The dispersement of noise-burst errors via interleaving and the power of the Golay code to correct 3 bits in every 24 usually results in the recovery of error-free frames.

ON THE AIR TESTING

During the month of January over a million bytes were transferred error-free from Lawrence, Kansas [Kantronics] to Laguna Niguel, California [InterFlex Systems]. During these tests, TRACE was set ON at each station, enabling the display of acknowledgement bytes and data frames including control bytes. This allowed us to view and count data and acknowledgement frames received with and without the aid of forward error correction and interleaving.

The results were somewhat surprising! While Pactor often dropped in transmission speed from 200 to 100 baud, G-TOR nearly always kept on crunching frames at 300 baud! Enough frames are corrected to keep the system running at 300 baud, regardless of man-made interference and mild multi-path conditions. This was apparent as G-TOR seldom dropped automatically from 300 to 200 baud. Transfer duration for the entire test file varied from 12 to 27 minutes for Pactor but only 5.5 to 7.5 minutes for all but one transfer in G-TOR. G-TOR simply maintained its highest pace better, resulting in a substantial increase in average throughput.

Operation of G-TOR is much like AMTOR. You enter G-TOR standby by typing and in response to the cmd: prompt. From standby you can copy AMTOR FEC (also used as the calling mode for G-TOR CQs), or wait for a G-TOR link request from another station. To initiate a link with another station, you must type (GTOR callsign return). The link is then established and the TNC reports (linked to callsign). During a QSO changeover is dictated by the usual keyboard (or host-mode) directives, (control-C T) and (control-C E).

CONCLUSION

G-TOR features include Golay forward error correction coding, full-frame interleaving, on-the-fly Huffman data compression with run-length encoding, fuzzy acknowledgments, a long ARQ cycle of 2.4 seconds, and a link-quality based transmission rate. Combined, these techniques result in a new, very robust, interference-resistant, and existing equipment compatible mode for HF digital communication for the amateur radio service. Throughput exceeds other existing all-mode TNC modes by better than two-to-one. G-TOR is not available for KAMs without the enhancement board since EPROM space has been used up. G-TOR is now standard in the KAM-Plus and the Enhancement Board for the KAM (predecessor of the KAM-Plus).

Footnotes:

1. Kantronics Inc., 1202 E 23rd Street, Lawrence, KS, 66046, 913-842-7745, fax 913-842-2021.

2. Towle, Jeff, InterFlex Systems, PO Box 6418, Laguna Niguel CA, 92607. Tel: (714) 496-6639, Fax: (714) 496-8041, BBS: (714)

497-5860 [KaGOLD with Pactor/GTOR support is available from InterFlex Systems]

3. Van Der Westhuizen, Mike, ZS6UP, "A Practical Comparison Between Clover and Pactor Data Transfer Rates," CQ,February, 1994.

4. Military Standard (MIL-STD) series -188-100, containing standards common to long-haul communications, Department of Defense.

Specifically MIL-STD-188-141A, Interoperability and Performance Standards for Medium and High Frequency Radio Equipment.

5. Recommendations of the CCIR, 1990, Volume III. (Fixed Servicesat Frequencies Below About 30 Mhz), Recommendation 520-1,page 28.