Topics

Discovery and SoapySDR

Philippe Nicolas
 

Hello 

I use Discovery and get great results with rtl_airband on Raspberry PI 3 B+
No problem on same configuration with previous HF+ model.

But since this morning I got this error : SoapySDR device 'driver=airspyhf,device_id=0': readStream failed: OVERFLOW, disabling
Program stops and as you can get, it is very annoying...

Anyone with such configuration ?
Any idea to get rid of this error...?

Thanks

Philippe

prog
 

On Sun, Aug 25, 2019 at 06:12 PM, <philippe.nicolas@...> wrote:
SoapySDR device 'driver=airspyhf,device_id=0': readStream failed: OVERFLOW, disabling
I don't remember writing this error message. Check with SoapySDR devs.

Philippe Nicolas
 

No for sure it is not a libairspyhf error message, I just hope someone has an idea about this error.

I opened an issue on SoapySDR before posting in airspy@groups.io.
I’m waiting for an answer.

Great device by the way !

Le 25 août 2019 à 18:13, prog <info@...> a écrit :

On Sun, Aug 25, 2019 at 06:12 PM, <philippe.nicolas@...> wrote:
SoapySDR device 'driver=airspyhf,device_id=0': readStream failed: OVERFLOW, disabling
I don't remember writing this error message. Check with SoapySDR devs.

Martin Smith
 

The error message is not coming directly from SoapyAirspyHF driver, but it looks like it is being flagged to be generated there.
https://github.com/pothosware/SoapyAirspyHF/search?q=OVERFLOW&unscoped_q=OVERFLOW
would point me to https://github.com/pothosware/SoapyAirspyHF/blob/c424725139c5898caa646bfa94518004f8524d5a/Streaming.cpp#L94
//overflow condition: the caller is not reading fast enough
Which to me would suggest that the RPi is too busy and is unable to process the samples as they are being produced.

Philippe Nicolas
 

Thanks for your help Martin !

I monitor CPU of Raspberry with top while crashing with OVERFLOW message :
rtl_airband is 29% CPU
kworker/2:3-eve 7%
top 1%
And others processes less than 1%
Headers of top :
%Cpu(s): 4.7 us, 1.8 sy, 0.0 ni, 93.3 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem : 948304 total, 731076 free, 56060 used, 161168 buff/cache
KiB Swap: 102396 total, 102396 free, 0 used. 835688 avail Mem

Raspberry is dedicated to rtl_airband.

I try to compile everything again and again with last version and test a lot but nothing…
Raspbian is also up-to-date
Yesterday and days before, I record hours of mp3 without problem.

I also change Discovery with HF+ Dual port and same problem arise.

