Considering the subset of protocols on Rick's list (below) for which
soundcard-based applications are available, PSK31 comes out on top.
For keyboard-to-keyboard operations, however, I don't believe that
absolute spectrum efficiency explains PSK31's stickiness. I suggest
that the follow three factors are what's responsible for its
stickiness:
1. the number of QSOs that fit within 3 KHz
A typical 3 KHz transceiver bandpass enables panoramic soundcard
software to simultaneously display up to 50 QSOs or calls (though 25
is a more practical capacity). This is large enough that operators
often park their transceiver on a single frequency (e.g. 14070) and
use their software to find ragchew partner, needed DX station, or
friend with whom a sked has been arranged. As discussed in an earlier
thread, most soundcard software can then QSY the transceiver to place
the desired signal at an audio offset optimal for the transmitter's
bandpass and receiver's filters.
2. speed
At 40 WPM, PSK31 is "fast enough" for most hams.
3. resiliency
Though far from perfect, PSK31 does a reasonable job under adverse
band conditions. While many DXers still prefer RTTY, more and more
RTTY DXers maintain a PSK31 capability to work DX stations active in
this mode (PSK QSOs "count" as RTTY in ARRL DXCC awards). The
successful use of PSK31 on topband and 80m is another indicator;
these bands are always blessed with QRM and/or QRN.
You might think that the younger generation of touch-typing hams
would find PSK31 "too slow". PSK63 provides double the speed, but
a. many keyboard-to-keyboard ops who tried PSK63 reported discomfort
with their abiity to keep up when transmitting (other than when
sending and receiving long brag tapes)
b. PSK63 would have cut the 3 KHz "capacity" from 25 to 12 QSOs
Years ago, several of us ably led by Skip KH6TY tried to establish
PSK63 as an upgrade from PSK31 and a replacement for RTTY. No sale --
there just wasn't enough incremental value to trigger a migration.
Several folks on the DXLab reflector have asked for PSK125 support,
saying that this mode is on the upswing in Europe. MultiPSK, which
interoperates well with DXLab, supports PSK125; it will be
interesting to see how the "much faster, but less robust and fewer
QSOs in 3 KHz" tradeoff works out.
For keyboard-to-keyboard operations, speed beyond 50 wpm is of
questionable value and error-free transmission is not an absolute
requirement because "manual ARQ" is available ("sri OM missed ur name
pse rpt ur name"). In contrast, message-passing systems require error-
free transmission. For them, higher speed means increased message
capacity, and panoramic reception is of little value, so wider
bandwidths do not impede adoption. In other words, they are an
entirely different kettle of fish -- both in terms of the
characteristics valued by their users, and the modulation and
protocol techniques appropriate to their implementation. Comparing
keyboard-to-keyboard and message-passing protocols on the same axes
makes no sense.
The point of this post is not "PSK31 is the best keyboard-to-keyboard
protocol; let's stop trying to invent something better". Rather, its
to identify the characteristics that have enabled PSK31 to remain so
dominant despite the subsequent 7-year explosion of new soundcard
modes triggered by its appearance. The protocol designer looking to
develop a more attractive alternative to PSK31 for keyboard-to-
keyboard operations should consider focusing on significantly
increasing QSO capacity within a 3 KHz transceiver bandspread without
seriously compromising either speed or resiliency. PSK31 first
appeared at the rather stunted peak of the last sunspot cycle; since
then, its adoption curve has looked like the inverse of the solar
flux curve. As we enter the next solar cycle and propagation
improves, 25 QSOs per band will likely prove insufficient; thus a
more dense keyboard-to-keyboard mode could displace PSK31 if its
other important characteristics aren't degraded.
As for the other kettle of fish, I will leave their future to those
interested in message passing systems. After all the discourse here,
I trust that they will see the light and provide means to ensure that
such systems never transmit on busy frequencies.
73,
Dave, AA6YQ
--- In [email protected], Rick <[EMAIL PROTECTED]> wrote:
>
> Consider that voice SSB requires over 2000 Hz for reasonable
quality and
> 2700 Hz would be better. Speaking on the air may be about 120 wpm.
That
> figures out to around ~ 20 Hz per wpm, give or take some. For
passing
> traffic it would be much slower though with more Hz per wpm.
>
> PSK31 is about the narrowest mode available to communicate at that
> speed. Even CW may be around the same bandwidth (~ 60 Hz). This
allows
> enormous numbers of hams to set their dial frequency at one point
and
> must move their cursor to read out or even contact or call other
hams.
>
> PSK31 can be sent at an average speed of around 40 wpm in that 60
Hz
> bandwidth, or 1.5 Hz per wpm. If you only look at throughput per
> bandwidth you find that if you need high speed, robustness, and
> accuracy, nothing can touch Pactor 2 and 3. If you need keyboard
speed,
> then it likely be a different story.
>
> Scaling different modes, under moderately good conditions and using
> Patrick's Multipsk information and some averages with ARQ modes
from
> KN6KB's RF Footprint Powerpoint:
>
> Mode bandwidth (Hz) / speed (wpm) =
Hz/wpm
>
> Olivia 32/1000 - 1000 / 24 = 42
>
> ALE MIL-STD-188-141A - 2000 / 76 = 26
>
> Olivia 16/500 - 500 / 20 = 25
>
> Olivia 8/1000 1000 / 59 = 17
>
> FAE = 2000 / 150 = 13
>
> MT63 1000 / 100 = 10
>
> 45 Bd RTTY 600 / 60 = 10 (some will consider this narrower and with
a
> better score)
>
> MFSK16 - 316 / 42 = 7.5
>
> Pactor 1 200 / 600/200 = 3
>
> ThrobX - 94/40 = 2.3
>
> DominoEX/11 194 / 77 = 2.5
>
> PSK31 60 / 40 = 1.5
>
> Pactor 2 700 / 500 = 1.4
>
> Pactor 3 2400 / 2225 = 1
>
> If you adjust some of the numbers for conditions where the S/N is
well
> below zero dB, then I think it would change things a bit. Some of
these
> numbers are guesstimates so if anyone has other suggested numbers,
it
> might be interesting. The main thing is to look at the relative
> comparison. But we need to keep things in perspective, since all
things
> are not equal and a wide footprint mode for keyboarding would be
> difficult to justify unless it had special abilities to handle
difficult
> conditions as some of these modes have. I could do another SWAG on
this
> with say, -5 or -10 S/N.
>
> 73,
>
> Rick, KV9U
>
