PACTOR - Short system description
System Details Pactor Operation Memory ARQ
I. Introduction
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 realized:
o optimal coherent mode, i. e. system clocks locked to frequency standards (e.g. DCF77, TV deflect ion signals and other high precision broadcasts)
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
1. Timing
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 obsolete.
* 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.
2. Packets
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 request, QRT) 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 (callsign).
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 '+ ?').
6. Speedchange
Speeddown only being useful in poor conditions or at low data input rates (e. g. manual typing), both directions are treated unsymmetrically.
i) Speeddown
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).
ii) Speedup
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.
PACTOR-II
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
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 as well. 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 Winlink 2000 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 IF filters. *, 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 longer legible. 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 http://ecjones.org/station.html