Raspberry Pi 400 - gqrx "eats" the RTL-SDR device.

[David Taylor GM8ARV]

First post here so please excuse ....any protocol errors!

Details:

Raspberry Pi 400

Linux raspi-24 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT 2020 armv7l GNU/Linux
gqrx installed through Add/Remove programs today

RTL-SDR added the blacklists commands and rebooted.

Issue:

Immediately after reboot, the RTL device shows in lsusb

pi@raspi-24:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 04d9:0007 Holtek Semiconductor, Inc.
Bus 001 Device 003: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Initial configuration of the RTL-SDR.COM in gqrx appears correct, but when you look at the dialog with the RX/TX display, there is nothing in the drop-down list to select RX (the box is blank), and the device is missing from lsusb

pi@raspi-24:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Likely me doing something wrong, but why would gqrx appear to lose the device?  Can I do anything to fix this?

Thanks,
David GM8ARV

[Richard Bown]

Have a look in syslog, as all the USB devices are missing

/var/log/syslog,   also have a look at dmesg just after it happened,
pipe dmesg to less it will make it easier to read through

dmesg | less

If you can run another terminal while starting gqrx

tail -f /var/log/syslog   is useful to run, it will show realtime what
being logged

Richard

> --
> 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
> <mailto:gqrx+uns...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gqrx/a007a248-43ef-4e90-9e9c-a0b555b91bc0n%40googlegroups.com
> <https://groups.google.com/d/msgid/gqrx/a007a248-43ef-4e90-9e9c-a0b555b91bc0n%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Best wishes /73
Richard Bown

Email : ric...@g8jvm.com

HTTP : https://www.g8jvm.com

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

Ham Call: G8JVM . QRV: HF + 50-432 MHz + Microwave
Maidenhead QRA: IO82SP38, LAT. 52.6620 N LONG. 2.4696 W
VHF: 6mtrs 200W, 4mtrs 150W, 2mtrs 300W, 70cms 200W,
Microwave: 1296MHz 110W, 2320MHz 100W, 3400MHz 15W, 5760MHz 10W & 10368MHz 5W
OS: Linux Mint 20, on a Dell Inspiron 3580 laptop
##############################################################################

[David Taylor]

On 15/12/2020 17:10, Richard Bown wrote:
> Have a look in syslog, as all the USB devices are missing
>
> /var/log/syslog,   also have a look at dmesg just after it happened,
> pipe dmesg to less it will make it easier to read through
>
> dmesg | less
>
> If you can run another terminal while starting gqrx
>
> tail -f /var/log/syslog   is useful to run, it will show realtime what
> being logged
>
> Richard

Richard,

Thanks for that, but it didn't help to resolve the issue with the
RTL-SDR. I tried a FunCube (V1 and v2) and now get partial results:

- what appears like a waterfall display from FM broadcasting works (with
the mode set to WFM).

- no spectrum display appears (the region is black with dB and MHz
scales, and a red vertical marker line).

- setting the frequency at the top of the spectrum display region does
/not/ appear to tune the FCD (either version).

- I get audio but it sounds like the raw input to gqrx, not the
demodulated output!

This is all with the most recent RPiOS, which has pulse-audio, I believe.

Once I get this working I would the like to to get the RTL-SDR going,
and perhaps Airspy and RSP devices.

Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-...@blueyonder.co.uk
Twitter: @gm8arv

[David Taylor]

On 19/12/2020 00:11, Robin Gape wrote:
> David,
>
> 1) something is *radically* wrong here.
> 7) I would strongly recommend a clean install of the *2020-12-02
> version* of Buster to a fresh SD card, updating the system, and
> installing GQRX afresh. If the results are *not* as above, something is
> seriously wrong.

Thanks, Robin. I'm running the new install right now and will report
back once the tests have run. I routinely add NTP and some SNMP
monitoring software so I'll be adding that too.

Many thanks for your detailed and comprehensive response!

73,
David GM8ARV

[David Taylor]

On 19/12/2020 00:11, Robin Gape wrote:
> David,
>
> 1) something is *radically* wrong here.

OK, I burned a new microSD card with the current OS and updated it, and
added gqrx via the Add/Remove function. Here's an extract, and I am
puzzled by the references to the I2C functions. Perhaps they are
internal to the RTL device?

r82xx_write: i2c wr failed=-1 reg=1a len=7
r82xx_write: i2c wr failed=-1 reg=0c len=1

I feel I should get the rtl_test working before attacking anything else!

Tried several devices, similar results. Suspect the RTL-SDR library,
but on a fresh install?

pi@raspberrypi:~ $ lsusb

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Bus 001 Device 005: ID 04d9:0007 Holtek Semiconductor, Inc.
Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 003: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse

Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

pi@raspberrypi:~ $ rtl_test
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000013

