Aha! THANKS! Kevin
> On Apr 10, 2024, at 11:45 AM, Daniel Estévez <dan...@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 <dan...@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
