Return-Path: Received: from rly-db05.mx.aol.com (rly-db05.mail.aol.com [172.19.130.80]) by air-db08.mail.aol.com (v125.7) with ESMTP id MAILINDB082-ac64aaa0ce050; Fri, 11 Sep 2009 04:40:20 -0400 Received: from post.thorcom.com (post.thorcom.com [193.82.116.20]) by rly-db05.mx.aol.com (v125.7) with ESMTP id MAILRELAYINDB054-ac64aaa0ce050; Fri, 11 Sep 2009 04:40:02 -0400 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1Mm1ea-0002zq-Se for rs_out_1@blacksheep.org; Fri, 11 Sep 2009 09:38:48 +0100 Received: from [193.82.116.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1Mm1ea-0002zh-FF for rsgb_lf_group@blacksheep.org; Fri, 11 Sep 2009 09:38:48 +0100 Received: from mail15.primus.ca ([216.254.141.182] helo=mail-07.primus.ca) by relay1.thorcom.net with esmtp (Exim 4.63) (envelope-from ) id 1Mm1dY-0005Oh-Dm for rsgb_lf_group@blacksheep.org; Fri, 11 Sep 2009 09:37:45 +0100 Received: from [98.124.14.67] (helo=Bigmachine.magma.ca) by mail-07.primus.ca with esmtpa (Exim 4.69) (envelope-from ) id 1Mm1eF-0005py-1s for rsgb_lf_group@blacksheep.org; Fri, 11 Sep 2009 04:38:27 -0400 Message-Id: <7.0.1.0.1.20090911040034.01869af8@magma.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 11 Sep 2009 04:38:17 -0400 To: rsgb_lf_group@blacksheep.org From: Bill de Carle In-Reply-To: <4AA9AE90.7070109@charter.net> References: <211F6B38DA2544AD84B814000D47EDF6@AGB> <0F69884C983F4F198A9B4B4F276326AD@radiorummet> <171181B694684DD8A9131D31D307EB5B@JimPC> <000001ca326f$b6ce1c00$0b01a8c0@weazle> <4AA9AE90.7070109@charter.net> Mime-Version: 1.0 X-Authenticated: ve2iq - (Bigmachine.magma.ca) [98.124.14.67] X-Karma: unknown: X-Spam-Score: 0.0 (/) X-Spam-Report: autolearn=disabled,none Subject: Re: LF: Wolf Config Settings Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: 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-AOL-IP: 193.82.116.20 At 09:57 PM 9/10/2009, W1TAG wrote: >J.B., > >For work at 500 kHz, I'd be tempted to go no longer than 16 frames. >I'm beginning to think that the fast fades and poorer phase >stability hurt the build-up of copy. While you may get your first >clear copy on the 31st line, I'll bet that you would have gotten it >quicker by flushing things out earlier. > >That said, 8 lines appears to be too short for any reasonable copy >of M0BMU here. I used 12 earlier in the week with decent results, >and have gone back to it. WOLF was originally set up as a batch mode but the GUI adaptation made it convenient to run it continuously. However, some of the batch mode philosophy still comes into play because the "integration time" builds up gradually. It starts with one frame, then builds up to a resultant over n frames, then dumps everything and starts all over again at one frame, etc. That isn't particularly compatible with continuous operation. It would probably be better to do it like we used to in the COHERENT/AFRICAM BPSK software, i.e. to keep a "running" average. COHERENT/AFRICA had a parameter called GRAB, which specified the number (n) of consecutive frames to be averaged together. On startup, the algorithm worked just like WOLF, it built up gradually, using first one frame, then two, etc, until n frames were in the average. Thereafter it continued to use only the *last* n frames. It was done by keeping a set of accumulators and a large historical database of past samples. Each time a new frame was received, its values were added into the accumulators and simultaneously the oldest values (from n samples back) were subtracted off. That way we had a sliding window n frames wide, moving continuously forward through time. One advantage was that we were working with much shorter frames (i.e. 16 or 32 bits vs 960 bits for WOLF blocks), so the amount of memory and computation required was considerably less. Obviously we cannot afford to be compute-bound at the end of each frame for more than the time it takes to receive the next frame. On the other hand, we have much faster processors these days and memory isn't an issue. COHERENT/AFRICA could integrate in two ways: by sample or by decoded bit. By sample gives better results but is impractical for long GRABs unless the timing is locked to GPS at both ends: once you accumulate half a Hz of frequency offset adding in more samples actually hurts more than it helps because destructive interference sets in. Integrating after bit decoding allowed us to run for much longer times because it still pays off to do it until the offset reaches half a bit-time (50 msec vs 62.5 usec). WOLF also does a frequency search at each update which multiplies the amount of compute time whereas COHERENT/AFRICA assumed the frequency was a known parameter. We did eventually incorporate a tracking filter which was an attempt to follow a slowly-changing frequency, but that never proved to be very helpful. The optimum value of n can be expected to vary over time depending on current propagation conditions. Perhaps some kind of adaptive filter to adjust the value of n continuously to give the best decode of WOLF's 480-bit PRN sync channel? Bill VE2IQ