SoapySdr and OsmocomSDR on OSX

[Jose Martinez Jr.]

I'm trying to setup a remote SDR (rtl-sdr now, limesdr next year). I have a Raspberry Pi2B (Debian) with SoapySDR/SoapyRTLSDR/SoapyRemote correctly detecting my NooElec dongle and runing the remote server.

I would like to acces that remote SDR from my Mac initially using the "Spectrum Browser". I was not able to find any guide to do this but found enough info to understand (I think) that on the Mac I need to install:

1) SoapySDR
2) SoapyOsmo (cmake .. -DUSE_OSMO_RTLSDR=ON)
3) Osmosdr (enabled for SoapySDR)

Can anyone comfirm my steps and possibly help with #3.

[Josh Blum]

On 08/27/2016 06:59 PM, Jose Martinez Jr. wrote:
> I'm trying to setup a remote SDR (rtl-sdr now, limesdr next year). I have a Raspberry Pi2B (Debian) with SoapySDR/SoapyRTLSDR/SoapyRemote correctly detecting my NooElec dongle and runing the remote server.

Thats correct.

>
> I would like to acces that remote SDR from my Mac initially using the "Spectrum Browser". I was not able to find any guide to do this but found enough info to understand (I think) that on the Mac I need to install:
>
> 1) SoapySDR
> 2) SoapyOsmo (cmake .. -DUSE_OSMO_RTLSDR=ON)
> 3) Osmosdr (enabled for SoapySDR)
>
> Can anyone comfirm my steps and possibly help with #3.
>

I assume by "Spectrum Browser", you mean GrOsmoSDR's fft plotter. So for
the host side on the Mac, you need

1) SoapySDR as well
2) SoapyRemote for the client module
3) GrOsmoSDR built with Soapy support

So you dont need SoapyOsmo at all. Thats basically hardware module
support for a few devices that do not otherwise have their own dedicated
project.

However you will need GrOsmoSDR with soapy support. There is more than
one way to build GrOsmoSDR from source (like manually, homebrew,
macports). In any case, GrOsmoSDR will automatically build the soapysdr
bindings when the development files are found. So its best to check the
cmake output to confirm this.

The device args to use with GrOsmoSDR to make this work:
"soapy=0,driver=remote,remote=ip_or_hostname"

That should do it, but if it help, there is more information here:
https://github.com/pothosware/SoapyRemote/wiki#remote-device-args

Cheers!
-josh

[Jose Martinez Jr.]

Josh, first off than kyou for the quick reply. So (on my mac) I installed (from source) SoapySDR, SoapyRemote and GrOsmoSDR as mentioned; No issues during install at all, including the cmake of GrOsmoSDR said it included SoapySDR support. Just to check things I ran SoapySDRUtil and it found the device but is not available:

 

hose$ SoapySDRUtil --find="remote=sdr"

######################################################

## Soapy SDR -- the SDR abstraction library

######################################################

Found device 0

  available = No 

  driver = remote

  label = Generic RTL2832U OEM :: 00000001

  manufacturer = Realtek

  product = RTL2838UHIDIR

  remote = tcp://sdr:55132

  remote:driver = rtlsdr

  rtl = 0

  serial = 00000001

  tuner =  

 Then when I try to run osmocom_fft I get this:

hose$ osmocom_fft -a "remote=sdr,remote:driver=rtlsdr,remote:soapy=0"

Mac OS; Clang version 7.3.0 (clang-703.0.31); Boost_105900; UHD_003.009.004-MacPorts-Release

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.10

built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy   >>>NO SoapySDR mentioned

FATAL: No supported devices found to pick from.  >>> I assume because SoapySDRUtil said it was not available.

Trying to fill up 1 missing channel(s) with null source(s).

This is being done to prevent the application from crashing

due to gnuradio bug #528.

Source has no sample rates (wrong device arguments?).

 

Any thoughs as to what went wrong ??

[Josh Blum]

> gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.10
>

> *built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace
> airspy* *>>>NO SoapySDR mentioned*
>

"soapy" should be in the list after airspy

