PACTOR-II is a fully backward-compatible improvement to the original PACTOR system. It is an adaptive mode that applies different modulation and encoding methods depending on the channel quality. PACTOR-II performs its initial link setup using PACTOR in order to achieve compatibility. An automatic handover to PACTOR-II is made only if both stations are capable of PACTOR operation. While PACTOR uses frequency-shift keying (FSK) modulation, PACTOR-II uses two-tone differential phase-shift keying (DPSK) modulation.
PACTOR-IIs highest data transfer rate without compression is 700 bit/s under optimum conditions, which can provide a maximum effective throughput of up to 1200 bit/s (for text with real-time data compression enabled). PACTOR-IIs improved error control coding enables it to operate on circuits with (S+N)/N ratios as much as 7 dB lower than PACTOR can tolerate.
2. STRUCTURE AND TIMING OF PACTOR-II FRAMES
Similar to PACTOR, PACTOR-II is also a half-duplex protocol that uses Automatic Repeat reQuest (ARQ) to acknowledge each individual data packet with a short control signal (CS). An over must be inserted into the data stream to change direction. The basic PACTOR-II frame structure consists of a header, a variable data field, a status byte and a cyclic redundancy check (CRC). The standard cycle duration for PACTOR-II is the same 1.25 s used by PACTOR, with the same 0.17s idle time (for propagation delay), to maintain interoperability. Since PACTOR-II uses a longer CS of 0.28 s (instead of PACTORs 0.12 s), the packet length had to be shortened to 0.8 s (from PACTORs 0.96 s). The transceiver requirements for transmit delay and receiver recovery time therefore remain the same for PACTOR-II as they are for PACTOR.
PACTOR-II uses six different CSs, each consisting of 40 bits. As in PACTOR, CS1 and CS2 are used to acknowledge/request packets and CS3 forces a break-in. CS4 and CS5 handle the speed changes, and CS6 is a toggle for the packet length.
Due to the signal propagation delay and equipment switching delays PACTOR-II has a maximum range for ARQ contacts of approximately 20,000 km. As with PACTOR, a long-path option is available to enable contacts up to 40,000 km. The sending station must call the receiving station in long-path mode. Initial contact is established using the ordinary PACTOR protocol, but with a cycle time of 1.4 s instead of 1.25 s. This longer cycle time allows for the much greater propagation delays found on long-path contacts. The link then automatically switches to PACTOR-II, with the same cycle duration. A switch between normal and long-path modes requires ending the link and reconnecting. In the new data mode (see below), timing is also automatically adjusted to obtain longer receiving gaps.
Unlike PACTOR, PACTOR-II automatically switches to longer packets if the data blocks are not filled up with idles; i.e., if the transmitter buffer indicates that more information has to be transferred than fits into the standard packets. If the information sending station (ISS) prefers to use long packets, it sets the long-cycle flag in the status word. The PACTOR-II information receiving station (IRS) then finally can accept the proposed change of the cycle duration by sending a CS6. This situation, for example, occurs when reading longer files out of mailboxes. The long packets are basically made up like the short ones, but consist of a larger data field that may contain up to 2208 bits of usable information. The length of these data packets is 3.28 s, which leads to an entire cycle duration of 3.75 s in this data mode.
3. ERROR CONTROL CODING
Effective transmission of data over difficult HF paths requires substantial error control coding (ECC). Full frame interleaving is required for cancelling out error bursts and short fading periods, especially with the longer data packets being used. PACTOR-II uses a convolutional code with a constraint length of 9, a real Viterbi decoder, and soft decision. Due to the high coding gain and resulting capacity of error correction without requesting a repetition of the entire packet, a significant increase in the effective throughput can usually be attained.
ECC requires redundant bits be appended to the data before transmission through a noisy channel. The redundant bits are generated from the original data by applying special rules that depend on the chosen code. The ratio of the number of information bits to the whole length is the code rate.
Two main approaches of ECC can be distinguished: block codes and convolutional codes. Convolutional codes require data interleaving to be effective on channels with burst errors from noise or interference. When applying block codes (such as Golay, Hamming and Reed-Solomon), the message or packet is divided into data blocks. Each block is then encoded separately and forms a code word. Block codes can easily be implemented as they often show a cyclic property and may not require much processing power. Block codes do not require interleaving because of their tolerance for burst errors, thus are efficient for use over HF radio.
Convolutional codes encode the entire message packet and the resulting code words are longer than the original packet. The complexity of a convolutional code mainly depends on the number of tapped shift registers, which work as binary convolvers, and represent the heart of the convolutional encoder. The eight shift registers used in PACTOR-II provide a constraint length of 9. This sets the upper boundary for the achievable coding gain. PACTOR-II uses a Viterbi decoder with soft decision to implement maximum likelihood decoding.
PACTOR-II uses a rate 1/2 convolutional code. Code with higher rates, e.g., rate 2/3 and rate 7/8, are derived by a process called puncturing. Prior to their transmission, certain of the symbols of the rate 1/2 encoded stream are punctured or deleted and not transmitted. At the receiving end, the punctured encoded bits are replaced with null symbols prior to decoding with the rate 1/2 decoder. The decoder treats these null symbols neither as a received 1 nor 0 but as an exactly intermediate value. No information is thus conveyed by that symbol that may influence the decoding process. The major advantage of this approach is that a single code rate decoder (in this case a rate 1/2 decoder) can implement a wide range of codes. In PACTOR-II, the Viterbi algorithm is implemented for decoding the convolutional code.
PACTOR-II provides a more robust Listen Mode than PACTOR because just the short header has to be received correctly to enable use of the ECC. Burst errors may be corrected by monitoring stations. The same speed and encoding levels used by PACTOR-II are also available in its Unproto Mode. On the receiving side, the correct mode is detected automatically.
PACTOR-II uses various DPSK modulation schemes and different code rates, depending on conditions. Differential binary phase-shift keying (DBPSK) is the most robust modulation used by PACTOR-II, so it is used for sending all control signals. If propagation conditions improve, PACTOR-II automatically switches to differential quadrature phase-shift keying (DQPSK) modulation. If conditions improve further, it changes to 8-DPSK and finally to 16DPSK under optimum conditions.
A single-tone 100 bit/s DBPSK signal can transfer 100 bit/s. PACTOR-II uses two-tone DBPSK modulation in its most robust mode, which can be thought of as two single-tone DBPSK signals used together, resulting in a data rate 200 bit/s. This data rate is lowered by the redundancy required in the coding to reduce the error rate, so that the effective throughput becomes 100 bit/s with rate 1/2 coding.
PACTOR II uses different forms of two-tone DPSK modulation in all of its modes and starts using DBPSK modulation at a data rate of 200 bit/s with rate 1/2 coding to provide a throughput of 100 bit/s. The next step uses DQPSK modulation at a data rate of 400 bit/s also with rate 1/2 coding, for a throughput of 200 bit/s. This is followed by 8-DPSK modulation at a data rate of 600 bit/s with rate 2/3 coding, for a throughput of 400 bit/s. Finally, in the best propagation conditions, PACTOR-II uses 16-DPSK modulation at 800 bit/s with a rate 7/8 coding, for a throughput of 700 bit/s. These throughputs are all the maximum uncompressed data transfer rates which are realised only if no packets need to be re-sent because of errors. PACTOR-II automatically selects the modulation and hence the data rate by considering the error repeat history (although this is not a true link quality assessment). When data compression is active, the effective data transfer rates may be considerably higher.
5. ON-LINE DATA COMPRESSION
Both PACTOR and PACTOR-II use an automatic online data compression algorithm that is optimised for text, starting with Huffman encoding. Additionally, PACTOR II uses run-length encoding and pseudo-Markov compression (PMC). Compared to 8-bit ASCII (plain text), PMC yields a compression factor of around 1.9. This leads to an effective speed of about 600 bit/s in average propagation conditions in data mode. PACTOR-II is already around three times faster than PACTOR on average channels. However, the maximum effective speed in good conditions can reach 1200 bit/s. PACTOR-II firmware automatically checks whether PMC, Huffman or the original ASCII code is the best choice. PACTOR-II is also able to transfer and 7-bit ASCII data and other binary information (such as programs, pictures and voice files) which can be split up into 4-bit nibbles by automatically switching off its on-line data compression.
6. SIGNAL CHARACTERISTICS
Similar to PACTOR, the tones of the PACTOR-II signal are spaced at 200 Hz. Their centre frequency may be defined in steps of 1 Hz, by software command, between 400 Hz and 2600 Hz, as long as the shift remains 200 Hz. In the PACTOR-II system, the transferred information is swapped from one channel (tone) to the other in every cycle. This swapping provides resistance to strong narrowband interference (e.g., CW) which might completely overpower one channel, so the signal can still get transferred but at a reduced speed. PACTOR-II signals can be received through filters as narrow as 500 Hz.
This technical description was prepared by Steven L Karty, N5SK.