Iq tool center freq lock

[vladisslav2011]

Problem: It is possible to change the center frequency while playing an IQ file. The
real file center frequency does not get shifted to correct position in this
case, so the spectrum plot/waterfall becomes shifted from actual played
frequency, bookmarks become not valid, freqCtrl shows wrong frequency,
plotter shows wrong frequency and so on.

This PR changes frequency setting logic to be more staraightfroward
and consistent.

Independent of frequency change event source (freqctrls, plotter, remote)
do the things in a same way: calculate new center and offset, taking into
account the fact, that the center frequency may be loked due to IQ file
playback, set the new frequency on a receiver side, then update all GUI
controls to reflect changes.
Enforce new frequency limits on the plotter side when IQ playback is started.

The "Ignore limits" checkbox still makes it possible to change center frequency
even when playing IQ file.

Next in series: #1011

Close #951

[vladisslav2011]

Rebased onto updated iq_tool_center_freq_fix + some code style fixes.

[vladisslav2011]

Rebased on top of current iq_tool_center_freq_fix.

[argilo]

There are quite a few code changes here, so it would be very helpful to have some explanation of what's going on.

Some questions:

• In what ways is it possible to accidentally change the hardware frequency?
• What are the consequences of changing the hardware frequency during I/Q playback?
• What changes were necessary to solve this?

[vladisslav2011]

• In what ways is it possible to accidentally change the hardware frequency?

Wheel over freqCtrl, middle button dragging of plotter horizontal axis, dockrxopt frequency input.
I do it all the time while using the IQ Tool.
It is possible to change hardware frequency with remote command 'F', but it is highly unlikely that anybody would use remote control while playing IQ file.

• What are the consequences of changing the hardware frequency during I/Q playback?

Bookmarks become not valid, freqCtrl shows wrong frequency, plotter shows wrong frequency and so on.

• What changes were necessary to solve this?

The main change is here: ceaa48c#diff-2fc3518522047c9d0c5d1f75d1de006499a71e9812311c7228c892a5250bad48R866-R885
Other changes were made to remove event flow loops and make all frequency changes and widgets updates go through MainWindow::setNewFrequency.

Thanks for a review.
I think, we can close #951 with this PR too.
I'll do required changes, make some tests and reopen the PR soon.

[argilo]

What if the filename does not have a frequency, or the frequency is incorrect? Should the user not be allowed to adjust the frequency in those cases?

[argilo]

I guess the core of the problem is the behaviour of the main frequency control, which currently changes the hardware frequency rather than the channel filter offset. I sometimes find this annoying even when using hardware inputs, because changing the hardware frequency is disruptive. (It is not instantaneous, especially when using remote devices, it shifts the waterfall, and it invalidates FFT averages.)

I agree that it makes sense for the main frequency control to adjust the channel filter offset during I/Q playback. It might even make sense for that to be the default for hardware inputs. (SDR# works this way, for instance.)

I'll have to play around with this a bit more and think about what, if anything, should be done to allow the hardware frequency to be adjusted during I/Q playback.

[argilo]

One minor issue: if an I/Q file is opened using the I/O Devices panel instead of the I/Q tool, then the current frequency continues to be used, even if it is well outside the viewable range:

Getting it back in range using the main frequency control is a bit painful. Clicking on the FFT gets it back in range more easily.

The frequency should probably be clamped to be within the bounds of the FFT.

[vladisslav2011]

What if the filename does not have a frequency, or the frequency is incorrect?

This case is addressed by this PR: #1026

what, if anything, should be done to allow the hardware frequency to be adjusted during I/Q playback.

I think, the hardware frequency should be adjusted during IQ playback only in the same way, it had changed during recording of the corresponding file. This may be implemented by processing tags, generated by SigMF source in future.
Another case, when hardware frequency is changing during IQ recording is satellite signal recording with remote control to compensate the doppler shift. In that case the hardware frequency should not be adjusted during playback due to obvious reasons...

The frequency should probably be clamped to be within the bounds of the FFT.

This can be done in MainWindow::setNewFrequency. Then it may be possible to remove bounds checking in the plotter. I'll try to implement this and update this PR.

[vladisslav2011]

The frequency should probably be clamped to be within the bounds of the FFT.

Done.
My tests show no regressions nor UX degradation.
Bounds checking in the plotter is done only to prevent moving the waterfall/spectrogram far away from visible area while zooming. Nothing to do here.