Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SoapySDR crashes trying to use the SDRPlay slave option. #356

Open
righthalfplane opened this issue Jun 2, 2022 · 4 comments
Open

SoapySDR crashes trying to use the SDRPlay slave option. #356

righthalfplane opened this issue Jun 2, 2022 · 4 comments
Assignees

Comments

@righthalfplane
Copy link

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
Copy link

fventuri commented Jun 3, 2022

@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 fventuri self-assigned this Jun 3, 2022
@fventuri
Copy link

fventuri commented Jun 3, 2022

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
Copy link
Author

righthalfplane commented Jun 3, 2022

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
Copy link

fventuri commented Jun 3, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants