report the exact tuned frequency

[mossmann]

When tuning to a user-requested frequency there is a small amount of error. We should provide a way, perhaps in a debug command-line tool, to retrieve the actual frequency the HackRF has actually tuned to (or equivalently the amount of error with respect to the user-requested frequency).

┆Issue is synchronized with this Basecamp todo by Unito

[odrisci]

This would be very useful for GNSS (satnav) applications. I recently published a short paper on this here. I have some hacky code knocking about somewhere, I'll post a link here once I push it online

[Sasszem]

I see this issue is quite old. Is a solution planned for it?
I see there are PLL calculations for both frequency and sample rate, but none of those is accessible host-side.
We can copy the firmware code like in #1223, but the algorithm might change and we get the wrong results (altough sample rate calculation haven't changed in a decade, the tuning algorithm did).
I think another possible solution would be to add a new vendor request that requests the same calculation from the firmware. This would be future-proof, but would also be incompatible with all current devices & programs.

[martinling]

A new vendor request that gets the actual frequency from the firmware is definitely the right way to do this.

Software is going to have to be updated whatever we do, because there's currently no API in libhackrf for programs to get the actual frequency; they're going to have to call new functions.

For software that uses libhackrf via wrapper libraries like gr-osmosdr or SoapySDR, it would be sufficient to just update the wrappers, because they both provide their own APIs to retrieve the actual frequency (gr-osmosdr API, SoapySDR API). Once those wrappers are updated to use the new libhackrf API feature, they can just return the results via their own APIs, and programs that use them should just work accordingly.

I don't think it's a problem to require a firmware update for this feature to work. But if we wanted to, it may be possible to make it work with older firmware versions too.

We want to ensure that new firmware versions are free to change their tuning algorithm, but we don't expect old firmware versions to change theirs. So a way to do it would be to have libhackrf first read the firmware API version. In the case of a new-enough version, use the new vendor request, and in the case of an older version, run the same tuning calculation within libhackrf that was known to have been used in that version of the firmware, and return the predicted result.