Envelope-to: dave@picks.force9.co.uk
Delivery-date: Tue, 26 Apr 2005 21:08:14 +0100
Message-ID: <002c01c54a9b$ccaca520$1101a8c0@w2ksn>
From: "Stewart Nelson" <sn@scgroup.com>
To: rsgb_lf_group@blacksheep.org
References: <00b801c54915$f416c140$0500a8c0@charter.net> <1862867986.20050425193418@t-online.de> <002901c549c0$226b6820$4d01a8c0@JKA> <894208480.20050425195652@t-online.de> <003001c549c2$e4aeef40$4d01a8c0@JKA> <8C7189CE67E4FAD-A98-CA95@mblk-r23.sysops.aol.com>
Date: Tue, 26 Apr 2005 13:09:05 -0700
MIME-Version: 1.0
Subject: Re: LF: WOLF Again
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 Markus and all,

> Does that mean you have to do two million 960-point correlations per receive
block to fill it?

No, the complex baseband signal is "despread" in 960 positions by multiplying by
the
shifted reference pattern.  When the correct shift is chosen, the result should
be
a carrier (of unknown frequency and phase).  An FFT is done on each despread
result,
and the magnitude from each bin is added into the pm array.

While much faster than the brute force approach, this is still pretty slow and
accounts for most of the run time.  That would be greatly reduced in a system
with time sync.  Even if the clocks were set manually and the system had to
search +/- 1 second, it would still save about 98% of the FFTs.  The Viterbi
decode would be the biggest remaining computation hog; I would guess that the
total processing time would be 1 to 2 seconds per block.

Without time sync, one could still improve by perhaps a factor of four, by
replacing the naive FFT function with a professionally written one, such
as FFTW or the Intel SPL.  Those packages have some licensing restrictions
which would then apply to WOLF.  IMO, it would not be a problem for
typical ham uses.

73,

Stewart KK7KA