PACTOR

1. PROTOCOL

PACTOR can be viewed as a combination of two earlier digital modes, packet radio and AMateur Teleprinting Over Radio (AMTOR). PACTOR provides improved throughput because its transmission speed adapts to the quality of the link and it uses Huffman compressed characters. PACTOR operates over half-duplex links and uses an Automatic Repeat reQuest (ARQ) protocol, acknowledging each individual data packet with a short Control Signal (CS). Some PACTOR implementations provide a Memory-ARQ feature to determine and store the relative strength of each received bit. Copies of corrupted frames stored this way are correlated with frames received later, to provide a coding gain for improved error correction.

2. PACKET LENGTH AND ACKNOWLEDGMENT

PACTOR is a synchronous transmission system with a packet duration of 0.96 second, a CS duration of 0.12 second, and an idle time of 0.17 second for a total cycle time of 1.25 seconds. The idle time is required for turaround procedures and settling, which allows for a maximum distance of about 20,000 km as in AMTOR. Clock reference is crystal controlled with an internal standard to at least 15 X 10-6 accuracy. The initiating station is the Master, and the other station is the Slave. PACTOR subjects each received packet to a Cyclic Redundancy Check (CRC) which triggers an ARQ for packets failing the CRC. The receiving station provides acknowledgment by sending a CS. Repetition of the same CS indicates a request for a packet to be repeated. The CS has a standard length of 12 bits and is always sent at 100 bauds.

3. PACKET COMPOSITION AND BAUD RATE

Packets are either 96 bits long sent at 100 bauds or 192 bits long sent at 200 bauds, with the data rate dependent on conditions. Each packet consists of a Header byte, Data field, and Status byte, followed by the CRC byte given twice. The Header byte consists of the 8-bit pattern for 55 hexadecimal and is used for synchronization, MemoryARQ, and listen mode. The Data field contains 64 bits if sent at 100 bauds or 160 bits if sent at 200 bauds. Its format is normally Huffman-compressed ASCII, with conventional 8-bit ASCII as the alternative. The Status byte provides the packet count, data format (whether standard 8-bit ASCII or Huffman-compressed ASCII), break-in request, and QRT bit, for a total of 8 bits. The CRC calculation is based on the ITU-T polynomial xE16+xE12+xE5+1. The CRC byte is calculated for the whole packet starting with the data field, without Header, and consists of 16 bits. There are four different Control Signals, identified as CS1, CS2, CS3, and CS4, the functions of which are explained below.

4. LINK INITIALIZATION

To initiate a PACTOR connection, the Master station sends a special synchronization packet which contains the standard Header byte followed by the call sign (address) of the Slave station in both a 100-baud and a 200-baud bit pattern. (Each address field allows for up to eight characters, with the character 0F hexadecimal following the call sign in each unused space.) This allows the 200-baud bit pattern to determine the quality of the channel: The Slave responds with CS1 (4D5 hexadecimal) if the 200-baud bit pattern was received without error, or CS4 (D2C hexadecimal) if not, which leads to an instant reduction of data rate to 100 bands. After receiving the first CS1 or CS4 from the Slave, the Master sends the first data packet with Header=AA hexadecimal and packet count=1. System specific data, including the Master call sign, is sent automatically at the beginning. If the Slave is busy, it can both acknowledge and reject a connection by sending one CS2 (AB2 hexadecimal) each time it receives a correct synchronization pattern. The Master terminates its connect request after receiving CS2 twice in succession.

5. CHANGING SPEED

The decision regarding a speed change is made at the receiving end, by automatically evaluating the data input rate and packet statistics including error rate and number of retries. The receiving station transmits CS1 (acknowledge) following each correctly received packet, or CS4 (speed change request) following receipt of a bad 200-baud packet. The data contained in each unacknowledged 200-baud packet is automatically repeated at 100 bauds. This repetition requires several 100-baud packets because of the smaller Data field. If the receiving station acknowledges a correctly received 100-baud packet with CS4, the transmitting station sends the next packet at 200 bauds. If the following 200-baud packet is not acknowledged after an operator-selectable number of attempts (normally two), the speed is automatically set back to 100 bauds.

6. CHANGING DIRECTION AND ENDING CONNECTION

