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

[Les Rayburn]

I feel very awkward in replying to this at all, other than to
say that the proposed signal format and logic makes
good sense. It would seem offer a solution to both
the short term QSO requirements, bandwidth issues,
and weak signal performance required for LF work and
perhaps could become a "standard" on both sides of
the pond.

Lacking programming skills, I can offer little more than
my support. However, I would gladly be willing to pay
for development costs if that makes this an easier
pill for folks like Alberto and Stewart to swallow.

As a minimum, all involved in developing these
tools have the appreciate of the rest of us.

73,

Les Rayburn, N1LF








>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
>
>
>_______________________________________________
>Lowfer mailing list
>Lowfer@mailman.qth.net
>http://mailman.qth.net/mailman/listinfo/lowfer

Les Rayburn, director
High Noon Films
100 Centerview Drive
Suite 111
Birmingham, AL 35216
(205) 824-8930
(205) 824-8960 FAX
(205) 253-4867 CELL