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 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.
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).
GTOR is a protocol about three times as fast
as the most popular TOR mode Pactor and has
good reliability, which it gets from
- 16 bit CRC error detection
- Golay encoding with ARQ for error
detection
- Interleaved data for noise disbursement
- Huffman compression and run length
encoding for improved throughput
- 300,200 OR 100 BAUD TO SUIT VARYING
CONDITIONS
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.
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.
Copyright 1994, Kantronics Co., Inc. All
Rights Reserved. G-TOR is a trademark of
Kantronics Co., Inc. |