[Lowfer] Re: Modes, signaling, and data recovery

[Stewart Nelson]

Hi all,

I believe that we can combine what has been learned from WOLF and
Jason to create a new signaling scheme, which would permit real-time
QSOs at quite low S/N, and also be capable of detecting a repeated
message with much better performance than any existing system.

I would be glad to give the WOLF source code to anyone who seriously
intends to add significant new functionality, e.g. a GUI, real-time
decode, GPS locking, etc.  I don't want to give it to someone who will
just tweak a few parameters or improve the decode by half a dB,
because the proliferation of multiple versions will cause problems.
Email me privately if you are interested.

However, I don't think that an improved WOLF is a good general
solution.  As Alberto and others have pointed out, the wide bandwidth
requirement and incompatibility with high power switching amps make it
suitable mostly for Part 15 operation.  Jim M0BMU managed to tame the
beast, but with an effort that few amateurs would be willing to
expend.

Suppose we start with a Jason-like format.  Here is a first cut; all
suggestions and criticisms are welcome.  Eighteen frequencies are
used, spaced 1/4 Hz apart, so the bandwidth is about 4.5 Hz.  Sixteen
tones are for data; the highest and lowest are reserved for a
synchronizing pattern.  Each symbol is sent for 4 seconds.  Three
message characters are packed into 16 bits (like WOLF), and sent as
four symbols.  Four parity symbols (a simple rate 1/2 block code),
and four synchronizing symbols (a repeating HHLL pattern) are added.
So it takes 12 symbols (48 seconds) to send three characters, for a
net throughput of 16 seconds per character, about 50% faster than
the present Jason.

One operating mode is just like Jason is used now.  I believe that the
above format, properly decoded, should offer about a 3 dB improvement
in required S/N.  If Jason currently needs a "QRSS10" signal, then we
should get about QRSS2 speed with a QRSS20 signal, not bad for QSOs
under moderately weak conditions.

If the signal is weaker, the sender simply transmits his message
repeatedly (this capability is already present in Jason).  The
receiving operator knows the expected message length and tells the
software, which integrates the signal (like WOLF), until it can be
decoded.  I expect that performance in this mode should be comparable
to WOLF, but we would have the ability to use shorter messages when
conditions were tough.  Using six characters instead of 15 might gain
an extra 3 dB.  Of course, there is nothing special about this mode on
the sending end, so a casual listener with a strong signal can get
the message without knowing its length.  In fact, because the sync
pattern is easily recognized, the software could have the ability
to search a wide chunk of spectrum (SSB bandwidth) for such signals.

With still worse S/N, we need to synchronize time and/or frequency to
an external standard to permit useful integration over longer periods.
Time synchronization is easy.  Because of the relatively long four
second symbol period, timing within one or two hundred milliseconds is
adequate.  One simply sets the PC clock via the Internet or with an HF
or LF time station.  Of course, if you are using GPS for frequency
sync, then you also get nearly perfect timing for free.

Synchronizing the receiver to GPS is also easy.  All you need is a GPS
receiver with a 1 PPS output.  Peter G3PLX invented a clever scheme
which requires no additional hardware.  You just couple the 1 PPS into
the antenna input of the receiver, and all the rest is done in
software!  It corrects not only for receiver miscalibration and drift,
but sound card sampling errors, too.

The transmit side is tougher.  If you have an SSB transmitter and a
separate receiver, it should be possible to receive your own signal,
along with the 1 PPS, and have the software servo the outgoing tones
to maintain sync.  Otherwise, you will probably need to build some
hardware.  Let me know how you are generating the Jason signal, and
perhaps I can suggest a simple solution.

I believe that with proper synchronization at both ends of the link,
it should be possible to beat WOLF by 8 to 10 dB on an overnight run,
which is IMO enough to get a lowfer signal across the pond.

Who will write all this software?  I know very little about Windows or
about sound card programming, but would be glad to write the signal
processing part.  If Alberto or another Windows wizard is interested,
perhaps we could work together to get this on the air.

73,

Stewart KK7KA