Message-ID: <3704A326.C70944EA@nephro.uni-kiel.de>
Date: Fri, 02 Apr 1999 12:59:50 +0200
From: "Peter W. Schnoor" <pwsch@nephro.uni-kiel.de>
Organization: University of Kiel, Clinic of Nephrology
To: rsgb_lf_group@blacksheep.org
Subject: Re: LF: SlowCW and Dwell periods
References: <199904020852.JAA03987@post.interalpha.net>
MIME-Version: 1.0
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

Hello Gang,

Andy Talbot wrote:
 
> 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.   

This was one of my misgivings. No further comment...
Once more: What means "smoothing" in case of running GRAM
???

> [...]
> 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.   

I'm running 4000/8192/0.49 with WELCH (i.e. quadratic)
preprocessing only. Trying cosine windows (Hamming, Hanning)
I found some "broadening" or "smearing" of the LORAN-C lines
using the Marconi. WELCH draws a little bit more delicate
(<- dict.). The leakage suppression seems to be sufficient
if RX gain is adjusted carefully.

> 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 tried 16384 and 32768 and it worked fine but my RX are not
stable enough to get the full performance. The SPECGRAM2
application for UNIX workstations has the advantage to run
under plain console mode, if available. So no computing
power is wasted for GUI. By the way, it compiles under old
MsDOS with GNU-C but is restricted to IRQ < 8. So I never
tried this. It is Open Source Software of course. 

> [...] 
> 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.

The 32768 FFT works sufficient under LINUX/i486-66 even
under GUI (X-Win).
Some years ago I asked Creative Labs for further
descriptions of their soundcards but I never got a qualified
answer. So I don't know wether this ADCs have any true-phase
antialiasing filtering at front end. 

> [...]
> 6dB of capability is being wasted anyway, using these non-coherent energy
> detection techniques, but that's another story ...............

And another question is how to get this 6dB with non-linear
power amplifiers...

Greetings from North Germany,
54°16'N / 10°04'E, JO54ag
73 es gl de Peter, DF3LP