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

[Kevin McQuiggin]

Aha!  THANKS!

Kevin


> On Apr 10, 2024, at 11:45 AM, Daniel Estévez <daniel@destevez.net> wrote:
> 
> 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.
>>> 
>

signature.asc
Description: Message signed with OpenPGP