https://github.com/osmocom/gr-osmosdr/blob/master/lib/source_impl.cc#L160

>
> Any thoughs as to what went wrong ??
>

It really looks like GrOsmoSDR didn't get built with SoapySDR support.
One ore two thoughts...

1) Is it possible that you have two different versions of
"libgnuradio-osmosdr.so" on your system? Like an older one that was
built prior. Different build tools like macports might have installed
into a different location than manual source build. The system could be
loading the older library (for example).

2) Short of that.. can you share the cmake and build output in like a
pastebin or something? I might be able to spot something. But being in
the list of enabled components should be sufficient.

-josh

[Jose Martinez Jr.]

Josh,

I'm getting killed with an issue with the HybridDrive on my mac, so I will probably have to re-create my entire system. However the answer to your query is yes/no. Yes there was a version of GnuRadio installed via macports. No because I could not find any library by the name of libgnuradio-osmosdr.so. That can be caused by my disk issues.

I will shout back at you later when this is resolved by Apple and I'll be starting from scratch again...

Thanks for the help so far, I would like to get this running with the RTL dongle before I move to the LimeSDR next year...

 

[Jose Martinez Jr.]

Josh,

As I suspected I had to rebuild my system from scratch. Now a clean slate. Being the gr-osmosdr needs GnuRadio (or parts of it) to install correctly what order do you suggest I install the components using MacPorts.

[Josh Blum]

Yes, you are going to need gnuradio for gr-osmosdr.

I'm not very familiar with MacPorts (been testing more with homebrew).
But as far as I understand, SoapySDR is in macports now. I dont know
which which modules are in there (like rtl), or if gr-osmosdr ports
package was updated for this yet. Presumably, if you install SoapySDR
first in macports, then the gr-osmosdr package will automatically build
it. More details in this issue:
https://github.com/pothosware/SoapySDR/issues/71

Presumably, some stuff can be installed from ports, and other stuff
installed from source with "manual building". But I suggest trying the
install out, see what happens, and iterate. I'm willing to help debug
and document the procedure.

-josh

PS - Just for reference, this is the homebrew tap that I maintain:
https://github.com/pothosware/homebrew-pothos/wiki
And dholm maintains gr-* tab for brew including gr-osmosdr that pulls in
soapysdr automatically: https://github.com/dholm/homebrew-sdr/

[Jose Martinez Jr.]

Josh,

So I (had) used MacPorts a long time ago to install GnuRadio just to see what it was like, with the dongle plugged into my mac. So now since I'm starting with a new system, I took a look at "HomeBrew" and it's looked really easy to install and get packages; So I installed it and your pothosware tap as well as dholm's tap and looked at the available formulas. NICE... especially  since I write my scripts using Python 3.5.

So following what you suggested on this post (earlier) for me, I should first install the soapy stuff then the gr-osmosdr (from dholm) so that it builds with soapy support :

brew install soapysdr --with-python3

brew install soapyremote --with-python3 (needed here ??)

brew install gr-osmosdr

I'll let you know how it goes. Again thanks very much for your help.

PS: I see you have the formula for LimeSDR, now all I need is for Lime to ship my board. Xmas gift perhaps !

[Jose Martinez Jr.]

Josh,

So I installed SoapySDR on my iMac (El Capitan) using your tap as follows:

brew install soapysdr --with-python3

brew install soapyremote --with-python3

Then:

himac:~ hose$ SoapySDRUtil --find="remote=sdr, driver=remote"

######################################################

## Soapy SDR -- the SDR abstraction library

######################################################

Found device 0

  available = No

  driver = remote

  label = Generic RTL2832U OEM :: 00000001

  manufacturer = Realtek

  product = RTL2838UHIDIR

  remote = tcp://sdr:55132

  remote:driver = rtlsdr

  rtl = 0

  serial = 00000001

  tuner = 

Finds the SoapyServer and the device, but still says it's not available. Before I continue with the GNU stuff, is this status "available=no" normal or do I need fix something in the server at this point.

 

[Josh Blum]

>
>
> Finds the SoapyServer and the device, but still says it's not available.
> Before I continue with the GNU stuff, is this status "available=no" normal
> or do I need fix something in the server at this point.
>
>

