Topics

Raspberry Pi 4 & Airspy Discovery


DD4WH
 

Hi everybody!
I am using an RPi4 & the AirSpy HF+ Discovery.

My RPi4 uses the pisdr image based an Raspbian by https://pisdr.luigi.ltd/
It contains a preinstalled image with
* SDR Angel
* soapySDR
* gqrx

However, I cannot use the AirSpy with SDRangel, because there is no audio or spectrum/waterfall.
The AirSpy is found by typing the following in the Terminal:

SoapySDRUtil --probe="driver=airspyhf"
The subsequent output shows that my hardware is recognized by SoapySDR.

I can also use the AirSpy Discovery in gqrx and receive is fully functional.

In SDRangel the sampling device is found and I can choose it, but when I start the sampling device (I have setup a demodulator first) there is no audio and no spectrum/waterfall.

Is this the same issue as this [https://github.com/f4exb/sdrangel/issues/600] ?
and is there a chance that it can be solved sometime?

All the best regards,

Frank DD4WH


Edouard Griffiths
 

Hello,

to sort out if this is specific to AirspyHF and possibly related to https://github.com/f4exb/sdrangel/issues/600 you have to try with another hardware (ex: RTL=SDR). It is more likely to be related to:
  • audio -> pulseaudio setup
  • graphics -> OpenGL setup
Generally I do not recommend using the RPi with SDRangel GUI variant. It works well with the server variant though and I use it myself extensively in this setup.

Brgds,
Edouard.


DD4WH
 

Salut Edouard,

took me a while to find my RTL stick, its too small ;-).

I tested SDR Angel with the RTL-SDR stick and it works with audio and spectrum/waterfall [I tried the WFM demodulator and also the Broadcast FM Demod].

I was really impressed by the performance: demodulating WFM stereo in finest audio quality and producing spectrum and waterfall works really well (RPi4) !

Also the Soapy-SDRUtil finds the driver files for RTL-SDR and everything seems OK.

As I am not really experienced in using Linux or RPi, can I now exclude that the missing AirSpy HF+ Discovery support has something to do with my pulseaudio / OpenGL setup?

Best 73s,

Frank DD4WH


Edouard Griffiths
 

Hello Frank,

what is the kernel version on this distribution (uname -r gives you the answer)?

Brgds,
Edouard.


DD4WH
 

hi Edouard,

it says:
5.4.51-v7l+

I took the latest version of the pisdr image available on the web to install.

My knowledge on RPi/Linux is quite limited, I must admit.

If there is anything else I can do or test in order for you to get more information on this, please let me know!

All the best regards from sunny Central Europe :-)

Frank DD4WH


Edouard Griffiths
 
Edited

My kernel on the Lubuntu 20.04 for x86_64 distro is "5.4.0-48-generic" (so in the 5.4 series) and I had the issue only after upgrade from 18.04 where the kernel was in the 4.15 series. What I could see while debugging the code is that the callback actually is never called back so it might have something to do with how USB is handled in the newer kernels for some hardware (most of my USB devices still work).

Brgds, Edouard.


Bob Stricklin
 

Frank,

First of all, we are fortunate to have such a fine program as SDRAngel available to us and to have Edouard make comments about issues on this reflector.

A challenge with working on software development with Linux is the base systems, kernels and drivers keep evolving. So, when a software package is developed and considered stable this will only last until someone makes a change. I have fought this issue working with RPi platforms and the Jetson boards trying to build and use other SDR packages.

Edouard’s package is wonderful, and I have it working with Ubuntu 18 using the Pluto and a few other devices on an Intel NUC.

If you are experienced in developing software you may be able to solve your problem on your build by changing a driver like the USB driver or one of the audio drivers. There is discussion about these issues on the web and here is a link to one on Ubuntu that may be useful;


The other thing you could do is find the particular kernel build that Edouard used and put this one on a different SD card to test your hardware. If this fixes the issues, then stick with it. The issue could also be related to the chips used on your board.

This is a problem though that we will face as hardware and software continues to evolve.  We all want to have the best of each. Hopefully we can help Edouard and not drive him crazy.

73,

Bob N5BRG




On Sep 30, 2020, at 9:37 AM, Edouard Griffiths <f4exb06@...> wrote:

