Frequency update doesn't always seem to work

[cjcliffe]

Leaving this issue here at the moment since I think it's only relevant to SoapyRTLSDR -- when tuning quickly in CubicSDR occasionally the last frequency update doesn't seem to "take" and the data being sent doesn't match the center frequency..

[guruofquality]

I wonder if its a bug in the RTL driver itself or a limitation of the hardware. Like are the retune's asynchronously happening in the hardware? Or can they get cancelled interrupted by the state of another re-tune. Its not like the Soapy RTL wrapper has very much in the way:

void SoapyRTLSDR::setFrequency(
        const int direction,
        const size_t channel,
        const std::string &name,
        const double frequency,
        const SoapySDR::Kwargs &args)
{
    if (name == "RF")
    {
        centerFrequency = (uint32_t) frequency;
        resetBuffer = true;
        SoapySDR_logf(SOAPY_SDR_DEBUG, "Setting center freq: %d", centerFrequency);
        rtlsdr_set_center_freq(dev, centerFrequency);
    }

Are the CubicSDR calls to setFrequency always coming out of the same thread? Multiple threads could cause an issue here.

As sort of a side note/curiosity: what happens when a user drags a slider and a barrage of gain/tune settings are produced faster than they can be applied? Does CubicSDR throw out the older settings that haven’t yet been applied so you don't get an ever growing queue of stale settings?

[cjcliffe]

@guruofquality it just sets the value and an atomic flag in my SDR thread so that all the updates happen before the next readStream() -- so it should all be synchronous and only ever set once to the last value per read loop.

It's also possible I'm getting back an old frequency value before the new one gets updated somehow; I'll do some experiments to try and find out where the issue is.

[cjcliffe]

Just to add a note to this; in particular it only really seems to happen while using SoapyRemote on the Pi or through the chain of sh*tty USB hubs on the iMac at work. It may not be a problem with SoapyRTLSDR but perhaps just the hardware itself overflowing / failing to update introducing the error.

[tenzap]

For me, frequency update never works and fails with this error rtlsdr_demod_write_reg failed with -9 Which points to a LIBUSB_ERROR_PIPE ( http://libusb.sourceforge.net/api-1.0/group__misc.html )

According to https://github.com/roger-/pyrtlsdr/issues/55 the problem is likely to be caused by the use of rtlsdr_read_async. The post in the URL above suggests to call rtlsdr_cancel_async before setting the frequency.

[guruofquality]

This is an ancient issue, closing. But if there is a need to return while streaming and the driver cant support it. A PR that calls rtlsdr_cancel_async() and I presume restores the state sounds good to me. I think i recall that not being an issue but maybe its a just always been a race in some cases?

[cjcliffe]

Seeing this issue on Mac but now in Ubuntu 18 consistently here as well; going to re-open and will see if I can make a fix with @tenzap's suggestion -- which makes sense when it's doing async read

[zuckschwerdt]

I'm using both librtlsdr and SoapyRTLSDR, and I stop the (async) stream before changing settings. It works well. Conversely, changing settings on a running stream reliably shows errors.

Perhaps just cleanly error when a stream is running and leave the handling to the app? I would be surprised if there was a discontinuity in the stream. Edit: the proposed sequencing of settings and rtlsdr_read_async() looks good!