pothosware / SoapyRTLSDR

SoapySDR RTL-SDR Support Module
https://github.com/pothosware/SoapyRTLSDR/wiki
MIT License
124 stars 29 forks source link

Allow non-integer frequency error correction #56

Open kerel-fs opened 3 years ago

kerel-fs commented 3 years ago

💡 Feature request Allow non-integer frequency corrections via SoapyRTLSDR::setFrequencyCorrection(const int direction, const size_t channel, const double value) and properly handle them. As librtlsdr supports integer ppm corrections only, this would either require modifying the library or applying the frequency correction in SoapyRTLSDR itself.

🎯 Goal We are using soapysdr via gr-soapy in the SatNOGS satellite ground stations. A user-provided parameter SATNOGS_PPM_ERROR is passed from the gnuradio flowgraph via gr-soapy to the Soapy Frequency Correction API, to correct for freq errors (e.g. -1 ppm for -1.220 ppm or -3 ppm for -2.675 ppm). A 0.5ppm error at 440Mhz is 0.22 kHz. In some cases even an offset of 0.5 kHz made it difficult to decode some signals (issue tracked at satnogs-client-ansible#90).

Allowing non-integer corrections like -1.220 ppm will reduce the residual error to 0.001 ppm / 0.4 Hz@440MHz, which is small enough.

:book: Related issues

As the support of Frequency Error Correction via the Soapy Frontend Correction API is limited to only a few devices (RTL-SDR & SDRPlay afaik), maybe this can be handled in SoapySDR itself. See https://github.com/pothosware/SoapySDR/issues/291

CC. @janvgils

zuckschwerdt commented 3 years ago

regarding #291 you meant that the other way around: implement hardware specific correction in each module, right? The calculation in librtlsdr looks simple and could use the improved precision if we could apply it there. It's also used via rtlsdr_get_xtal_freq(), not sure if that's linear?