[time-nuts] Question about SoundCard stability?

[John Miles]

> 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