It looks like the driver does a test to see if it can open the rtl
device handle. I'm not sure why its failing to open. But sometimes a
kernel driver will attach itself to the rtl, which could be the cause.
You may have to rmmod something.

Are you able to run --make on the server/the actual device which the rtl
is attached to? SoapySDRUtil --make="driver=rtlsdr"

-josh

[Jose Martinez Jr.]

You were right. I ran the SoapySDRUtil --make="driver=rtlsdr" and sugedted that I blacklist dvb_usb_rtl28xxu so I did. Now the device shows up as available. So it's on to gr-osmosdr...

Thanks again, but I don't think you've heard the last of me :-)))

[Jose Martinez Jr.]

[Jose Martinez Jr.]

Woops, accidental enter, posted orig. question.

Well did not take me long at all to install GnuRadio (via brew) and then build gr-osmosdr from source; After a couple of issues with missing python modules (Cheetah, pnum) I was able to run osmocom_fft successfully !!!

ALL thanks to your help.

So a couple of more questions for now, at least until I get the LimeSDR ....

1. Do you know if there's support in GQRX (or any other OSX  SDR app) for SoapySDR; Their website points to yours, but you don't mention it.
2. Is there a good comparison that I can read between Pothos and GnuRadio; I Googled for one but came up empty.

Thanks

[Josh Blum]

On 09/05/2016 01:24 PM, Jose Martinez Jr. wrote:
>
>>
>> Woops, accidental enter, posted orig. question.
>>
>
> Well did not take me long at all to install GnuRadio (via brew) and then
> build gr-osmosdr from source; After a couple of issues with missing python
> modules (Cheetah, pnum) I was able to run osmocom_fft successfully !!!
>
> ALL thanks to your help.

Cool, glad to hear its working.

Did gr-osmosdr not build under dholm's recipe? If its a brew build, it
should being in the correct dependencies automatically. If not, it would
be something good to report so it can be fixed.

>
> So a couple of more questions for now, at least until I get the LimeSDR ....
>
>

> 1. Do you know if there's support in GQRX (or any other OSX SDR app)

> for SoapySDR; Their website points to yours, but you don't mention it.

In general, application developers are going to need to support LimeSDR
just like any other SDR device driver -- in this case, either through
the LimeSuite API or SoapySDR.

Fortunately, applications that already operate on top of gr-osmosdr or
SoapySDR directly are already set, and hopefully future-proofed.
CubicSDR for example is already built directly on top of SoapySDR for
hardware support.

I dont have a complete list of every software package that uses
SoapySDR, but I would like to extend it. Please let me know if there is
something to add. The only reason I didnt list GQRX specifically is that
I though the support was implied by using gr-osmosdr. But I should
probably mention this directly.

> 2. Is there a good comparison that I can read between Pothos and

> GnuRadio; I Googled for one but came up empty.
>

I never really made a formal comparison of any sort.
There is sort of some feature mentioning on this page:
https://github.com/pothosware/gnuradio/wiki

For the most part, gnuradio has been around for longer, and has a larger
established block set and community. I hope that the gr-runtime and
gr-pothos projects mentioned in the link above somewhat mitigate that by
bringing in core gnuradio blocks.

From a developer standpoint, I think that Pothos has a few major pros:
Very minimal boiler plate for writing new blocks, more flexible
licensing (at least for core framework + blocks), unified block API,
better abstractions for control-flow, and working with custom data
types. It might be useful to check out the coding guide:
https://github.com/pothosware/pothos/wiki/BlocksCodingGuide

There are some differences in how the scheduler works, to allow things
like DMA-based blocks, feedback, and circular topologies. You may also
find the scheduler explained wiki interesting as well:
https://github.com/pothosware/pothos/wiki/SchedulerExplained

Of course there is a Pothos GUI to match the framework and API features.
It takes a different approach than GRC which is to manage a live
topology, blocks, and widgets within the editor. Which is interesting,
and it has its own associated challenges. I think some of the biggest
improvements to this software package are going to be in the GUI via
polishing, and finishing off major features.
The tutorial might also shed some extra light here:
https://github.com/pothosware/pothos-gui/wiki/Tutorial

