Return-Path: <owner-rsgb_lf_group@blacksheep.org>
Received: (qmail 58181 invoked from network); 9 Apr 2005 02:51:00 -0000
Received: from unknown (HELO ptb-spamcore01.plus.net) (192.168.71.1)
  by ptb-mailstore03.plus.net with SMTP; 9 Apr 2005 02:51:00 -0000
Received: from mailnull by ptb-spamcore01.plus.net with spamcore-l-b (Exim 4.32; FreeBSD)
	id 1DK65G-000Gkh-BG
	for dave@picks.force9.co.uk; Sat, 09 Apr 2005 03:52:30 +0100
Received: from [192.168.67.1] (helo=ptb-mxcore01.plus.net)
	by ptb-spamcore01.plus.net with esmtp (Exim 4.32; FreeBSD)
	id 1DK65G-000Gke-8z
	for dave@picks.force9.co.uk; Sat, 09 Apr 2005 03:52:30 +0100
Received: from post.thorcom.com ([193.82.116.20])
	 by ptb-mxcore01.plus.net with esmtp (Exim) id 1DK67m-0000BV-7u 
	for dave@picks.force9.co.uk; Sat, 09 Apr 2005 03:55:06 +0100
Received: from majordom by post.thorcom.com with local (Exim 4.14)
	id 1DK63e-0000h7-Ie
	for rs_out_1@blacksheep.org; Sat, 09 Apr 2005 03:50:50 +0100
Received: from [193.82.116.30] (helo=relay.thorcom.net)
	by post.thorcom.com with esmtp (Exim 4.14)
	id 1DK63e-0000gy-5F
	for rsgb_lf_group@blacksheep.org; Sat, 09 Apr 2005 03:50:50 +0100
Received: from mail.genesiswireless.us ([63.171.43.8] helo=ms.genesis-technology.com)
	by relay.thorcom.net with esmtp (Exim 4.43)
	id 1DK63c-00026f-GC
	for rsgb_lf_group@blacksheep.org; Sat, 09 Apr 2005 03:50:50 +0100
Received: from [192.168.0.100] (rev-65.165.20.91.genesiswireless.us [65.165.20.91])
	by ms.genesis-technology.com (8.13.3/8.13.3) with ESMTP id j392nbks027063
	for <rsgb_lf_group@blacksheep.org>; Fri, 8 Apr 2005 21:49:37 -0500
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)
X-Accept-Language: en-us, en
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
>
>
>
>  
>