SoapySDR crashes trying to use the SDRPlay slave option.

[righthalfplane]

When I tried to run SdrGlut using the SDRpay slave mode it would always crash. I finally tracked it down.

It crashes if you call -

device->setFrequency(SOAPY_SDR_RX, rx->channel, rx->fc-rx->foffset);

but if you call -

device->setFrequency(SOAPY_SDR_RX,0,"RF",rx->fc-rx->foffset);

it works. I thought that the first one just calls the second.

[fventuri]

@righthalfplane - I think it is actually a little more complicated than that.

If you look at the source code for the function setFrequency(direction, channel, frequency, [args]) (https://github.com/pothosware/SoapySDR/blob/master/lib/Device.cpp#L360-L398), you'll see that it uses this algorithm (assuming args is empty): go though all the frequency names (in the case of the SoapySDRPlay3 module, these are just "RF" and "CORR" - see here: https://github.com/pothosware/SoapySDRPlay3/blob/master/Settings.cpp#L641-L642), and for each of them try to assign "as much as possible" of the requested frequency, get the remainder, and assign that "quota" of frequency to the next frequency type.

For instance, assuming that the client requested a frequency of 100MHz, this algorithm would try to set the "RF" frequency to 100MHz, read the frequency back from the device, compute the difference, and try to assign that remaining "quota" of frequency to the next frequency type, i.e. "CORR" (which in that case doesn't make much sense, since "CORR" is the frequency correction in ppm).

The problem you experienced might be that for in the case of an RSPduo in slave mode, the frequency correction cannot be assigned by the slave since it is under full control of the master, and I suspect this could be the cause of the crash.

Franco

[fventuri]

Out of curiosity I just looked at what CubiCSDR (which I use as my reference in these cases) does, and I see that they always use the SoapySDR function setFrequency(...) with the string of the frequency type (for the "RF" cases see: https://github.com/cjcliffe/CubicSDR/blob/master/src/sdr/SoapySDRThread.cpp at lines 109, 551, and 554), i.e. they never use the setFrequency(...) function that has just direction, channel, and frequency as the arguments (the one whose algorithm I discussed in my previous comment).

Franco

[righthalfplane]

I did look at CubicSDR and that is why I tried the change.

I have always used the version with out the "RF" until now in dozens of test programs and on rare occasions it had this problem - it acts like the address to setFrequency has been over written with a zero - and crashes - no clue as to why ? This is the first time I tried to track down the problem.

The Dual Tuner (independent RX) version works fine without the "RF" and I just verified that it works with it also.

I will be using the "RF" version from now on.

I also found that the "RSPduo sample rate=8mhz" does not work - I posted that on the SoapSDRPlay3 issues.

[fventuri]

As I said in my previous comment, the problem you saw might be specific only to the RSPduo in Slave mode (but not Dual Tuner or Master mode), because in that mode changes to the frequency correction (ppm) parameter are not allowed.

You should be able to see if this is the case by inserting a statement right before the 389 in SoapySDR Device.cpp source file (https://github.com/pothosware/SoapySDR/blob/master/lib/Device.cpp#L389) to print out both name (name) and residual frequency (freq) to see if the CORR (frequency correction) name is being used while in Slave mode.

Franco