Thanks @uy0ll for digging into this. Maybe this helps in finding the proper way to re-implement the frequency correction feature within the new gr-soapy-based satnogs client code.
I followed your hints and would like to add some remarks.
I don’t see an error within in gr-soapy here: The function source_impl::set_frequency_correction is a wrapper around {SoapyRTLSDR|Device}::setFrequencyCorrection and should work correctly when called. Unfortunately I don’t think it’s called with a non-zero value by the flowgraphs currently. The flowgraph template for the gr-soapy source block is calling it at soapy_source.block.yml#L371-373 using the correction0 parameter, but this parameter is always zero in all satnogs-flowgraphs (e.g. iq_receiver.grc#L402-403).
The config variable (edit 2020-03-10T20:40: SATNOGS_DEV_ARGS is deprecated and has no effect in the new gr-soapy-based satnogs client software stack, but unfortunately wasn’t removed from satnogs-client yet. I just opened issue satnogs-client#373 to fix this.SATNOGS_DEV_ARGS got a new meaning with gr-soapy, see gr-soapy#64 (comment 301344183) for its effects in gr-soapy v2.0 and earlier). It can be easily confused with the new SATNOGS_SOAPY_RX_DEVICE which serves a similar purpose now.
Sry, I think the if (name == "CORR") condition can’t be met within any SatNOGS station with latest software atm. Reason:
This code is part of SoapyRTLSDR::setFrequency,
it gets called only once by gr-soapy in
source_impl::set_frequency(size_t channel, const std::string &name, double frequency),
but in turn this gr-soapy function gets never called. And the simpler
source_impl::set_frequency(size_t channel, double frequency) is used
instead.
tl;dr: I can’t see the possibility to configure any frequency correction without modifying the flowgraphs in the latest satnogs client software stack. But it would be possible to re-implement this (lost) feature.