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

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.