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: Kevin McQuiggin
Subject: Re: Strategies to save/display low sample-rate data
Date: Wed, 10 Apr 2024 11:43:24 -0700

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: signature.asc
Description: Message signed with OpenPGP


reply via email to

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