What is the relation between sdrplay, soapy/gr-osmosdr and gqrx?

[Michael Strecke]

Hi,

I'm trying to get gqrx and a RSP2 to work under Linux (Ubuntu 18.04) and MacOSX (10.12.6) and I've run into some strange phenomena (see below). Before I fiddle with these system further, I would like to know how things are supposed to work.

From what I've read I get the following picture - please correct me if I'm wrong:

• For a RSP2 a hardware driver is needed. It can be downloaded at sdrplay.com.
• Then there is middleware like soapy or gr-osmosdr that knows how to talk to the driver and provides a common interface to applications - also for other radio hardware. They may differ in what features they expose.
• And then there is the application - gqrx - which knows how to talk to the middleware.

The problem starts if after a fresh install or an update  some versions change.

There are plenty of opportunities:

• The sdrplay driver you can currently download had its own API version bumped up from 0.6 to 0.7 at the beginning of this year. Older versions which you might need are AFAIK not available from that site.
• The version of the soapy middleware - which is currently bundled with gqrx (I presume) - only understands sdrplay API 0.6.
• Newer versions of gr-osmosdr do understand sdrplay API 0.7. But this version seems only to be bundled with the tar.gz Linux version.
• For Ubuntu users there are two gqrx versions one can install:
• via the packet manager (and PPA repositories) and
  
• as the tar.gez file mentioned before ("Generic Gqrx binary package for 64 bit linux" from gqrx.dk).
  

On the Mac, I have two versions of gqrx running: 2.9 (from my Download folder) + 2.11.5 (from the website).

The installed sdrplay version is 2.11.2 (from my Download folder - API 0.6. Currently available at sdrplay.com is 2.13.2 – presumably API 0.7).

• If I start the Mac and execute the newer gqrx version, the RSP2 is not found.
• If I then start the older gqrx version, the RSP2 is available.
• If I then execute the newer gqrx version again, the RSP2 will also be found.

At this point I've got the overwhelming feeling that I'm missing something.

• Can gqrx talk directly to the soapy middleware or does it use gr-osmosdr for this task?
  gqrx -> soapy -> RSP2    OR    gqrx -> gr-osmosdr -> soapy -> RSP2 ?
• Are soapy and gr-osmosdr libraries shipped with gqrx?
• Does version X of gqrx uses the same versions of soapy/gr-osmosdr on all plattforms (Linux/PPA, Linux/TAR, Mac/PKG)?
  
• Are these libraries being “installed”?
• They presumably get overwritten if I compile and install them from source?
• Is there any other important point that I’m missing which can mix things up?

Thanks

Michael

[andrea montefusco]

On Tue, Sep 4, 2018 at 11:07 PM, Michael Strecke <michael...@gmail.com> wrote:

• Can gqrx talk directly to the soapy middleware or does it use gr-osmosdr for this task?
  gqrx -> soapy -> RSP2    OR    gqrx -> gr-osmosdr -> soapy -> RSP2 ?

gqrx will talk with the currently installed gr-osmosdr library.

If you look to the very first rows gqrx is printing on its terminal, you can see the version of gw-osmosdr and the list of devices supported by that specific release found.

--

Andrea Montefusco IW0HDV
------------------------------------------
As my old boss, an Apollo veteran, would often remind us “It’s good to be smart, but it’s better to be lucky.”
   Wayne Hale, Space Shuttle Flight Director

[Alexandru Csete]

Hi Michael,

As Andrea said, gqrx only talks to gr-osmosdr. It is then gr-osmosdr
that interfaces to the SDRPlay either through SoapySDR or its own
backend (which doesn't work but there is an updated version in Jeff's
repository: https://github.com/willcode/gr-osmosdr )

The Ubuntu PPA method will install things under /usr/. The AppImage,
tar.gz and mac DMG run locally without installing anything. Thus, if
you install any of the dependencies from source (by default under
/usr/local), it will conflict with the PPA and will be ignored by all
the other packages.

You can install SoapySDR 0.7 but then you need to rebuild gr-osmosdr
and presumably also gqrx. When you rebuild gr-osmosdr you also need to
make sure you have the dev packages for the other SDR devices
installed, otherwise your gr-osmosdr build will not support them.
There are ways to build and install software in your own home
directory, isolated from /usr/ and /usr/local/ but it is beyond what I
have time to explain.

Yes, it is broken at the architectural level and the fix is to write
something from scratch; though a significant part of the problem is
that the SDRPlay driver is closed source and can not be distributed
through e.g. the PPA.

I may need to make some changes because of the new bladeRF 2.0 micro.
If I have some time (unlikely) I may try to update the SDRPlay support
as well.

Alex

On Tue, Sep 4, 2018 at 11:07 PM, Michael Strecke
<michael...@gmail.com> wrote:

[Alexandru Csete]

I thought you meant SoapySDR 0.7 but there is no such release:
https://github.com/pothosware/SoapySDR/releases

So it is the sdrplay API that is version 0.7 and is available in
package version 2.13???

Anyway, in that case, all you may have to do is to rebuild the
soapysdr-sdrplay plugin version 0.6.1 - at least in theory.

Alex

[Michael Strecke]

This certainly clears some things up....

I'm still trying to explain the strange phenomena on my Mac that I wrote about:

• Newer version of gqrx does not find the RSP2.
• Then an old version of gqrx is started and finds the RSP2.
• After that also the newer version of gqrx sees the RSP2.
  

If I understand you correctly, each Mac DMG of gqrx comes with its own version of gr-osmosdr and soapy.

Only the older ones seems to work.

How can the newer gqrx then access the RSP2 when it failed previously?

Thank you for your time and patience

Michael