Added option to specify frequency offset

[catkira]

ADALM Pluto usually has quite a large frequency offset (mine has 20 kHz). Many applications cannot handle this offset (ie srsRAN). With this option srsRAN's cellscan works if I specify 20 kHz offset.

[catkira]

sorry for the two commits, also sorry for the spaces instead of tabs, but feel free to modify it :)

[zuckschwerdt]

No worries about commits, we can squash on merge.

Can you explain this change in more detail? I.e. wouldn't that report the wrong center frequency? Usually sample rate and center frequency are corrected with a parts-per-million adjustment. Is this a correction value like PPM? Are you then sure it's not PPM but linear?

And should the device discovery find_PlutoSDR() really repeat back random settings? We don't usually do that, e.g. for buffer sizes.

[zuckschwerdt]

IIRC if you are at, say, 2000 MHz and want to effect a +20 kHz change, that should be a frequency correction of 10 PPM.

[catkira]

The reason why I put it into find_PlutoSDR() is that srsRAN only hands the additional soapy arguments to the find call. Then when opening the device it uses the args that find_PlutoSDR() returned, but not the args that the user specified at command line. So doing it like this was the only way to pass the option from srsRAN to Soapy - otherwise I would have to modify srsRAN as well. To do the cellscan I call (my Pluto has -20 kHz offset) ./cell_search -b 3 -s 1300 -e 1301 -d Soapy -a frequency_offset=-20000 The correction value here is in Hz. The sample rate of my pluto has a similar error (also around 10ppm), but srsRAN can handle that. I think sample rate error is better handled by the tracking algo. It might be worth to change it to PPM, because that would probably be more suitable when using different center frequencies.

[catkira]

I think the frequency error comes from oscillator offset, so it will probably appear as a ppm offset rather than an absolute offset. I will change this feature to accept frequency offset as PPM.

[zuckschwerdt]

PPM correction is a well established concept, I'd say most client software is able to open devices and then pass a correction value. Ideally this should be fixed "downstream". I.e. cell_search should be able to accept a center frequency and a PPM correction, then use https://github.com/pothosware/SoapySDR/blob/master/include/SoapySDR/Device.h#L754 or https://github.com/pothosware/SoapySDR/blob/master/include/SoapySDR/Device.hpp#L671

[catkira]

ah I didn't know Soapy already has infrastructure for frequency correction. I will make SoapyPlutoSDR use this interface then and make srsRAN to use this interface.

[catkira]

I already changed it to PPM, I will add usage of Soapy CFO API later when I have time...

[catkira]

Does Soapy have a separate API for frequency and sample rate offset? (I dont see it in the header file) Usually they are the same, but they can be different in rare cases. If Soapy does not have a separate sample rate offset API, the question is what setSampleRate() should do when a frequency offset is given. Should it use the same PPM value also for sample rate?

[zuckschwerdt]

The value we are looking for (PPM correction) is xo_correction in the IIO API for the AD9361. It might even be a firmware setting. Some additional info might be here: https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms2-ebz/hardware/tuning#oscillators – note the use of iio_attr to adjust the value.

I'd say that usually sample rate and frequencies are derived from the same oscillators. There is only one common frequency correction in the API. But it's more flexible using the "CORR" element on setFrequency() https://github.com/pothosware/SoapySDR/blob/master/include/SoapySDR/Device.hpp#L809

[zuckschwerdt]

Ah yes, seems the xo_correction is a config value and can be persisted: https://wiki.analog.com/university/tools/pluto/users/customizing#config_file

Can you experiment with that and change the PR to just add this info to the README?

Adding the setFrequencyCorrection() / "CORR" API wouldn't be nearly as useful I'd say.

[catkira]

Ah thanks for looking that up for me (that should have been my job) :) I added xo_correction = 39999600 to config.txt and now I dont need any additional correction anymore. So one just has to apply the PPM correction to the 40 MHz frequency of the installed oscillator.

I will change the PR later.

[zuckschwerdt]

Add something like "Note that the Frequency Correction API is not implemented, it's recommended that you adjust the xo_correction value with the observed PPM in the Pluto device config.txt."

[zuckschwerdt]

Fixed with a07c372.