My kernel on the Lubuntu 20.04 for x86_64 distro is "5.4.0-48-generic" (so in the 5.4 series) and I had the issue only after upgrade from 18.04 where the kernel was in the 4.15 series. What I could see while debugging the code is that the callback actually never calls back so it might have something to do with how USB is handled in the newer kernels for some hardware (most of my USB devices still work).

Brgds, Edouard.


DD4WH
 

Bob, Edouard,

thank you very much for your messages and your help! It is of course not my intention to drive someone crazy! :-)

I acknowledge the hard work you put into the software and your answers to my questions!

My knowledge in Linux is poor, I have only dealt with C programming up to now, so many things appear strange to me on Linux devices like the RPi.

However, when reading carefully through your answers, one question still remains in my head:

* the kernel I have on my RPi4 [5.4.51-v7l+] is fully capable of communicating via USB with my particular SDR hardware (AirSpy HF+ Discovery). So, my conclusion is: the kernel itself is NOT the problem, because gqrx plus my kernel can communicate with the AirSpy discovery and also SoapySDR can communicate with the AirSpy Discovery on my specific kernel.
* So, what I do not understand is how then SDRAngel cannot communicate with that equal hardware and why the specific kernel I use can be the cause of this? From the observations above I assume that SDRAngel uses a different way of addressing the USB devices than the mentioned SoapySDR and gqrx?

Sorry for my obvious poor knowledge which causes me to ask this kind of questions of which the answer could be very clear to more experienced users.

Would be nice to have an idea about this, even if it is not possible to get SDRAngel to work with the AirSpy Discovery (on my specific kernel).

Have a nice and hopefully sunny day,

Frank DD4WH


Bob Stricklin
 

Hi Frank,

Edouard mentioned he looked at a similar issue and found a call was being made which did not return….

Have you used the GDB debugger before? Can you set up the debugger on your RPi and run the code with the debugger?  It's not too difficult to do this. Then you can step through the SDRAngel code and watch as it moves through the different functions. Ideally you will find the location the AirSpy is being called and may see the same issue of a function not returning after it is called. Then you can look at the structure of that function call and try to find why it does not continue to work.

SoapySDR does the -probe by checking to see if the library is there and making a simple call to device. So not a very deep check to see things are working.

You indicate the device works with gqrx. Can you look at the code on gqrx (Open Source) and compare the methods used to communicate with the AirSpy. By comparing the code in this area you may find the reason your combination of hardware and software is not working on SDRAngel.

Which version of AirSpy do you have?

You may need to build the code for the packages involved so you can include the debug flag (-g). This will get you the hooks needed in the executable SDRAngel to step through the code during execution.

Hope this helps you.

Bob  N5BRG

On Oct 1, 2020, at 4:03 AM, DD4WH <dd4wh.swl@...> wrote:

Bob, Edouard,

thank you very much for your messages and your help! It is of course not my intention to drive someone crazy! :-)

I acknowledge the hard work you put into the software and your answers to my questions!

My knowledge in Linux is poor, I have only dealt with C programming up to now, so many things appear strange to me on Linux devices like the RPi.

However, when reading carefully through your answers, one question still remains in my head:

* the kernel I have on my RPi4 [5.4.51-v7l+] is fully capable of communicating via USB with my particular SDR hardware (AirSpy HF+ Discovery). So, my conclusion is: the kernel itself is NOT the problem, because gqrx plus my kernel can communicate with the AirSpy discovery and also SoapySDR can communicate with the AirSpy Discovery on my specific kernel.
* So, what I do not understand is how then SDRAngel cannot communicate with that equal hardware and why the specific kernel I use can be the cause of this? From the observations above I assume that SDRAngel uses a different way of addressing the USB devices than the mentioned SoapySDR and gqrx?

Sorry for my obvious poor knowledge which causes me to ask this kind of questions of which the answer could be very clear to more experienced users.

Would be nice to have an idea about this, even if it is not possible to get SDRAngel to work with the AirSpy Discovery (on my specific kernel).

Have a nice and hopefully sunny day,

Frank DD4WH


DD4WH
 

Hi Bob,

thanks a lot for your detailed description of the debugging process necessary to discover the cause of the bug!

Sorry, but at the moment I do not feel prepared to go for that challenge and even if I found the bug, I would certainly not be able to find a fix in a programming language that I do not speak :-).

In this context it would be interesting if anybody has RPi4 and the AirSpy HF+ Discovery in working condition with SDRAngel and what the difference would be in comparison to my setup.

Thanks again for your time & efforts!

73 de Frank DD4WH