I think I will loose my last hair with it !
:-(

On 25 Aug 2019, at 21:13, Martin Smith via Groups.Io <martin_z_smith=yahoo.ie@groups.io> wrote:

The error message is not coming directly from SoapyAirspyHF driver, but it looks like it is being flagged to be generated there.
https://github.com/pothosware/SoapyAirspyHF/search?q=OVERFLOW&unscoped_q=OVERFLOW
would point me to https://github.com/pothosware/SoapyAirspyHF/blob/c424725139c5898caa646bfa94518004f8524d5a/Streaming.cpp#L94
//overflow condition: the caller is not reading fast enough
Which to me would suggest that the RPi is too busy and is unable to process the samples as they are being produced.



prog
 

On Sun, Aug 25, 2019 at 10:04 PM, Philippe Nicolas wrote:
Raspberry is dedicated to rtl_airband.
Try one of the lower sample rates (for example 192 ksps).

Philippe Nicolas
 

I also be intrigued by these messages from DMESG :
[ 21.446609] usb 1-1.2: usbfs: interface 0 claimed by usbfs while 'rtl_airband' sets config #1
[ 8865.828041] usb 1-1.2: usbfs: interface 0 claimed by usbfs while 'rtl_airband' sets config #1

Guess what, usb1-1.2 is Discovery…

Are these messages bad errors ?
I have an SSD to boot Raspberry

On 25 Aug 2019, at 21:49, Philippe Nicolas <philippe.nicolas@...> wrote:

Thanks for your help Martin !

I monitor CPU of Raspberry with top while crashing with OVERFLOW message :
rtl_airband is 29% CPU
kworker/2:3-eve 7%
top 1%
And others processes less than 1%
Headers of top :
%Cpu(s): 4.7 us, 1.8 sy, 0.0 ni, 93.3 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem : 948304 total, 731076 free, 56060 used, 161168 buff/cache
KiB Swap: 102396 total, 102396 free, 0 used. 835688 avail Mem

Raspberry is dedicated to rtl_airband.

I try to compile everything again and again with last version and test a lot but nothing…
Raspbian is also up-to-date
Yesterday and days before, I record hours of mp3 without problem.

I also change Discovery with HF+ Dual port and same problem arise.

I think I will loose my last hair with it !
:-(

On 25 Aug 2019, at 21:13, Martin Smith via Groups.Io <martin_z_smith=yahoo.ie@groups.io> wrote:

The error message is not coming directly from SoapyAirspyHF driver, but it looks like it is being flagged to be generated there.
https://github.com/pothosware/SoapyAirspyHF/search?q=OVERFLOW&unscoped_q=OVERFLOW
would point me to https://github.com/pothosware/SoapyAirspyHF/blob/c424725139c5898caa646bfa94518004f8524d5a/Streaming.cpp#L94
//overflow condition: the caller is not reading fast enough
Which to me would suggest that the RPi is too busy and is unable to process the samples as they are being produced.



Martin Smith
 
Edited

That USB SSD could well be the source of your problem: http://doc.xdevs.com/doc/RPi/pi3-block-diagram-rev4.png RPi 3+ hardware and older only have one USB 2.0 High Speed port shared by most large data transfers so if the (USB) SSD is busy, and the (USB) network is busy and the (USB) SDR is trying to stream.

You could try migrating your network traffic from the inbuilt USB NIC to the inbuilt WiFi on the RPi 3 B+ to free up USB capacity/bandwidth and/or "Try one of the lower sample rates (for example 192 ksps)".

Shirley Dulcey KE1L
 

If you're willing to throw a bit of money at the problem you could get
the new Raspberry Pi 4. It has true gigabit Ethernet that does not
share bandwidth with USB, and also has two USB 3.0 ports (which are
limited to about 4 Gbps because the USB controller connects to the CPU
with a single PCIe lane, but they're still more than fast enough).

On Sun, Aug 25, 2019 at 7:34 PM Martin Smith via Groups.Io
<martin_z_smith=yahoo.ie@groups.io> wrote:

[Edited Message Follows]

That USB SSD could well be the source of your problem: http://doc.xdevs.com/doc/RPi/pi3-block-diagram-rev4.png RPi 3+ hardware and older only have one USB 2.0 High Speed port shared by most large data transfers so if the (USB) SSD is busy, and the (USB) network is busy and the (USB) SDR is trying to stream.

You could try migrating your network traffic from the inbuilt USB NIC to the inbuilt WiFi on the RPi 3 B+ to free up USB capacity/bandwidth and/or "Try one of the lower sample rates (for example 192 ksps)".


jdow
 

Talk to the SoapySDR folks. The error message declares it is their problem in the first word.

{^_^}

On 20190825 09:17:47, Philippe Nicolas wrote:
No for sure it is not a libairspyhf error message, I just hope someone has an idea about this error.
I opened an issue on SoapySDR before posting in airspy@groups.io <mailto:airspy@groups.io>.
I’m waiting for an answer.
Great device by the way !

Le 25 août 2019 à 18:13, prog <@prog <mailto:@prog>> a écrit :

On Sun, Aug 25, 2019 at 06:12 PM, <philippe.nicolas@... <mailto:philippe.nicolas@...>> wrote:

SoapySDR device 'driver=airspyhf,device_id=0': readStream failed:
OVERFLOW, disabling

I don't remember writing this error message. Check with SoapySDR devs.

Philippe Nicolas
 

That’s what I did and I follow the questions to rtl_airband dev.

But since yesterday 10:00PM to now 11:30 AM, no more OVERFLOW at all with lower sample rates to 192 ksps…
But with 192 ksps, I don’t recognize my nice Discovery !
I will try with 384 ksps.

but still these DMESG :
[ 8865.828041] usb 1-1.2: usbfs: interface 0 claimed by usbfs while 'rtl_airband' sets config #1
[50778.443481] usb 1-1.2: usbfs: interface 0 claimed by usbfs while 'rtl_airband' sets config #1
[53718.433842] usb 1-1.2: usbfs: interface 0 claimed by usbfs while 'rtl_airband' sets config #1

I’m sure I got this after upgrading all the software on the Raspberry, but which one is the root cause, I don’t know…
As I said no problem before upgrading, with HF+ dual port and Discovery with 768 ksps

Oh my, still testing…!

Le 26 août 2019 à 10:07, jdow <jdow@...> a écrit :

Talk to the SoapySDR folks. The error message declares it is their problem in the first word.

{^_^}

On 20190825 09:17:47, Philippe Nicolas wrote:
No for sure it is not a libairspyhf error message, I just hope someone has an idea about this error.
I opened an issue on SoapySDR before posting in airspy@groups.io <mailto:airspy@groups.io>.
I’m waiting for an answer.
Great device by the way !
Le 25 août 2019 à 18:13, prog <@prog <mailto:@prog>> a écrit :

On Sun, Aug 25, 2019 at 06:12 PM, <philippe.nicolas@... <mailto:philippe.nicolas@...>> wrote:

SoapySDR device 'driver=airspyhf,device_id=0': readStream failed:
OVERFLOW, disabling

I don't remember writing this error message. Check with SoapySDR devs.

prog
 

On Mon, Aug 26, 2019 at 12:07 PM, Philippe Nicolas wrote:
But since yesterday 10:00PM to now 11:30 AM, no more OVERFLOW at all with lower sample rates to 192 ksps…
But with 192 ksps, I don’t recognize my nice Discovery !
I will try with 384 ksps.
The program you are using for demod is not consuming all the samples SoapySDR is sending to it on time. Try fixing that first.

kb3cs
 

all questions of this nature are not answered by "Raspberry".
it is possible Odroid XU4 or Odroid N2 are answers.

  - 1u (base 43) -

prog
 

On Mon, Aug 26, 2019 at 03:08 PM, kb3cs wrote:
all questions of this nature are not answered by "Raspberry".
it is possible Odroid XU4 or Odroid N2 are answers.

  - 1u (base 43) -
But it worked before. There's a high probability the update/upgrade brought more bloat than needed. FattyPi