I hope that helps,
-Josh

[Jose Martinez Jr.]

Cool, glad to hear its working. 

 Yes and it works nicely with osmocom_fft. The only issue I've noticed is that after a while ( ~1 to 2 hours) the spectrum display is frozen. Need to look around a bit more to see where the issue is.

Did gr-osmosdr not build under dholm's recipe? If its a brew build, it
should being in the correct dependencies automatically. If not, it would
be something good to report so it can be fixed.

 No it did not work for me, I decided to "robotastic" tap to install GnuRadio and then I installed gr_osmosdr from source.

In general, application developers are going to need to support LimeSDR
just like any other SDR device driver -- in this case, either through
the LimeSuite API or SoapySDR.

Fortunately, applications that already operate on top of gr-osmosdr or
SoapySDR directly are already set, and hopefully future-proofed.
CubicSDR for example is already built directly on top of SoapySDR for
hardware support.

 

 I understand, I saw a youtube video from Marty Wittrock with the LimeSDR and he was using GQRX 2.5.3 with "soapy=0, driver=lime" so it does work, at least directly connected to Linux PC.

I dont have a complete list of every software package that uses
SoapySDR, but I would like to extend it. Please let me know if there is
something to add. The only reason I didnt list GQRX specifically is that
I though the support was implied by using gr-osmosdr. But I should
probably mention this directly.

So as I said above it does work, but I should have been more specific, I'm looking to run the SDR device remotely via SoapySDRServer. That does not seem to work; I used the same device string that I used for gr_osmocom and it does not even connect to the server. I chatted with Alex Cest and opened an issue against GQRX for him to look at in a future release.

osmocom_fft -a "soapy=0,driver=remote,remote=sdr"

osmocom_fft -a "soapy=0,driver=remote,remote=sdr,remote:driver=rtlsdr"

I also found and built rx_tools from Robert Seger to use rx_fm as another tool to access SoapySDRServer; Same result as GQRX.

Do you have any clues for me here ?? 

 

Thanks for the info on Pothos, I'm going to play a bit with it.

Hose 

[Josh Blum]

>
>
> So as I said above it does work, but I should have been more specific, I'm
> looking to run the SDR device remotely via SoapySDRServer. That does not
> seem to work; I used the same device string that I used for gr_osmocom and
> it does not even connect to the server. I chatted with Alex Cest and opened
> an issue against GQRX for him to look at in a future release.
>
> osmocom_fft -a "soapy=0,driver=remote,remote=sdr"
>
> osmocom_fft -a "soapy=0,driver=remote,remote=sdr,remote:driver=rtlsdr"
>
>
> I also found and built rx_tools from Robert Seger to use rx_fm as another
> tool to access SoapySDRServer; Same result as GQRX.
>
> Do you have any clues for me here ??

So I saw the issue for rx_tools, and its a bug for using the device args
in discovery, my suggestion in the issue below:
https://github.com/rxseger/rx_tools/issues/38

But both osmocom fft and gqrx worked for me using those device args
(though obviously with a different hostname for the remote address).

-josh

[Jose Martinez Jr.]

So I saw the issue for rx_tools, and its a bug for using the device args
in discovery, my suggestion in the issue below:
https://github.com/rxseger/rx_tools/issues/38

I'll Robert get rx_tools sorted out.

 

But both osmocom fft and gqrx worked for me using those device args
(though obviously with a different hostname for the remote address).

This one is interesting. Attached is a screen shot of my GQRX window using the actual IP of the server rather than a hostname. Same result for me NADA in GQRX or SoapySDRServer. I'm running on OSX "El Capitan" with GQRX installed from Alex's site "http://gqrx.dk/download". Could this be only an issue in OSX ?

-Hose

[Jose Martinez Jr.]

Loosing my mind with OSX Bootcamp. Forgot the attachments:

 

[Josh Blum]

On 09/09/2016 03:03 PM, Jose Martinez Jr. wrote:
>
>>
>>
>>
>>
>>
>> *So I saw the issue for rx_tools, and its a bug for using the device args

