[Lf] Proposed new LF signal format]

[Andre' Kesteloot]

Stewart Nelson wrote:

> 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