waterfall/spectrum falls out of sync with indicated frequency at extreme zoom
Tune to WWV/WWVH or other time signal with a known frequency. Set the FFT size to 524288, and zoom in so the spectrum is maybe 2kHz wide.
If you "grab" the frequency "tape" and move it left and right, you will notice that the frequency peaks in the spectrum move around under the frequency reticle -- when it is expected they remain fixed.
In particular: move to the left, and the carrier will look to be at the right frequency, and move to the right, and the carrier slides off. I have observed an errors in excess of 100Hz. Another way is to watch WWV: if you place the carrier on the left, the 500Hz and 600Hz tones will not line up with the reticle.
The problem was traced to the doZoom() method in waterfall.h; when the 'factor' (line 102) is much less than one (this is the extreme zoom), the floating point arithmetic in the copy loop goes haywire, growing progressively worse from left to right (as observed).
A quick fix is to change the type of "factor" and "id" (lines 102 and 105) from float to double.
That's not the reason at all. (I assume you probably haven't tried the fix you're suggesting or you'd have noticed).
The real reason is just that the function aligns the FFT bins to the sides of the waterfall/fft. It's not a bug, it's just how it was written neglecting extreme zoom levels for performance.
That's not the reason at all. (I assume you probably haven't tried the fix you're suggesting or you'd have noticed).
The real reason is just that the function aligns the FFT bins to the sides of the waterfall/fft. It's not a bug, it's just how it was written neglecting extreme zoom levels for performance.
Does this explain what is happening here? Seems like the signal keeps shifting location depending on how I scroll it, if the zoom is set lowest (second half of clip I demonstrate it): https://imgur.com/wsMvb4X
No matter if it's a bug or a feature, or if it's caused by FFT bins or something else... Changing the variables from float to double fixes it... https://github.com/AlexandreRouma/SDRPlusPlus/pull/833
That's false, you changed a lot more than just the type of these two variables.