I believe that, by using a signal format designed specifically for LF
weak-signal operation, it should be possible to communicate at S/N
values at least 10 dB below what is typically needed for QRSS. Some
recent experiments by Lyle Kohler convinced me that the presently
popular modes are far from optimum, and I have written a program to
show the potential of a new mode. I call it WOLF (Weak-signal
Operation on Low Frequency).
A while ago, Lyle comparison tested various systems commonly used for
amateur LF communication. Modes tested included conventional CW, QRSS
(decoded both visually, and aurally with CRUNCH), and several PSK
formats. Using an audio editor, Lyle mixed an attenuated copy of each
signal with a "standard" sample of noise recorded from an LF receiver.
He measured the maximum attenuation which each mode could tolerate
before copy became impossible. The results can be seen on his Web
site at http://www.computerpro.com/~lyle/weaksigs/weaksigs.htm .
My present software is essentially an off-line demo. The transmit
mode creates a .wav file; the receive mode reads a .wav file and
attempts to decode the message. So far, it has only been tested by
mixing the Tx output with noise downloaded from Lyle's site (I am
traveling and have no LF Tx or Rx capability). But the simulated
results have been quite encouraging; there is often good copy when the
attenuation is 44 dB. This is a signal 11 dB weaker than that which
was needed by BPSK at MS1000, and 14 dB below the threshold for 0.4
WPM QRSS.
I would greatly appreciate any suggestions for making this system even
more robust, and encourage anyone interested to download the software
and try it. A simple test would be to mix the Tx output with your
favorite QRM or QRN and see how it fares. Much better would be trying
it on the air. If you have an SSB rig which can output LF, just play
the WOLF output file, feeding the transmitter audio from your sound
card. At the receiving end, record a .wav file from the receiver
audio, and feed it to WOLF for decoding. If you need a different
format file to key your Tx in BPSK, please let me know and I'll try
to provide it.
Below is a brief description of the WOLF signal; you can find more
details, and the software, at http://www.scgroup.com/ham/wolf.html .
Some features of this format are:
* An explicit reference signal for robust frequency and phase lock
* Average Tx power nearly equal to PEP
* Coding to minimize number of bits for a given message
* Forward error correction with high coding gain
* Coherent detection
* Matched filter detection (bit clock derived at receiver)
* Interleaving (can tolerate gaps in reception)
None of these ideas are new; it just seemed logical to combine
those features of modern commercial systems which offer performance
gains in our environment.
Most amateur weak-signal work uses some form of CW or BPSK. It is
often said that, for the same PEP, BPSK has a 6 dB advantage (CW
transmits only half the average energy, and half of that is carrier
with no message content). However, CW's carrier is far from wasted.
It enables recovery of the frequency and phase of the incoming signal,
even when it is very weak. That's one reason QRSS is so popular! In
contrast, conventional BPSK relies on a non-linear process to recover
the carrier, and fails to lock when the S/N is very low. Bill
de Carle's AFRICA avoids this problem in a clever way -- by matching
the phase pattern with all possible transmitted characters. But, this
requires that any forward error correction (FEC) coding be applied
separately to each character, which limits coding gain.
The WOLF signal is BPSK (at MS100), but after each "data" bit, a
"reference" bit is added. The reference stream is a pseudo-random
sequence which is known in advance by the receiver. The precise
frequency and phase can be measured, even when the signal is too weak
to decode the message. The reference "channel" also provides robust
bit timing and framing information, so the actual message need not
include synchronizing bits. The symbol set is limited to 40 (capital
letters, digits, space, and 3 punctuation). This permits sending
three characters using only 16 bits. A data packet is fixed at 15
characters (80 bits), enough to send two call signs plus some report
information. A rate 1/6 convolutional code is applied to the entire
packet, resulting in a 480 bit message. Including the reference bits,
a frame has 960 bits, so it takes 96 seconds to send.
A beacon just sends the frame repeatedly. If the signal is strong
enough for conventional CW, someone tuning it in only needs to
"listen" for a little more than 16 seconds to see the complete
message. If some error correction is required, perhaps a minute will
suffice. But if the signal is very weak, the receiving software can
integrate over as many frames as needed, until good copy is achieved.
For two way communication, one can send a frame, and await an
acknowledgement. If not received correctly, the frame is resent,
until there is enough information for correct copy. However, I
believe that one could design a much more efficient protocol, which
should permit a QSO to be completed within one hour, even with a
signal 10 dB below the QRSS limit. See the web page for more details.
Comments and suggestions welcome.
73,
Stewart KK7KA
|
