Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: LF: WOLF sources

To: [email protected]
Subject: Re: LF: WOLF sources
From: WE0H Mike <[email protected]>
Date: Fri, 08 Apr 2005 21:51:33 -0500
In-reply-to: <001301c53cad$a55447e0$1101a8c0@w2ksn>
References: <001301c53cad$a55447e0$1101a8c0@w2ksn>
Reply-to: [email protected]
Sender: [email protected]
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
Stewart,

By the sounds of what you wrote, WOLF could become the mode of choice for crossing the pond with a Part 15 signal level. I wish I knew how to write code...

--
Mike
WE0H
WD2XGI



Stewart Nelson wrote:

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





<Prev in Thread] Current Thread [Next in Thread>