You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
💡 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.
📖 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 pothosware/SoapySDR#291
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.
📖 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 pothosware/SoapySDR#291
CC. @janvgils
The text was updated successfully, but these errors were encountered: