PACTOR - Short system description
System Details Pactor Operation Memory ARQ
PACTOR (PT), specially designed for operation in noisy and fluctuating
channels, is an improved half-duplex synchronous ARQ system combining the
reliability of PR with the fixed AMTOR time frame.
Principal design considerations
PACTOR comprises all important AMTOR or PR (2-way) characteristics:
o fixed timing structure and full synchronism to ensure maximum speed
o fast and reliable changeover / break-in
o required bandwidth less than 600 Hz
o 100% ASCII compatible (true binary data transmission)
o extremely low probability of undetected errors (16 bit CRC)
o independent of shift polarities
o no multi-user overhead in a narrow-band channel
o inexpensive hardware (Z80 single-board)
o high operational comfort (built-in message storage system, etc.)
o listen-mode (monitor)
o FEC-mode (CQ-transmissions etc.)
As a novelty in Amateur RTTY, some additional powerful features have been
o optimal coherent mode, i. e. system clocks locked to frequency
standards (e.g. DCF77, TV deflect ion signals and other high precision
o online data compression (Huffman coding)
o automatic speed change (100/200 bps) without loss of synchronization
o fully acknowledged link termination (no QRT-timeout required)
o memory ARQ (even noisy packets can be restored)
II. System Details
The basic PT transmission frame is very similar to AMTOR; blocks (packets)
containing data information are acknowledged by short control signals (CS)
sent out by the receiving station.
Shift levels are toggled with every cycle in order to support memory ARQ
(see below). Since the shift polarity is clearly defined at
synchronization time, any conventions concerning 'mark/space' become
* cycle duration : 1.25 sec
* packets : 0.96 sec = 192 (96) bits at 200 (100) bps
* control signals: 0.12 sec = 12 bits, each 10 mS long
* CS-receive gap : 0.29 sec
Change of transmission speed only alters the internal packet structure; all
other timing parameters remain constant.
General packet structure:
/header/..20 (8) data bytes at 200 (100) bps../status/CRC/CRC/header :
This byte enables fast synchronization and delivers auxiliary
information (memory ARQ, listen mode)
data : arbitrary binary information
status : system control byte (2 bit packet number, tx-mode, break-in
CRC : 16 bit cyclic redundancy check based on CCITT polynomial
X^16+x^12+x^5+1, calculated over the entire packet (except header)
3. Control signals (CS)
Four CS are used. As a compromise between reliability and fast detection, a
CS length of 12 bit was chosen.
CS1: 4D5 CS2: AB2 CS3: 34B CS4: D2C (all hex numbers, LSB right)
The mutual Hamming distance is 8 bit, thus minimizing the chance of
receiving a false CS. CS1/2 and CS3/4 form symmetrical pairs (bit reverse
patterns). CS1..3 have the same function as their AMTOR counterparts; CS4
serves as the speed change control. In contrast to AMTOR, CS3 is transmitted
as head portion of a special changeover packet (see below).
4. Pactor Operation
The calling station ('master') sends special synchronization packets: /head
(100 bd)/..address (8 bytes, 100 bd)../..address (8bytes, 100 bd) Normally,
the receiver only uses the 100-bps-section to achieve a fast
synchronization. The 200-bps-section supplies additional information about
the channel quality: if it is received correctly, the first CS will be CS4,
otherwise CS1 is sent. After in turn having synchronized a CS4 or CS1, the
master will continue with sending normal data packets at 200 or 100 bps,
respectively. The first transmitted characters contain the 'system level
number' (PACTOR software-version), followed by the master address
5. Changing the transmission direction
Similar to AMTOR, the receiving station (RX) can change the transmission
direction whenever it has received a valid packet. For this purpose a
special changeover-packet is transmitted, starting at the CS time frame.
The transmitting station (TX) will switch to RX mode immediately after it
has received the CS3 which forms the first section of the changeover-
packet. It then reads in the rest of that packet and transmits a CS (CS1
and CS3 = acknowledge, CS2 = reject) timed at the last three bytes of the
former packet frame.To force a break in, the TX sets the BK-status-bit
(this corresponds to AMTOR '+ ?').
Speeddown only being useful in poor conditions or at low data input rates
(e. g. manual typing), both directions are treated unsymmetrically.
The RX may request speeddown after any incorrectly received packet by
sending CS4, which immediately forces the TX to build up 100-bps-packets
(any unconfirmed 200 bps information is repeated at low speed).
Any valid packet may be confirmed with CS4, forcing a TX speedup. In case
the following high-speed-packet is not acknowledged after a number of
tries, the TX will automatically perform a speeddown. (For more details,
refer to 'PT-Handbook' by WAA Research Group).
7. Termination of a PACTOR contact
Cutting an ARQ link inevitably leads to the problem that information has to
be transmitted without final acknowledgment (Second WAA theorem). PT
applies special QRT packets, providing an expensive but rather effective
solution. These packets contain an active QRT status bit and he RX address
in byte-reverse order (low speed pattern). If this address is found during
the standby synchronization procedure, the RX responds with a single
transmission of the final CS (The timing relations before stby are stored).
This method will always guarantee a well-defined QRT.
8. Data Compression
Character frequency analysis of typical english or german texts shows that
the average amount of information per character does not exceed 4 bits. For
that reason, ASCII text transmissions often carry a redundancy of 50%,
which could be avoided by using a variable length code matched to the
character distribution.The most popular example of such a code is the Morse
code; PACTOR data compression mode applies Huffman coding with nearly
optimum efficiency, yielding up to 100% speed gain. Every packet contains a
compressed data string; character code lengths vary from 2 to 15 bits.
9. Memory ARQ
In conventional ARQ systems the TX has to repeat a packet until it has been
received completely error-free. It is evident that the probability of
receiving a complete packet dramatically decreases with lower S/N ratio.
The only way to maintain the contact in that case is to shorten packet
length and/or to apply error correcting codes which in turn will greatly
reduce maximum traffic speed when conditions are good. The method chosen by
WAA Research Group is to sum up corresponding bit samples of subsequent
packets and to test if the mean value (reduced to a 0/1-decision) passes
the CRC. To keep quantizing errors small, the samples are taken from the
FSK-demodulator low-pass-filter output by means of an 8-bit AD-converter.
Assuming white Gaussian noise, this accumulation method - also known as
'memory ARQ' - will obviously converge even at a WA4EGT, QRA WA2MFY/SYS1:
low S/N ratio. Furthermore, since shift levels are toggled with every
transmission, constant interfering signals within the receiver passband
will not affect the resulting mean value. To prevent accumulation of old
request packets, the header is inverted with every new information packet,
thus serving as a RQ indicator (similarity test).
10. Listen Mode (Monitor)
This mode resembles Packet Radio monitoring: the receiver scans for valid
packets which are detected by CRC match. This 'brute force' method was
chosen in order to ensue maximum flexibility, although it consumes a
considerable amount of the available CPU capacity.
11. FEC Transmissions
CQ and bulletin transmissions are supported by means of a special non-
protocol mode. Packets are transmitted with one or more repetitions; the CS
receive gap is omitted. Since the listen mode does not require
synchronization, the transmitting station possesses great freedom of
selecting packet repetition rate and speed.
12. Practical Aspects
The first PACTOR programs were running on 'breadboarded' Z80 singleboard-
computers. These early experiments led to the development of a stand-alone
'PACTOR- Controller' with built-in modem and tuning-display. The conventional
operating modes BAUDOT and AMTOR were added in order to maintain
compatibility and - what might be more interesting - to allow easy
comparisons. Assuming typical conditions, PACTOR traffic can be expected to
run 4 times faster than over a AMTOR link.
Structure and Timing of the PACTOR-II Frames
Speed Levels and Error Control Coding
On-line Data Compression
Some Practical Aspects
All new modes should provide significant improvements over existing
systems, which must not only refer to the maximum throughput and the
robustness. Other basic attributes like signal bandwidth, required
frequency accuracy and compatibility to existing standards also have to be
taken into consideration.
Modulation and encoding methods that supply high throughput rates, e.g.
16-DESK, normally suffer from a lack of robustness. On the other hand,
systems distinguished by a high robustness, e.g. DBPSK combined with a rate
1/2 convolutional code, only provide a low maximum throughput. Therefore,
adaptive digital modes have to be used, that apply different modulation and
encoding methods depending on the channel quality. Just changing the symbol
rate however, leads to only little adaptivity and additionally results
variations of the bandwidth. In order to prevent any spill over in adjacent
channels, the bandwidth should ideally always remain the same, regardless
of whether a robust or a fast data transmission is performed. As 500 Hz CW
filters are very commonly used and due to the usual spacing of the mailbox
frequencies on short wave, a maximum bandwidth of 500 Hz should not be
exceeded. In addition, there should not be too high a demand placed the
transceiver used, regarding its frequency adjustment and stability. For
optimum results, maximum frequency deviations similar to FSK modes should
be tolerated. This forces the use of powerful tracking methods, which allow
a link also to be established the deviation is up to +/- 80 Hz. Further, a
new mode should be backwards compatible an existing standard, preferably
with automatic switching, in order to prevent a deficiency of QSO partners
in the early stage.
PACTOR-II meets all the above mentioned requirements. It is fully backwards
compatibility with the current PACTOR standard, as the initial link setup is
still done in FSK. If both stations are capable of Level II, an automatic
switching is performed. The PACTOR protocol basically uses a two-tone DESK
system with raised cosine pulse shaping, which reduces the required
bandwidth to less than 500 Hz. The maximum absolute transfer rate is 800
bits per second. Due to the improved on-line data compression, maximum
effective throughput rates of more than 1200 bits per second can be
obtained. PACTOR-II is thus the fastest short wave digital mode. Very
efficient error control coding using a convolutional code with a constraint
length of 9 and a real Viterbi decoder with soft decision applied at all
speed levels, in addition to analog Memory-ARQ. PACTOR-II is also
therefore, by far the most robust digital mode, which allows a link to be
established a achieve a reasonable throughput in such poor propagation
conditions that all other modes fail. In comparison with the current FSK
PACTOR standard including analog Memory ARQ, which had been the most robust
digital mode until the release of PACTOR-II, a further gain of robustness
of around 8 dB could be obtained. The following chapters describe some
details of the PACTOR-II protocol.
II. Structure and Timing of the PACTOR-II Frames
Similar to the current FSK PACTOR standard, PACTOR-II is also a half-duplex
synchronous ARQ system without any mark/space convention. It may thus be
operated in USB as well as LSB position of the transceiver. The initial
link setup is still performed using the FSK (PACTOR-I) protocol, in order
to achieve compatibility to the previous level. If both stations are
capable of PACTOR-II, an automatic switching to the higher level is
performed. The basic PACTOR-II frame structure is similar to PACTOR-I. It
consists of a header, a variable data field, the status byte and the CRC.
The standard cycle duration does not differ from FSK PACTOR and is still
1.25 seconds, which is one of the requirements to obtain easy compatibility
to Level I. Longer Control Signals (CS) had to be applied to achieve a
higher robustness for the acknowledgment signal, required due to the
greater robustness of the data channel. The entire length of the standard
packet had to be shortened to 0.8 seconds in order not to shorten the
maximum possible propagation delay, which is thus still 170 milliseconds.
The requirements to operate PACTOR-II regarding the transmit delay and the
receiver recovery time of the used equipment therefore remain unchanged in
comparison with Level I. Due to the signal propagation delay, and equipment
switching delays, PACTOR-II as well as PACTOR-I has in the standard mode a
maximum range for ARQ contacts of around 20,000 km. As with PACTOR-I, a
long path option is available also for PACTOR-II enabling contacts up to
40,000 km. The sending station calls ~~ partner station in 'Long Path
Mode'. Initial contact is established using the PACTOR-I FSK protocol as
previously mentioned, but with a cycle time of 1.4 seconds instead of 1.25.
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. In the new data mode (see below), timing is
also automatically adjusted to obtain longer receiving gaps. Unlike the
previous level, PACTOR-II additionally 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 fitting 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
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,
which may contain up to 2208 bits of usable information. The length of
these data packets is 3.28 seconds, which leads to an entire cycle duration
of 3.75 seconds in this so-called data mode. Figure 1 shows the PACTOR-II
cycle duration and the packet construction in the standard mode as well as
in the data mode. When entering text manually in QSO traffic from operator
to operator, the maximum throughput of the standard mode is normally not
used up, thus the required higher flexibility of the system is still
available due to the short packets. The efficient use of longer data
packets on short wave is generally only possible, if powerful error control
coding, with full frame interleaving is applied to cancel out error bursts
or short fading periods. As already mentioned, PACTOR-II uses a
convolutional code with a constraint length of 9, a real Viterbi decoder
and soft decision, in addition to analog Memory-ARQ. Due to the high coding
gain and the resulting capacity of error correction without requesting a
repetition of the entire packet, a significant increase in the effective
throughput could be obtained. Proceeding from average bit error rates on
short wave channels, simple block codes are usually unable to provide
enough coding gain. This often leads to a decrease in speed when using
longer data strings, as repetitions often cannot be avoided.
PACTOR-II uses six different CS, each consisting of 40 bits, all having
exactly the maximum possible mutual hamming distance of 24 bits to each
other. They thus reach exactly the Plotkin boundary and also represent a
perfect code. This allows the advantageous use of the Cross Correlation
method for decoding, which is also a kind of soft decision,leading to the
correct detection of even inaudible CS. This checking is not only confined
to a simple binary principle. A complex analog test procedure is applied,
using the fine detail data from the DSP, to evaluate the single CS
received, as well as the information summed up in the Memory-ARQ buffer.
Similar to Level I, CSl 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. All CS are always sent in DBPSK in order to
obtain a maximum of robustness.
III. Speed Levels and Error Control Coding
As mentioned in the introduction, PACTOR-II uses a two-tone DPSK modulation
system Due to the raised cosine pulse shaping, the maximum required
bandwidth is only around 450 Hz at minus 50 dB. ASK, which was also tested
in the early stage, provided poorer results in weak conditions compared
with a higher DPSK modulation, as different amplitude levels are more
difficult to distinguish in noisy channels than more phase levels.
Additionally, ASK increases the Crest Factor of the signal. For these
reasons, it is not used in the final PACTOR-II protocol. Basic information
on these items can also be found in the first part of this series.
PACTOR-II uses instead, different DPSK modulation schemes and various code
rates The Crest Factor of the PACTOR-II signal is therefore only 1.45. The
basic code used is an optimum rate 1/2 convolutional code with a constraint
length of 9. Codes with higher rates, e.g. rate 2/3 and rate 7/8, can be
derived from that code: by so-called puncturing prior to the transmission,
certain of the symbols of the rate 1/2 encoded stream are 'punctured' or
deleted. and not transmitted. 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 as 'O', but as an exactly intermediate value. No information is thus
conveyed by that symbol that may influence the decoding process. The coding
performance of 'punctured' code operation nearly matches the coding
performance of the best known classic rate 2/3 or 7/8 codes with a
comparable constraint length, provided that the puncture pattern is chosen
carefully. The major advantage of this approach is that a single code rate
decoder (in our case a rate 1/2 decoder) can implement a wide range of
codes. In the PTC-II, the Viterbi algorithm is implemented for decoding of
the convolutional code. Nevertheless, there are several different methods
to decode the PACTOR-II signal, which require less processing power, but in
return for this, also provide less coding gain. However, these methods at
least allow compatibility to the PACTOR-II standard and may therefore be
applied in cheaper hardware. The most robust PACTOR-II speed level employs
DBPSK with rate 1/2 coding, which per cycle allows an absolute throughput
of 5 bytes in the standard mode and 36 bytes in the data mode respectively.
In the next step, DQPSK with rate 1/2 coding is applied, which leads to an
absolute throughput of 14 bytes in the standard mode and 76 bytes in the
data mode. This is followed by 8-DPSK with a rate 2/3 coding, providing a
throughput of 32 and 156 bytes per packet, respectively.
Finally, in best propagation conditions, PACTOR-II applies 16-DPSK with a
rate 7/8 coding, which allows the maximum throughput of 59 bytes in a short
packet and 276 bytes in the data mode. The mentioned transfer rates are all
net rates referring to 8-bit ASCII, which are calculated after the error
control coding and all other protocol overhead. As data compression is
usually active, these throughput rates must be multiplied by the
compression factor. The effective speed is therefore considerably higher in
practice. All throughput rates and the corresponding modulation and
encoding methods are summarized in table 1. (Not attached)The speed levels
are automatically chosen by the PTC-II, considering the link statistics and
the actual channel quality, thus no user intervention is required.
IV. On-line Data Compression
Like in the previous FSK PACTOR system, automatic on-line Huffman data
compression is applied. Additionally, PACTOR-II uses run-length encoding
and, as a further novelty, Pseudo-Markov Compression (PMC, see below).
Compared to 8-bit ASCII (plain text) PMC yields a compression factor of
around 1 .9, which leads to an effective speed of about 600 bits per second
in average propagation conditions in data mode. PACTOR-II is already around
3 times faster than PACTOR-I and 15 times faster than AMTOR on average
channels. However, the maximum effective speed in good conditions can
exceed 1200 bits per second. As the PTC-II firmware automatically checks,
whether PMC, Huffman encoding or the original ASCII code is the best
choice, which depends on the probability of occurrence of the characters,
there is no risk of losing throughput capacity. PACTOR-II is of course
still able to transfer any given binary information, e.g. programs or
picture- and voice files. In these cases the on-line data compression is
automatically switched off. Ordinary Huffman compression exploits the
'one-dimensional' probability distribution of the characters in plain
texts. The more frequently a character occurs, the shorter has to be the
Huffman symbol that is assigned to the actual character. On the other hand,
Markov compression can be considered as a 'double' Huffman compression,
since it not only makes use of the simple probability distribution, but of
the 'two-dimensional' probability. For each preceding character, a
probability distribution of the very next character can be calculated. For
example, if the actual character is 'e', it is very likely that 'i' or 's'
occurs next, but extremely unlikely that an 'X' follows. The resulting
probability distributions are much sharper than the simple one-dimensional
distribution and thus lead to a considerably better compression.
Unfortunately, there are two drawbacks: Since for each ASCII character a
separate coding table is required, the entire Markov coding table becomes
impractically large. Additionally, the two-dimensional distribution and
thus also the achievable compression factor depends much more on the kind
of text than the simple character distribution. We have therefore chosen a
slightly modified approach which we called Pseudo-Markov Compression,
because it can be considered as a hybrid between Markov- and Huffman
encoding. In this variant, the Markov encoding is limited to the 16 most
frequent 'preceding' characters. All other characters trigger normal
Huffman compression of the very next character. This reduces the Markov
coding table to a reasonable size and also makes the character
probabilities less critical, since especially the less frequent characters
tend to have unstable probability distributions. Nevertheless, for optimum
compression, two different tables for English and German texts are defined
in the PACTOR-II protocol and automatically chosen by the PTC-II.
V. Some Practical Aspects
Similar to Level I, the tones of the PACTOR-II signal are spaced at 200 Hz.
Their frequency may be defined freely in steps of 1 Hz by software command,
as long as the shift remains 200 Hz. Thus you can easily switch between
high- and low-tones, and also adjust any additionally required tone pair.
This allows the utilizing of narrow CW filters in all transceivers that
provide the option of activating the corresponding filters in the SSB mode.
In the PACTOR-II system, the transferred information is swapped from one
channel (tone) to the other in every cycle. Unlike FSK systems, the link is
thus not blocked when strong narrow band QRM completely overpowers one
channel (e.g. CW or carriers), but only its maximum speed is reduced. Usual
FSK systems with mark/space convention and without Memory-ARQ have to fail
in such cases, because even if a so-called 'space-only' mode is applied,
the strongest signal is automatically chosen. This always leads to
break-down of the link, as the QRM is stronger than the useful signal in
the proposed case PACTOR-II provides a comprehensive Listen-Mode, which is
much more robust than known from PACTOR-I, because just the short header
has to be received correctly, then the powerful error control coding can be
fully utilized. Burst errors may be corrected also by monitoring stations
and thus virtually do not affect the performance. The Unproto-Mode in
PACTOR-II allows to choose between all the above mentioned speed and
encoding levels. On the receiving side, the correct mode is detected
automatically and therefore needs no user-adjustment. For example, a fast
and very robust QTC mode can thus be achieved, when a message is
transmitted in the Unproto-Mode using DBPSK with rate 1/2 coding.
PACTOR-III is the newest generation HF data transmission mode developed by
SCS in Hanau, Germany. SCS invented PACTOR and in 1995 followed with the PACTOR-II
mode. PACTOR-I and II modes are supported by SCS manufactured PTC modems, the PTC-II,
PTC-IIe and PTC-IIpro. After PACTOR-III was released on May 1, 2002, current PTC
modems are now upgradable to use PACTOR-III via a software update.
Current PTC modems are now upgradable to use PACTOR-III via a software update.
To use PACTOR-III both transmitting and receiving stations must support PACTOR-III.
If you are a mobile station transmitting to a land based station both mobile and
land stations must be in PACTOR-III mode in order to benefit from the higher data
rates III mode offers.
Uses a voice channel of 2.4khz and with an optimal link, is 4 to 5 times faster
than PACTOR-II mode. All current SCS hardware (PTC-II,PTC-IIe and PTC-IIpro) are
upgradable to Level III mode via a firmware update. PACTOR-III applies 6 different
"speedlevels", depending on the actual signal conditions. Switching between the
submodes is fully automatic.
After protocol overhead, PACTOR-III achieves an effective throughput of up to
2722 Bit/s without compression. If plain text is transmitted, the built-in Pseudo
Markov compression allows an effective throughput of up to 5200 Bit/s. The crest
factor varies between 2.7 and 4.7 dB depending on the actual speed level. PACTOR-III
utilizes a novel crest factor reduction method yielding a very low crest factor
compared to other multi-carrier modulation schemes.
Figure 1. Structure and timing of the Pactor-II frames.
This information was obtained from the SCS PTC-II web site
and Griff's NB6Z web site.
The following is an overview of some tests that I (AE4TM) recently conducted to compare the
relative performances of Pactor-1,2,3, AMTOR, RTTY, and PSK-31 to each other under a
wide range of S/N (signal to noise) ratios. Before these tests were started, two initial
checks were conducted to rule out any potential errors that might arise from a misaligned
IF receiver Pass-Band and excessive audio output being fed to the PTC-II. First,
the receiver Pass-Band Tuning control was varied over a slight range to determine
the positions needed for maximum transfer speeds for different IF filter configurations.
Second, the effective data rates were measured at different audio gain levels to
determine if excessive audio output to the PTC-II were slowing the effective data
rates. In addition to these tests, the effect of the AGC speed and noise blanker on
the transfer speeds were measured over a wide range of S/N ratios and the results
indicated that a FAST AGC with the noise blanker turned ON (when the engine is idling)
provided the fastest average speeds. These experiments then set the stage for a
comprehensive distance test using a link between my mobile station and home base
station for different modes. I found the data very helpful for my own needs and as
such I wish to present them to other Amateurs interested in these digital modes
One comment regarding file compression. These speed tests were made by transferring
binary files between my two stations. Binary data was chosen for the tests because
it disables the compression algorithms built into the PTC-II so that a more accurate
relative comparison could be made between the pactor modes. As a result, the effective
data rates shown in the figures below are modestly slower than the physical data
rates observed if either ASCII data or Winlink 2000
b2 "precompressed" data were sent to the PTC-II. In both these scenarios, the physical
data rates run about 44% faster than what the figures indicate below.
I personally cannot thank the SCS Team enough for bringing Pactor-1/2/3 to us. It
is a marvel of engineering and has brought much enjoyment to many in our ham radio
hobby along with many others that have put it to very good use around the world.
Figure 2A. The figure above illustrates the effect of the IF passband
tuning on the relative data rates of pactor-2 during transfers of binary files between a
mobile IC-706 and a base station IC-746 having 500Hz CW IF filters placed in the SSB
filter slots. The IC-706 has a single 500Hz filter whereas the IC-746 has two 500Hz IF
filter slots in series-one at the 9MHz stage and the other at the 455khz stage. The
red data represent the relative transfer speeds for various tuning positions of the
500Hz filter in the mobile IC-706. The blue data represent the effect of the tuning
position of the IC-746 9MHz 500Hz filter on the transfer speed of the same data.
Finally, the green data represent the effect of the tuning for the IC-746 455kHz 500Hz
filter on the transfer rate for this data. For each set, Gaussian curves were fit
to the data as shown. This experiment was conducted to illustrate the necessity of
very careful calibrations of the IF passbands in experiments which compare the relative
speeds of the various HF data transfer protocols which use a narrow IF filter.
Figure 2B. In contrast to Figure 2A, the figure above
illustrates the effect of the IF passband tuning on the relative data rates of pactor-3
during transfers of binary files between a mobile IC-706 and a base station IC-746
having 2.4kHz SSB IF filters placed in the optional filter slots. In these tests, both
transceivers have a single 2.4kHz IF filter at the 9MHz stage only. The red data
represent the relative transfer speeds for various tuning positions of the 2.4kHz
filter in the mobile IC-706 whereas the blue data represent the effect of the tuning
position of the IC-746 9MHz 2.4kHz filter on the transfer speed of the same data.
For both sets, Gaussian curves were again fit to the data. Similarly, this experiment
was conducted to illustrate the necessity of very careful calibrations of the IF
passbands in experiments which compare the relative speeds of the various HF data
transfer protocols which use a 2.4kHz SSB IF filter.
Figure 3. This figure illustrates the effect of transceiver
audio volume output to the SCS PTC-II on the relative data rates of pactor-2 with both a
2.4kHz SSB IF filter (red) and 500Hz CW IF filter (blue).
This test was conducted to confirm that the PTC-II A/D circuitry is not being overdriven
leading to errors and overall lower effective data rates. According to the PTC-II
manual, the PTC can operate with inputs up to 1VRMS and the data indicated
that the station was properly adjusted.
Figure 4. This figure illustrates the effect of different signal
strengths on the Internal Runtime Delays (IRD) of the two ICOM transceivers used to
compare the different pactor levels shown in final figure. The time delays shown
against the y-axis represent the sums of the RF time delays passing through both HF
transceiver IF stages. The data were obtained by connecting between the two transceivers
at various distances up to nine miles on 10 meters but recorded as a function of the
received signal strengths in s-units instead of distance along the x-axis. For higher
accuracy, fifteen connects were averaged for each s-unit value with the standard
deviations shown as error bars along the vertical direction. Furthermore, the time
delays due to the finite speed of light (186 miles/mS) were subtracted from the IRD
values at each s-unit value. The data indicate relative insensitivity of the signal
strengths on the time delays except for very strong signals (over S10) where the curve
bends upwards towards longer time delays. Here time delay increases begin to approach
the internal resolutions of the PTC-II of 0.625mS suggesting that in very strong
signals the automatic gain feedback in the IF stage may be "pulsing" the attenuator
during the connection causing doppler shifting in the pactor data between the two
transceivers. If such effects do occur, the maximum pactor exchange speeds may not
be achieved. Finally, it is important to point out that these effects probably vary
greatly between various HF transceivers but unfortunately these data are not included
as standard tests for digital compatibility by the manufacturers except in the military
specified transceivers such as the Rohde and Schwarz.
Table 1. The data above illustrate the effect of the Automatic
Gain Control (AGC) and the Noise Blanker (NB) on the relative Pactor-2 transfer speeds
averaged over a wide range of S/N ratios. In each run, both transceiver settings
were adjusted to the selections shown and two hours of binary file transfers were
averaged on 80 meters with the engine off in the mobile station. In short, AGC set
to FAST and Noise Blanker set to OFF provided the fastest transfer speeds under
these conditions. The next figure shows the effect of ignition noise on the transfer
rates with the engine running.
Figure 5. The figure above shows the effect of engine RPM on
effective data rate of Pactor-2 on 40m. The blue/green data indicate the data rates
with the noise blanker turned ON whereas the orange/red data indicate the data rates
with the noise blanker turned OFF. Furthermore, a 500Hz CW IF was used for the blue
and orange data sets and a SSB IF was used for the green and red data sets. Except
for when the engine was OFF, the noise blanker improved the throughput of data via
the pactor-2 mode for all RPM ranges. Therefore, the use of a high quality noise
blanker is very useful to any mobile station that intends to have an engine running.
(Note: some noise blankers distort RF signals potentially lowering the actual throughput;
therefore, I recommended that you actually test your specific noise blanker
before making the final decision to use the noise blanker.
Figure 6. The figure above depicts the relative speeds of Pactor-1/2/3,
Amtor ARQ, PSK-31, and RTTY (45 Baud) as a function of relative signal strength.
These data were obtained by transferring binary files* (no compression) between a
mobile Pactor-3 and base Pactor-3 station on 80m during the daytime. This band was
chosen because of its low use (hence low QRM) and lack of "picket fencing" seen on
the higher frequencies during the daytime. Furthermore, during the daytime, these
80m connects were determined to be ground waves from their lower slave response times
(SRT) as compared to sky-waves. The red, green, and blue data illustrate the relative
speeds of Pactor-3, Pactor-2, and Pactor-1, respectively, as a function of distance
between these two stations. As the pactor level increases, the relative performance
increases with Pactor-3 being far superior to any mode ever developed for the HF
spectrum. In these three runs, binary files were transferred so that the built-in
compression algorithms were disabled. Therefore, when transferring ASCII data which
gets compressed by the PTC-II modem or
b2 data which is already compressed before reaching the PTC-II, the net data compression
further increases the relative throughput by ~44% over those shown on the figure
above. The black data illustrate the performance of the Amtor ARQ mode, the orange
data illustrate the performance of the 50+ year old 45 baud RTTY mode, whereas the
grey data illustrate the very popular PSK-31 mode.** In these last three data runs,
the data simply illustrate the transfer speed of legible ASCII data. Unlike pactor,
RTTY, Amtor, and PSK-31 are not 100% error free and the actual transferred files
are found at the following three links:
RTTY screen dump,
AMTOR screen dump,
and PSK-31 screen dump.
In all the runs above, both transceivers were configured with 2.4kHz crystal SSB
*, ASCII was used for RTTY, Amtor, and PSK-31.
**, To my initial surprise, RTTY outperformed PSK-31 at all S/N ratios. However,
this is not unexpected when one realizes that PSK-31 utilizes a raised cosine wave
in the time domain instead of the frequency domain. From standard DSP textbooks,
this selection leads to a bad impulse response making an ISI-free matched filter
design impossible. As a result, a loss of around 0.5-1 dB compared to the ideal design
occurs. In addition, RTTY has a crest factor of 0 dB compared to a crest factor of
>1.5 dB for PSK-31 when information is transferred. Furthermore, the low data rate
this DPSK mode utilizes is quite susceptible to fading and fading in turn generates
Doppler spread errors, i.e. frequency/phase uncertainties.
Figure 7. Technical description combined with that of Figure 8 below.
Figure 8. On March 4, 2006, the digital mode comparison tests
were repeated in the field in the same exact manner as in the Spring of 2002 but using
the latest Pactor 3.6q firmware. The location for these tests was San Bernardino county
in Southern California. In contrast to Figure 6, these data are plotted as cps
(characters per second) assuming the maximum compression available for each mode, i.e.
Pseudo Markov for Pactor-II/III (compression ratio 1.9) and Huffman for Pactor-I (compression
ratio 1.6). Furthermore, instead of plotting these data against the station separation,
these data are now plotted against the signal to noise ratios (S/N) based on a 4000Hz white-noise
bandwidth, a common telecommunications standard. These S/N data were carefully obtained from
collecting readings from the IC-746 transceiver signal strength indicators. In Figure 7,
the resulting data are plotted on a linear graph to show the relative speeds between
Pactor-I/II/III, AMTOR, RTTY, and PSK-31 which are available with the SCS PTC-II. Figure 8
shows the same data against a logarithmic y-axis "cps" to allow fine discrimination of the
cutoff sensitivities for each digital mode at very low (inaudible) S/N levels. Note that
the "A" in Pactor-IA simply indicates that this is the version of Pactor-I provided by
the SCS PTC-II HF modem and not from less sensitive versions elsewhere.
In sum, field collected data using amateur equipment (e.g. amateur radio operator transceivers
and low gain amateur antennas) show that Pactor-III approaches a data speed of 650 cps and
continues to work to an inaudible level of -18 dB S/N. Pactor-II approaches a speed of 140 cps
and continues to work to an inaudible level of -18 dB S/N. Pactor-IA approaches a speed of
28 cps and continues to work to an inaudible level of -5.6dB. Other non-Pactor modes can be inferred from
Figure 8 but readers should be aware that in contrast to Pactor-I/II/III, the other digital modes
are not 100% error free (by CRC method) and the cutoff's simply indicate the point where the text is no
Note: The data for AMTOR is based on a 5 bit ("upper case only") character with
no error correction. If FEC (Forward Error Correction) is applied, the values shown
in these data should be divided by two before comparing to the other digital modes.
In conclusion, these experiments summarize data obtained from 1500+ miles of driving
while transferring binary files between two SCS Pactor modems. The results indicate
that pactor-3 is considerably faster than pactor-2 on the HF bands. Finally, I have
strived to obtain as much accuracy in this set of comparisons as possible but remind
readers that these data were collected from an amateur station and not from a commercial
station. A brief description of the station used in these experiments can be found at