The receiving station can change to transmit by sending CS3 (3413 hexadecimal) as a break-in request at the head of its first data packet. At the end of a connection, special end of contact (QRT) synchronization packets are transmitted which contain the receiver address in the reversed order. This process is repeated until the sending station has received the acknowledgement.

7. ASCII CHARACTERS AND HUFFMAN COMPRESSION

PACTOR normally uses ASCII characters that have been compressed with a Huffman algorithm. This Huffman compression reduces the average character length for improved efficiency. The Annex shows the Huffman compressed equivalent of each ASCII character used in PACTOR, with the least significant bit (LSB) given first. The length of individual characters varies from 2 to 15 bits, with the most frequently used characters being the shortest. This results in an average character length of 4 to 5 bits for English text, instead of the 8 bits required for normal ASCII.

8. SIGNAL CHARACTERISTICS

PACTOR uses frequency-shift keying (FSK). With the recommended frequency shift of 200 Hz, PACTOR can be received through a filter with a bandwidth as narrow as 600 Hz.

9. PACTOR HUFFMAN COMPRESSION

CharASCIIHuffman
(LSB [sent first] on left)
space3210
e101011
n100101
i1051101
r1141110
t11600000
s11500100
d10000111
a9701000
u11711111
l108000010
h104000100
g103000111
m109001011
<CR>13001100
<LF>10001101
o111010010
c99010011
b980000110
f1020000111
w1190001100
D680001101
k1070010101
z1221100010
.461100100
,441100101
S831111011
A6500101001
E6911000000
P11211000010
v11811000011
O4811000111
F7011001100
B6611001111
C6711110001
I7311110010
T8411110100
O79000101000
P80000101100
149001010000
R82110000010
(40110011011
)41110011100
L76110011101
N78111100000
Z90111100110
M77111101010
9570001010010
W870001010100
5530001010101
y1210001010110
2500001011010
3510001011011
4520001011100
6540001011101
7550001011110
8560001011111
H720010100010
J741100000110
U851100000111
V861100011000
<FS>281100011001
x1201100011010
K751100110100
?631100110101
=611111000010
q1131111010110
Q811111010111
j10600010100110
G7100010100111
-4500010101111
:5800101000111
!3311110011101
/4711110011110
*42001010001100
34110001101100
%37110001101101
39110001101110
95111100001100
&38111100111001
+43111100111110
>62111100111111
@640001010111000
$360001010111001
<600001010111010
X880001010111011
#350010100011011
Y8900101000110101
;5911110000110100
\9211110000110101
[91001010001101000
]93001010001101000
<DEL>127110001101111000
~126110001101111001
}125110001101111010
|124110001101111011
{123110001101111100
96110001101111101
^94110001101111110
<US>31110001101111111
<GS>29111100001101100
<ESC>27111100001101101
<EM>25111100001101110
<CAN>24111100001101111
<ETB>23111100001110000
<SYN>22111100001110001
<NAK>21111100001110010
<DC4>20111100001110011
<DC3>19111100001110100
<DC2>18111100001110101
<DC1>17111100001110110
<DLE>16111100001110111
<RS>30111100001111000
<Sl>15111100001111001
<SO>14111100001111010
<FF>12111100001111011
<VT>11111100001111100
<HT>9111100001111101
<BS>8111100001111110
<BEL>7111100001111111
<ACK>6111100111000000
<ENQ>5111100111000001
<EOT>4111100111000010
<ETX>3111100111000011
<STX>2111100111000100
<SOH>1111100111000101
<NUL>0111100111000110
<SUB>26111100111000111

PACTOR REFERENCES

Helfert, Hans-Peter, and Ulrich Strate: PacTOR Radioteletype with Memory ARQ and Data Compression, QEX, American Radio Relay League, Newington, CT, October 1991, pp. 3-6.

Horzepa, Stan: PacTOR: Better HF Data Communications for the Rest of Us?, QST, American Radio Relay League, Newington, CT, February 1993, p. 98.

Rogers, Buck: PacTOR - The New Frontier, CQ, CQ Communications, Hicksville, NY, July 1993, pp. 88-95.

Van Der Westhuizen, Mike: A Practical Comparison Between Clover and Pactor Data Transfer Rates, CQ, CQ Communications, Hicksville, NY, February 1994, pp. 40-42.

See also: http://www.scs-ptc.com.

ACKNOWLEDGEMENT

This technical description was prepared by Steven L Karty, N5SK.