SATNOGS_PPM_ERROR with USRP

Hello,

I think this is something I looked at in the past, but I do not remember the conclusion, and I never solved the issue as the station has been down for quite some time.

From the setup wiki I see that the SATNOGS_PPM_ERROR is not available with the following modules:
SoapyUHD
SoapyPluto

I have an USRP1 with about 12ppm frequency error. Is there a way to correct the frequency? I was thinking to compute the frequency correction in the pre-pass script, but then I have no idea how to apply the value during the pass. Is there a way to do that? Or any other suggestion?

Thanks
Alberto

Hi Alberto,

this is a recurring problem we do not have a good answer to.

Currently satnogs-client uses the frequency correction methods of the radio driver to correct for offsets of the LO. Those are exposed in a unified way by SoapySDR in the “Frontend Correction API”. Unfortunately as you pointed out correctly this is not available on UHD & Pluto devices.

It was discussed in the past to implement the frequency correction at a different place in the stack, common to all devices, but not implemented.

A suggestion to SoapySDR to provide such a device-independent frequency correction API was dismissed (see issue SoapySDR#291), with “To know how the adjustment will effect the RF synthesizer at different frequencies is very hardware specific”. I’m still not completely sure this is true, so maybe continuing discussion in this issue might be a good way forward (this would solve problems not only for SatNOGS but all Soapy users).

I do not see a method to use a pre-observation script to adjust the frequency. The rx frequency gets ultimately passed to the gnuradio flowgraph in satnogsclient/radio/flowgraphs.py#L151. I do remember that there was a reason why the SATNOGS_PPM_ERROR shouldn’t be applied there. One reason is certainly that all frequency measurements by the flowgraph (e.g. for doppler tracking via artifacts) will be off, but there were other reasons as well.

Sincerely,
Fabian