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

Fri, 15 Feb 2002 13:16:16 -0500

Stewart,

Maybe the smart thing to do is encapsulate the functionality of Wolf inside
a DLL which the (current) command-line shell would call. Then anyone that
wanted to can write a UI for it without disturbing the signal processing
code. At least two of the other signal processing programs use a DLL, sounds
like a good idea to me. It would also mean that you could add features into
the DLL and not "break" the existing programs out there.

Just a thought. :-)

73,

Mark W1EOF
The LowferVoyeur
(I only watch these other guys do the work because I'm too busy developing
software)

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Stewart Nelson
> Sent: Saturday, February 16, 2002 5:08 AM
> To: [email protected]
> Subject: [Lowfer] Re: Modes, signaling, and data recovery
>
>
> 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
>
>
> _______________________________________________
> Lowfer mailing list
> [email protected]
> http://mailman.qth.net/mailman/listinfo/lowfer