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:
The key features of G-TOR are:
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 addition, 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 to be 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.
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
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).
GTOR is a protocol about three times as fast as the most popular TOR mode Pactor and has good reliability, which it gets from
GTOR is gaining some ground in HF data communications, but as it is only available from one manufacturer, it has not taken off as quickly as its benefits would suggest.
It can transmit a full ASCII set and callsigns of up to 10 characters GTOR is a linked mode between one station and one other using a 2.4 second cycle - data frame 1.92 sec and acknowledgement 0.16 sec.
GTOR transmits either 24, 48 or 72 characters depending on baud rate, either 100, 200 or 300 respectively. Errors are detected at the receiver using a CRC-16 checksum. The receiver request new data, a repeat of the last data or parity or a change in baud rate.