discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strategies to save/display low sample-rate data


From: Daniel Estévez
Subject: Re: Strategies to save/display low sample-rate data
Date: Wed, 10 Apr 2024 20:45:36 +0200
User-agent: Mozilla Thunderbird

Hi Kevin,

milli-Hz, not Mega-Hz. 0.078125 Hz = 78.125 mHz.

On 10/04/2024 20:43, Kevin McQuiggin wrote:
Hi Daniel:

I’m confused re the math here, or maybe the concept!  Please forgive what may 
be a dumb question.

Where does 78 MHz for frequency resolution come from?  80 SPS using analytic 
sampling (IQ) means a bandwidth of 80 Hz.  1024 bins in the FFT with an 80 Hz 
bandwidth gives 80/1024 or 0.078125 Hz per bin.

I see the “78” in there but how does this get interpreted as 78 MHz?  I might 
have missed something earlier in the thread.

73,

Kevin VE7ZD

On Apr 10, 2024, at 11:28 AM, Daniel Estévez <daniel@destevez.net> wrote:

On 10/04/2024 19:44, John Ackermann N8UR wrote:
On 4/10/24 11:29, Fons Adriaensen wrote:
Both the decimation and 80 size 1024 FFTs per second should be peanuts
for any modern PC...

And of course you don't need to do the FFT again for every sample,
it just generates a lot of redundant data.
I understood that if you have a 1024 bin waterfall, it takes that many samples 
to fill it and output a vector.  With a sample rate of 80, that means about 
12.8 seconds to show one line of the waterfall.  Or do I have that wrong?
(I used 80 samples/sec for simplicity.  The actual rate after decimating from a 
1.536 ms/s stream is 93.75.)

Hi John,

Yes, that is correct. Ultimately you're hitting the uncertainty principle for 
the Fourier transform. A 1024-point FFT at 80 samples/s has a frequency 
resolution of 78 mHz. You need to process at least 1 / 78 mHz = 12.8 seconds of 
signal to achieve that resolution.

Best,
Daniel.



Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]