[time-nuts] Question about SoundCard stability?

[David McClain]

Hello John,

> Well, not entirely -- it's common enough to see FFT applications that
> compute frequency readings at sub-bin precision by tracking atan 
> (Q,I) across
> multiple time records.  That is a well-defined thing to do, since the


Yes, indeed, I am familiar with that technique from my SIGINT days...  
however, what you are really doing is extending the sampling period  
by looking at multiple scans. And so that isn't really any different  
at its base than just taking a longer period FFT.

The only way I have ever seen super-resolution is when you do AR  
deconvolution, bearing in mind that wherever there are instrumental  
induced zeros in the spectrum, you will get nonsense values in the  
result. AR, aka maximum-entropy, attempts to produce a minimum norm  
estimate, akin to that from SVD analysis.

And yes, SpectrumLab appears to be assuming infinte SNR, no nearby  
interference, absolutely drift free, monochromatic lines. And there  
(maddeningly) seems no way to disable this *feature*.

The soundcard interface of SpectrumLab was manually adjusted by me to  
ensure that the 100 Hz sideband actually reads as 100 Hz. My Flex3K  
codec was about 17.5 ppm slow.

Dr. David McClain
Chief Technical Officer
Refined Audiometrics Laboratory
4391 N. Camino Ferreo
Tucson, AZ  85750

email: dbm at refined-audiometrics.com
phone: 1.520.390.3995
web: http://refined-audiometrics.com



On Oct 12, 2010, at 23:25, John Miles wrote:

>
>> I think I have answered the question... You cannot get around the
>> uncertainty principle, which states that your precision in resolving
>> frequencies is limited by the inverse of your resolution in time.
>> Attempting some hair-brained "interpolation" across a peak in the FFT
>> is just a mathematical game without any meaning.
>
> Well, not entirely -- it's common enough to see FFT applications that
> compute frequency readings at sub-bin precision by tracking atan 
> (Q,I) across
> multiple time records.  That is a well-defined thing to do, since the
> relationship between the time-record length and the period of the  
> dominant
> signal in a given bin is what's ultimately being measured.  But  
> this sounds
> like a case where the readings reported by the software are based on
> assumptions that aren't valid.
>
> What is the connection between the Flex 3000 and the PC like?   
> Where does
> the "48 kHz" rate you mentioned come from, exactly?  If, for  
> instance, the
> 48 kHz is some fraction of the same TCXO that's driving the baseband
> conversion in the receiver, then it could make sense if the frequency
> readings appear mysteriously constant.  The "drift" would be in the
> wall-clock duration of the time record in this case, influencing  
> the true
> frequency of the FFT bin in ways the software doesn't know about.
>
> In other words, as far as SpectrumLab is concerned, the frequency  
> associated
> with bin 123 of a 1024-bin record at 48 kHz is exactly  
> 2882.8125000... Hz,
> because it's assuming that the 48 kHz sample rate is also exact.   
> If the
> latter isn't true, and it won't be, then the former won't be true  
> either.
>
>> A *proper* interpolation in frequency space is performed by zero-
>> padding the time record. When you do that, you introduce many inter-
>> bin sidelobes. But more to the point, when the FFT bin-size is the
>> same width as the expected drift amplitude, you get a broad,
>> convolved bin content from the duration of the window, and attempting
>> to say, on the basis of adjacent bin amplitudes, that you know where
>> the frequency of *the peak* is to any better than the bin-width is
>> just nonsense.
>
> It doesn't work that way (or shouldn't, at least, if they are  
> claiming to
> report true peak-frequency readings).
>
> -- john, KE5FX
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/ 
> time-nuts
> and follow the instructions there.
>