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