Return-Path: Received: (qmail 14190 invoked from network); 2 Apr 1999 09:55:02 +0100 Received: from magnet.plus.net.uk (HELO magnet.force9.net) (195.166.128.26) by guiness.force9.net with SMTP; 2 Apr 1999 09:55:02 +0100 Received: (qmail 22380 invoked from network); 2 Apr 1999 08:55:25 -0000 Received: from post.thorcom.com (194.75.130.70) by magnet.plus.net.uk with SMTP; 2 Apr 1999 08:55:25 -0000 Content-Transfer-Encoding: 8bit Received: from troy.blacksheep.org ([194.75.183.50] ident=root) by post.thorcom.com with esmtp (Exim 2.04 #3) id 10SzgR-0001BA-00; Fri, 2 Apr 1999 09:52:11 +0100 X-Priority: 3 Received: (from root@localhost) by troy.blacksheep.org (8.6.12/8.6.12) id IAA09760 for rsgb_lf_group-outgoing; Fri, 2 Apr 1999 08:51:55 GMT X-MSMail-Priority: Normal Received: from post.thorcom.com (root@post.unica.co.uk [194.75.183.70]) by troy.blacksheep.org (8.6.12/8.6.12) with ESMTP id IAA09756 for ; Fri, 2 Apr 1999 08:51:53 GMT Received: from post.interalpha.co.uk ([195.26.224.18] helo=post.interalpha.net) by post.thorcom.com with esmtp (Exim 2.04 #3) id 10Szfr-0001B1-00 for rsgb_lf_group@blacksheep.org; Fri, 2 Apr 1999 09:51:35 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Received: from sot-mod52.interalpha.net (sot-mod52.interalpha.net [195.26.225.52]) by post.interalpha.net (8.8.7/8.6.11) with SMTP id JAA03987 for ; Fri, 2 Apr 1999 09:52:01 +0100 Message-ID: <199904020852.JAA03987@post.interalpha.net> X-Sender: drassew2@post.interalpha.co.uk X-Mailer: Windows Eudora Version 1.4.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Date: Fri, 02 Apr 1999 08:53:05 +0000 To: rsgb_lf_group@blacksheep.org From: "Andy Talbot" Subject: LF: SlowCW and Dwell periods Sender: Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org >I don't know what "dwell" really means in this topic but I >think it's the time of data collection and folding/averaging >in background. What means "smoothing"? In time or frequency >domain? If it means "data windowing" the WELCH algorithm >outperforms the other (Rectangular, Gaussian, Parzen, >Hanning, etc.) since it does not "smear" too much, >especially in case of LORAN-C background. My understanding of the GRAM software is that the 'dwell' time is just a period of wasted time idling between performing an FFT on each set of data rather than increasing the FFT length. If this is the case then there is no advantage at all in going to longer dot lengths USING THE GRAM SOFTWARE as there is no way of further narrowing the receive bandwidth with a narrower FFT bin. In which case alll the power being transmitted during each dwell period is going to waste. I seem to recall that the author of the programme quickly included the dwell option at the request of LF operators, suspect that but not being particularly interested in the radio related aspects of that software did not try to take it any further. I may be wrong, but the dwell option appeared so quickly that a simple delay is the most likely route for generating it. The lowest bandwidth therefore possible is from 8000 Hz sampling with a 16384 Point FFT giving a bin size of 0.49 Hz and therefore a bandwidth of close to 1 Hz using a Hamming window. Therefore, with 1 Hz BW the 3 seconds dots everyone seems to have settled on as being optimum will fill 3 FFT samples ans show up clearly as a line of three pixels or more depending on what overlap has been incorporated in the data sampling. But there will NEVER be any advantage in going to longer dots unless the sampling rate is reduced (will GRAM allow 5513 Hz sampling ?) or the FFT size can be increased above 16384. I use the DSP EVM board to mix the audio down to DC and then data reduce / filter to arbitrarily low bandwidths to give the full advantage of going to longer dot. periods with no wasted dwell time. The current limit is in the region of a reciptocal-minute bandwidth, around 10mHz, meaning dot lengths of 40 - 60 seconds could be used and it would be a straightforward job to increase the decimation further. GRAM does not use the mix down and decimate technique, but it just may be possible for the author to include a longer FFT routine as an option if asked. I have seen million point FFTs processed on Pentium PCs in less than one second, so it is certainly possible! It is also possible to ignore alternate samples of the input data, giving an effectively reduced input sampling rate - that is what decimation is all about - but the audio must then be pre-filtered to prevent any alliasing terms being generated as no filtering is being done in software. However, if a CW receiver with a narrow filter giving an audio output in the region of say 500 - 900 Hz is used, there is no reason why the 8kHz sampling can't be decimated by four giving an effective sampling of 2kHz, and four times the resolution bandwidth with the same 16K FFT. That is a 6dB S/N improvement immediately for a software mod as straighforward as including a dwell time. 6dB of capability is being wasted anyway, using these non-coherent energy detection techniques, but that's another story ............... Andy G4JNT