Message-ID: <42574335.70801@genesiswireless.us>
Date: Fri, 08 Apr 2005 21:51:33 -0500
From: WE0H Mike <we0h@genesiswireless.us>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
MIME-Version: 1.0
To: rsgb_lf_group@blacksheep.org
References: <001301c53cad$a55447e0$1101a8c0@w2ksn>
In-Reply-To: <001301c53cad$a55447e0$1101a8c0@w2ksn>
X-GenesisWireless-MailScanner-Information: Please contact the ISP for more information
X-GenesisWireless-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details
X-MailScanner-From: we0h@genesiswireless.us
X-SPF-Result: relay.thorcom.net: 63.171.43.8 is neither permitted nor denied by domain of genesiswireless.us
X-Spam-Score: 0.1 (/)
X-Spam-Report: autolearn=failed,FORGED_RCVD_HELO=0.05
Subject: Re: LF: WOLF sources
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63
X-SA-Exim-Scanned: Yes
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
X-Listname: rsgb_lf_group
X-SA-Exim-Rcpt-To: rs_out_1@blacksheep.org
X-SA-Exim-Scanned: No; SAEximRunCond expanded to false
X-Spam-Filtered: by PlusNet SpamCORE (v3.00)

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
>
>
>
>  
>