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: [email protected]
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 -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/
time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
