GQRX throws exception with Airspy HF+ when echanging sample rate etc

[wolfgan...@gmx.net]

Hi,

after long time I lifted my severely patched 2.11.xx gqrx to current master.

Now I get an exception from gqrx with my Airspy HF+ discovery when I try to change sample rate or audio device: "Failed to open Airspy HF+ device (-1)". This exception originates from the gr-osmosdr airspyhf driver.

I see gqrx tries to open the Airspy device again while it is still open.

It  works with my SDRPlay RSP1A.

With "git bisect" on an unmodified master I traced it down to the commit

-------

commit 8b4c2efd394734f120245739e72b6f61e8370e32
Author: Markus Kolb <deleted address>
Date:   Thu Mar 5 18:38:17 2020 +0100

   always (re)set input/output device
-------

Is this a bug in gqrx or is gqrx expecting from device drivers to tolerate opening an already open device?

Regards,

Wolf DK7OB

[Roger David Powers]

Maybe post the output of 'SoapySDRUtil --info' and 'SoapySDRUtil --probe' ?

I have Airspy HF+ Discovery and have been using it on fairly recent builds (late Dec 2020) and it has been working fine.

Regards,
RDP

--
You received this message because you are subscribed to the Google Groups "Gqrx SDR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gqrx+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gqrx/cbee747a-0ce8-445d-83d1-a1edb2388dd3n%40googlegroups.com.

[wolfgan...@gmx.net]

Thanks for your answer!

You are running Airspy HF+ with Soapy? Didn't know that works. I am using gr-osmosdr. The soapy utility only shows sdrplay. Maybe my soapy is too old?

wofritz@hal:~/sdr/gqrx/build$ SoapySDRUtil --info
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Lib Version: v0.7.0-gd79a09d3
API Version: v0.7.0
ABI Version: v0.7
Install root: /usr/local
Search path:  /usr/local/lib/SoapySDR/modules0.7
Module found: /usr/local/lib/SoapySDR/modules0.7/libsdrPlaySupport.so (0.1.0-2808728)
Available factories... sdrplay

[Roger David Powers]

I thought 'gqrx' used Soapy to discover radios, so I made sure I had the soapy support installed.

Yes, yours seems to be behind, all the current stuff is 0.8 not 0.7.

I have been using the 'pisdr' image for raspberry pi to use this radio.

I have also built the same stuff from the github sources on another rpi as well as an intel linux box and it all worked.

As you know https://github.com/airspy/airspyhf is where to find the library needed by both soapy and gr-osmocom.

My 'soapy' output from the rpi is below.

Note it shows the airspyhf twice because I am also running SoapyRemote so I can use the airspy from other computers via wifi or lan.

pi@rmin:~ $ SoapySDRUtil --info

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

##     Soapy SDR -- the SDR abstraction library     ##

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

Lib Version: v0.8.0-g926c86d9

API Version: v0.8.0

ABI Version: v0.8

Install root: /usr/local

Search path:  /usr/local/lib/SoapySDR/modules0.8

Module found: /usr/local/lib/SoapySDR/modules0.8/libHackRFSupport.so   (0.3.3-7d53087)

Module found: /usr/local/lib/SoapySDR/modules0.8/libLMS7Support.so     (20.10.0-1480bfe)

Module found: /usr/local/lib/SoapySDR/modules0.8/libPlutoSDRSupport.so (0.2.0-93717b3)

Module found: /usr/local/lib/SoapySDR/modules0.8/libairspySupport.so   (0.1.2-10d697b)

Module found: /usr/local/lib/SoapySDR/modules0.8/libairspyhfSupport.so (0.1.1-5488dac)

Module found: /usr/local/lib/SoapySDR/modules0.8/libremoteSupport.so   (0.6.0-c09b2f1)

Module found: /usr/local/lib/SoapySDR/modules0.8/librtlsdrSupport.so   (0.3.1-bec4f05)

Available factories... airspy, airspyhf, hackrf, lime, plutosdr, remote, rtlsdr

Available converters...

 -  CF32 -> [CF32, CS16, CS8, CU16, CU8]

 -  CS16 -> [CF32, CS16, CS8, CU16, CU8]

 -  CS32 -> [CS32]

 -   CS8 -> [CF32, CS16, CS8, CU16, CU8]

 -  CU16 -> [CF32, CS16, CS8]

 -   CU8 -> [CF32, CS16, CS8]

 -   F32 -> [F32, S16, S8, U16, U8]

 -   S16 -> [F32, S16, S8, U16, U8]

 -   S32 -> [S32]

 -    S8 -> [F32, S16, S8, U16, U8]

 -   U16 -> [F32, S16, S8]

 -    U8 -> [F32, S16, S8]

pi@rmin:~ $ SoapySDRUtil --find

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

##     Soapy SDR -- the SDR abstraction library     ##

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

Found device 0

  driver = airspyhf

  label = AirSpy HF+ [3652eb5dacde39f8]

  serial = 3652eb5dacde39f8

Found device 1

  driver = remote

  label = AirSpy HF+ [3652eb5dacde39f8]

  remote = tcp://192.168.1.23:55132

  remote:driver = airspyhf

  serial = 3652eb5dacde39f8

[wolfgan...@gmx.net]

Ok, I built and installed the soapy Airspy module and SoapySDRUtil --find lists the Airspy HF:

wofritz@hal:~/sdr/gqrx/build$ SoapySDRUtil --find

######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Found device 0
 driver = airspyhf

 label = AirSpy HF+ [dd5282aac24c3fcc]
 serial = dd5282aac24c3fcc

Found device 1
 driver = sdrplay
 label = SDRplay Dev0 RSP1A 171202DF93

But in GQRX, I only get the Airspy driver from gr-osmosdr. What is your entry for the Airspy in the device list?

[wolfgan...@gmx.net]

I rebuilt gr-osmosdr with only soapy enabled, and now I see the airspyhf from soapy and it is basically working.

It is still crashing though. The crash is different, I now I get a segmentation fault. It is the same commit that introduces the problem, so I think there really is a bug in it.

I'm now going to investigate what that commit is actually doing and why it is reopening the device if it is already open.

[Roger David Powers]

The gqrx "IO devices" menu device drop down has two offerings for airspyhf+.

First one says "driver=airspyhf,serial=3652eb5dacde39f8,soapy=0" so this must be the path using soapy.

Second one says "airspyhf=0" so this must be the direct gr-osmosdr path.

GQRX console output says:

gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.2.0

built-in source types: file rtl rtl_tcp uhd hackrf rfspace airspy airspyhf soapy redpitaya 

So we see gr-osmosdr has "airspyhf" support built in.

I was able to use both paths without any specific problems.

I see that soapy lets me change the LNA and RF gains whereas gr-osmosdr does not.

I used the start/stop menu a lot and did not see any specific problems.

I changed sample rate and decimation and did not see any specific problems.

I do see my RPi3b struggles when I turn on the CW-U filter or when I narrow the LSB filter to 1.0 kHz or below.

So, are you doing anything to trigger the fault?

Regards,

RDP

[wolfgan...@gmx.net]

I first assumed something in my modified code was causing the problem, but I also get it with an unmodified master fresh from github. I see the problem with the same commit, regardless if I use the native gr-osmosdr driver or the soapy driver, except that the gr-osmosdr driver throws an exception which is propagated to gqrx and gives a nice error box, while the soapy driver crashes with a segfault and core dump.

This is on an Intel I5 system, maybe for some reasons the problem does not show on the Raspi.

That crash is coming if I do anything in the

For now, I have reverted that commit and the crash is gone.