Frequency correction emulation

[WGH-]

Many drivers, like the HackRF one, don't have frequency correction implemented, because the hardware doesn't have the ability.

For these devices setFrequencyCorrection is no-op, and hasFrequencyCorrection also returns false.

However, it can be implemented in software. For exampe, gr-osmosdr implements it for HackRF this way. gr-osmosdr also fills more or less the same niche as SoapySDR (even though it can use it as a backend), but it has fewer features and depends on GNU Radio.

In any case, many end users need frequency correction either way. The question is, where should it be implemented, if the device doesn't support it in hardware?

Right now SoapySDR's clients must implemented it, if the devices doesn't support it (hasFrequencyCorrection returns false). But maybe SoapySDR should implement it itself, by claiming it's always available, and using software correction if hardware correction is unavailble?

[guruofquality]

The idea of adjusting the main oscillator ppm is that any RF frequency when tuned will match the reference perfectly after the adjustment. To know how the adjustment will effect the RF synthesizer at different frequencies is very hardware specific.

So I think implementing setFrequencyCorrection/hasFrequencyCorrection totally in software for a given module is just fine. If you want a particular support module to have the support, just make a PR in the repo, like SoapyHackRF.