Open kerel-fs opened 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?
💡 Feature request Allow non-integer frequency corrections via
SoapyRTLSDR::setFrequencyCorrection(const int direction, const size_t channel, const double value)
and properly handle them. Aslibrtlsdr
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