Message-ID: <001301c53cad$a55447e0$1101a8c0@w2ksn>
From: "Stewart Nelson" <sn@scgroup.com>
To: rsgb_lf_group@blacksheep.org
Date: Fri, 8 Apr 2005 19:41:33 -0700
MIME-Version: 1.0
Subject: LF: WOLF sources
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org

Hi Wolf and all,

I just posted a copy of the WOLF sources at 
http://www.scgroup.com/ham/wolf-source.zip

This has the complete environment; if you have MS VC++
you should be able to build it right away.  Binaries
are also included, so you can see if the build gives
the same results.

The code is simple C, so it should not be hard to
build it with Borland or GCC.  All the real work
is done in wolf.cpp; there are various utility
functions in fft.cpp.

Although I don't presently have time to write new code,
I'd be glad to answer any questions that may come up.

In addition to a GUI and real-time operation, here are
some features I'd like to (eventually) see:

1. Slow it down!  Instead of a raw rate of 10 bps,
   operation at e.g. 1 or 2 bps would greatly
   reduce interference to stations operating on
   nearby frequencies, and permit operation between
   LORAN lines.  A slower format would also be much
   more tolerant of timing errors, in a future system
   using synchronized clocks.

   I believe that reducing the data rate is a simple
   matter of adjusting some parameters, but there
   are two problems: a) It's likely that many Tx or
   Rx would not be phase-stable over the 8 or 16
   minutes that a frame would now take.  One would
   need to add a "stability" setting to allow
   searching for carrier frequency and phase over a
   selectable fraction of a frame.  b) It would be
   a shame to have to wait 16 minutes for results,
   even when the incoming signal is strong.  One
   could perform a decode with e.g. 1/4 of a frame,
   substituting "erasures" for the missing bits.

2. Provide for Tx/Rx bit timing synchronization.
   This could use GPS or another external source,
   or simply depend on accurate computer clocks.
   That should greatly improve sensitivity, by
   eliminating false reference pattern sync on
   weak signals.

3. Implement "smart" signal averaging, weighting
   the incoming message symbols according to the
   quality of the received reference symbols.
   That would avoid degradation of data received
   during good propagation, by noise received
   during prior poor propagation.  Also, when
   the received reference is "excellent", the
   decoder could reset, allowing different
   messages to be sent in each frame.

A combination of (2) and (3) should permit
operation at "any" SNR, though it would of course
take 100 times longer to receive a signal 10 dB
weaker.

4. Implement some means of Tx/Rx carrier sync.
   This probably requires GPS at the Tx end,
   though it may be possible to use LORAN QRM
   on receive.  First, that would improve LF
   skywave performance by a few dB.  However,
   on a long-term phase stable path, e.g. VLF
   or groundwave, it should permit operation at
   any SNR, taking only 10 times longer to
   receive a signal 10 dB weaker.

If different folks are interested in tackling
these topics, perhaps I could act as a coordinator.

73,

Stewart KK7KA