Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: LF: SlowCW and Dwell periods

To: [email protected]
Subject: Re: LF: SlowCW and Dwell periods
From: "Peter W. Schnoor" <[email protected]>
Date: Fri, 02 Apr 1999 12:59:50 +0200
Organization: University of Kiel, Clinic of Nephrology
References: <[email protected]>
Reply-to: [email protected]
Sender: <[email protected]>
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

<Prev in Thread] Current Thread [Next in Thread>