CubicSDR v0.2.2 not seeing SDRplay v1

[MiamiC70]

SDRplay works with CubicSDR v0.2.2-alpha however, when I install the latest version of CubiSDR v0.2.2 it does NOT see the SDRplay. I have tried manually refreshing and adding and it does not work. I had to revert to alpha version to get it working again.

[sdrplay]

When this happens it normally means that SoapySDR and SoapySDRPlay need to be rebuilt. I've no idea what the dependency is but this has worked on new builds in the past.

Best regards,

SDRplay Support

[MiamiC70]

I installed the latest version of Soapy as well.

[sdrplay]

If you've got the latest API, built SoapySDR and SoapySDRPlay and the following command doesn't work then it's not related to CubicSDR...

SoapySDRUtil --probe=sdrplay

Best regards,

SDRplay Support

[MiamiC70]

Not related? Yet when I do nothing but reinstall older version it magically starts working.
Quite a "coincidence don't you think?

[sdrplay]

CubicSDR knows nothing about the RSP - all communication from CubicSDR is via the SoapySDR module. So there could be an issue with comms between CubicSDR and SoapySDR but it can't directly be between CubicSDR and the RSP

That's why I'm suggesting to break down the problem. Does SoapySDRUtil work correctly? If so, then the issue is between CubicSDR and SoapySDR - if not, then that's the place to focus on.

Did you test the SoapySDR - RSP connection with the latest build of SoapySDR and SoapySDRPlay?

As I said, the only time I've seen this (and it does happen occasionally) is when the versions of CubicSDR and SoapySDR/SoapySDRPlay get out of sync.

Best regards,

SDRplay Support

[Alrescha]

I can confirm the behavior. CubicSDR v0.2.2-alpha can see the RSP1, but v0.2.2 does not. This is with lib version v0.6.0-g9cb32fa9.

It would be nice if Charles and the SDRPlay folks could put their heads together and solve this.

A.

[sdrplay]

I'll need specifics to be able to help. I've just built SoapySDR, SoapySDRPlay and CubicSDR all from their respective master sources on github. I'm on Ubuntu 16.04 Linux x64 Desktop PC and CubicSDR 0.2.2 is running fine and has no problems using either RSP1 or RSP2

As I've said I've seen this before when pre-built binaries have been used and it's always been an issue between CubicSDR - SoapySDR versions.

Best regards,

SDRplay Support

[Alrescha]

Not to put too fine a point on it, but I am not asking for 'help'. I am a customer. If I wanted to be a developer I would go back to work. A major factor in my purchasing decision for the SDRPlay was that it had macOS support - as advertised by you.

The developer who makes the *only* native macOS software for your product released v0.2.2 a month ago. It does not work with your current driver. Does this not interested you? You host this developer's software on your own site - albeit an outdated and unsigned version. Why is it not up-to-date? (why is it not *signed*)

Do you tell your Windows customers to install a development environment and 'rebuild'?

A,

[sdrplay]

It's the first time any one in this thread has mentioned a specific platform, so it's been difficult for me to understand what isn't working.

The CubicSDR github repository is updated almost daily - it's not possible for us to keep totally up to date with these builds. We provide installs as a courtesy for those customers that don't want to build the software. Most 3rd party SDR software requires some degree of building, particularly those that are cross platform.

Many customers also use SDRuno in a Windows virtual machine on a Mac

I'll rebuild the Mac SoapySDR/SoapySDRPlay and CubicSDR installs and push to the website this evening.

Best regards,

SDRplay Support