|
DIGITAL MODES: the new
generation of HF HAM Radio !
|
PACTOR II |
I.
Introduction
---------------------
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 spillover 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
compatility 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. |
Any
contribution to Digital Modes technology are
welcome! Just write us and feel free to send us your
articles for this Technical Area inside DMC Web
Site!
|