Using device 0: Generic RTL2832U OEM
Detached kernel driver
Found Rafael Micro R820T tuner
r82xx_write: i2c wr failed=-1 reg=1a len=7
r82xx_write: i2c wr failed=-1 reg=0c len=1
r82xx_init: failed=-1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7
16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1
43.4 43.9 44.5 48.0 49.6
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
r82xx_write: i2c wr failed=-1 reg=0a len=1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
WARNING: Failed to set sample rate.
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_write_reg failed with -1
rtlsdr_write_reg failed with -1

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode...
Allocating 15 zero-copy buffers
cb transfer status: 1, canceling...

Library error -5, exiting...
Reattaching kernel driver failed!

pi@raspberrypi:~ $ lsusb

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Bus 001 Device 005: ID 04d9:0007 Holtek Semiconductor, Inc.
Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 003: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse

Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

pi@raspberrypi:~ $

[Robin Gape]

David,

1) we're making progress here

2) having refreshed the memory, the i2C messages refer to the internal operation of the RTL-SDR dongle. They're not usually seen, unless there is a problem.

3) the -1 error seems to be associated with a lack of power delivered to the USB port of the dongle. Have you tried:

a) putting the dongle in a different USB port?

b) both USB2 and USB3 ports?

c) a powered USB hub (only needs to be USB2)?

d) using an alternative USB extension cable (presumably the dongle is not plugged directly in to the USB port)?

e) using an alternative power source for the Pi-400 (shouldn't be necessary)?

f) measuring the voltage at the dongle with a USB voltage monitor widget? (If one has one, can it ever be found again!)

4) One is presuming that the dongles work in other hosts, Linux, Windows, or otherwise.

5) On the test machine, an RTL-SDR dongle works fine in either a USB2 or USB3 port.

6) Is it correct to assume that there is no Raspberry Pi that might be substituted for the 400?

7) One suspects that the failure to re-attach is associated with some problem within libusb, possibly on the defensive programming front.

73, HTH, Stay Safe,

Robin, G8DQX

[David Taylor]

On 20/12/2020 00:52, 'Robin Gape' via Gqrx SDR wrote:
> David,
>
> 1) we're making progress here
>
> 2) having refreshed the memory, the i2C messages refer to the internal
> operation of the RTL-SDR dongle. They're not usually seen, unless there
> is a problem.
>
> 3) the -1 error seems to be associated with a lack of power delivered to
> the USB port of the dongle. Have you tried:
>
> a) putting the dongle in a different USB port?
>
> b) both USB2 and USB3 ports?
>

> c) a *powered* USB hub (only needs to be USB2)?

>
> d) using an alternative USB extension cable (presumably the dongle
> is not plugged directly in to the USB port)?
>
> e) using an alternative power source for the Pi-400 (shouldn't be
> necessary)?
>
> f) measuring the voltage at the dongle with a USB voltage monitor
> widget? (If one has one, can it ever be found again!)
>
> 4) One is presuming that the dongles work in other hosts, Linux,
> Windows, or otherwise.
>
> 5) On the test machine, an RTL-SDR dongle works fine in either a USB2 or
> USB3 port.
>
> 6) Is it correct to assume that there is no Raspberry Pi that might be
> substituted for the 400?
>
> 7) One suspects that the failure to re-attach is associated with some
> problem within libusb, possibly on the defensive programming front.
>
> 73, HTH, Stay Safe,
>
> Robin, G8DQX

Thanks for that Robin. I didn't seem to make a lot of progress simply
installing a fresh OS.

2. Agreed. there was some sort of problem.

3. At times the whole USB system appears to hang, even with Luigi's
images (below). Perhaps when switching back from Airspy to RTL-SDR?
Nothing else seemed to make a difference (tried cable, USB ports, but
not a powered hub). Still sounds like a driver issue to me. Not tried
(e). I keep my (f) on the desk in front of the monitor!

4. Yes, usually SDR# is my standard testbed, sometimes HDSDR or SDRAngel.

5. Same here with the Luigi image.

6. I do have the odd RPi spare if needed.

I ended up trying this ready-to-run image:

https://github.com/luigifcruz/pisdr-image

although I would have preferred to build from scratch. With the Airspy
Mini there seem to be spurs at +/- 900 kHz.

Bluetooth audio is still a problem - pairs OK but no way to set the
headphones as the output device.

In general the performance of the RPi 400 strikes me as not better than
a five year old Intel tablet (Linx 1010B), probably not really up to
some of the tasks I had hoped it might be. I hope I'm wrong, but I did
try the volk_profile optimiser without much difference. I suspect that
if everyone (through software) had full access to the signal processing
functions on the chip it might help rather more. Luigi's image has some
limitations right now (no RSPxxx or Funcube support, no CubicSDR) and
SDRAngel takes minutes (!) to load.

Again, thanks for your comments and sharing your experience.