>> in discovery, my suggestion in the issue below:
>> https://github.com/rxseger/rx_tools/issues/38

>> <https://github.com/rxseger/rx_tools/issues/38> *

>>
>> I'll Robert get rx_tools sorted out.
>
>
>>

>> *But both osmocom fft and gqrx worked for me using those device args
>> (though obviously with a different hostname for the remote address). *

>
>
> This one is interesting. Attached is a screen shot of my GQRX window using
> the actual IP of the server rather than a hostname. Same result for me NADA
> in GQRX or SoapySDRServer. I'm running on OSX "El Capitan" with GQRX
> installed from Alex's site "http://gqrx.dk/download". Could this be only an
> issue in OSX ?
>
> -Hose
>
>
>

Just to double check things:

Whats the output of "SoapySDRUtil --info" on the OSX box?

Does this command indeed find the rtlsdr?
SoapySDRUtil --find="driver=remote,remote=sdr"

What message is printed when osmocom_fft is run and fails to find
anything. It usually shows all of the supported drivers:
osmocom_fft -a "soapy=0,driver=remote,remote=sdr,remote:driver=rtlsdr"

-josh

[Jose Martinez Jr.]

Just to double check things:
Whats the output of "SoapySDRUtil --info" on the OSX box?

himac:~ hose$ SoapySDRUtil --info

######################################################

## Soapy SDR -- the SDR abstraction library

######################################################

Lib Version: v0.5.3-release

API Version: v0.5.2

ABI Version: v0.5-2

Install root: /usr/local

Module found: /usr/local/lib/SoapySDR/modules0.5-2/libremoteSupport.so

Loading modules... done

Available factories...null, remote,

 

Does this command indeed find the rtlsdr?
SoapySDRUtil --find="driver=remote,remote=sdr"

himac:~ hose$ SoapySDRUtil --find="driver=remote,remote=sdr"

######################################################

## Soapy SDR -- the SDR abstraction library

######################################################

Found device 0

  available = Yes

  driver = remote

  label = Generic RTL2832U OEM :: 00000001

  manufacturer = Realtek

  product = RTL2838UHIDIR

  remote = tcp://sdr:55132

  remote:driver = rtlsdr

  rtl = 0

  serial = 00000001

  tuner = Rafael Micro R820T 

What message is printed when osmocom_fft is run and fails to find
anything. It usually shows all of the supported drivers:
osmocom_fft -a "soapy=0,driver=remote,remote=sdr,remote:driver=rtlsdr"

Well osmocom_fft does not fail. It works great as listed above.

-Hose 

[Jose Martinez Jr.]

Josh, just an update on my saga. Today I installed CubicSDR and it worked right from the start with my SoapySDRServer. So the issue must be with GqRx on OSX.

When you say it works fine for you, was that on OSX, Linux or Windows ?

 

[Josh Blum]

I just double checked on linux. I don't have an OSX box to test this on,
but as far as I remember, SoapyRemote + CubicSDR + OSX is a pretty
common use case.

I dont think GQRX on OSX is any different in terms of device discovery.
So if SoapySDR is working, the only issue would be if gr-osmosdr isnt
calling into SoapySDR for some reason. I suppose it could be GQRX
itself, but perhaps we can confirm that:

gr-osmosdr does not have a lot in the way of debugging what devices it
sees or what types of drivers are available. There is one print on
source/sink instantiation that shows the drivers available, it should
print soapy:
https://git.osmocom.org/gr-osmosdr/tree/lib/source_impl.cc#n166

After confirming that, I think the best most solid course of action is
to uncomment the prints here. You are going to know exactly what its
doing and what devices are found:
https://git.osmocom.org/gr-osmosdr/tree/lib/source_impl.cc#n244

It would be good to know if something like osmocom_fft shows different
prints than GQRX. If so, we can investigate what args were passed, see
whats different, and why..

Hope that helps in the right direction,
-josh

[Jose Martinez Jr.]

Taking a bit longer than I thought, but I'll get to this test soon.