Raspberry pi 3 b+ & Rtl 2832u sdr

Hi i have a question for some bug or my Pi is have a some problem.
When put usb device all is ok, but when try to use rtl_test is a worst time.

root@OpenWrt:~# rtl_test
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
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
[R82XX] PLL not locked!
Sampling at 2048000 S/s.

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
lost at least 11139219 bytes
lost at least 11054612 bytes
lost at least 11001626 bytes
lost at least 11192666 bytes
lost at least 10956216 bytes
lost at least 10987050 bytes
lost at least 10852059 bytes
lost at least 10858963 bytes
lost at least 10743562 bytes
lost at least 10760693 bytes
lost at least 10824795 bytes
lost at least 10878276 bytes
lost at least 10729908 bytes
lost at least 10531768 bytes
lost at least 10574356 bytes
lost at least 11139220 bytes
lost at least 11054612 bytes
lost at least 11001626 bytes
lost at least 11192666 bytes
lost at least 10956216 bytes
lost at least 10987050 bytes
lost at least 10852059 bytes
lost at least 10858963 bytes
lost at least 10743562 bytes
lost at least 10760693 bytes
lost at least 10824795 bytes
lost at least 10878276 bytes
lost at least 10729908 bytes
lost at least 10531768 bytes
lost at least 10574356 bytes
lost at least 11139220 bytes
lost at least 11054612 bytes
lost at least 11001626 bytes
lost at least 11192666 bytes
lost at least 10956216 bytes
lost at least 10987050 bytes
lost at least 10852059 bytes
lost at least 10858963 bytes
lost at least 10743562 bytes
lost at least 10760693 bytes
lost at least 10824795 bytes
lost at least 10878276 bytes
lost at least 10729908 bytes
lost at least 10531768 bytes
lost at least 10574356 bytes
lost at least 11139220 bytes
lost at least 11054612 bytes
lost at least 11001626 bytes
lost at least 11192666 bytes
lost at least 10956216 bytes
lost at least 10987050 bytes
lost at least 10852059 bytes
lost at least 10858963 bytes
lost at least 10743562 bytes
lost at least 10760693 bytes
lost at least 10824795 bytes
lost at least 10878276 bytes
lost at least 10729908 bytes
lost at least 10531768 bytes
lost at least 10574356 bytes
lost at least 11139220 bytes
lost at least 11054612 bytes
lost at least 11001626 bytes
lost at least 11192666 bytes
lost at least 10956216 bytes
lost at least 10987050 bytes
lost at least 10852059 bytes
lost at least 10858963 bytes
lost at least 10743562 bytes
lost at least 10760693 bytes
lost at least 10824795 bytes
lost at least 10878276 bytes
lost at least 10729908 bytes
lost at least 10531768 bytes
lost at least 10574356 bytes
lost at least 11139220 bytes
lost at least 11054612 bytes
lost at least 11001626 bytes
lost at least 11192666 bytes
lost at least 10956216 bytes
lost at least 10987050 bytes
lost at least 10852059 bytes
lost at least 10858963 bytes
lost at least 10743562 bytes
lost at least 10760693 bytes
lost at least 10824795 bytes
lost at least 10878276 bytes
lost at least 10729908 bytes
lost at least 10531768 bytes
lost at least 10574356 bytes
lost at least 11139220 bytes
lost at least 11054612 bytes
lost at least 11001626 bytes
lost at least 11192666 bytes
lost at least 10956216 bytes
lost at least 10987050 bytes
lost at least 10852059 bytes
lost at least 10858963 bytes
lost at least 10743562 bytes
lost at least 10760693 bytes
lost at least 10824795 bytes
lost at least 10878276 bytes
lost at least 10729908 bytes
lost at least 10531768 bytes
lost at least 10574356 bytes
lost at least 11139220 bytes
lost at least 11054612 bytes
lost at least 11001626 bytes
lost at least 11192666 bytes
lost at least 10956216 bytes
lost at least 10987050 bytes
lost at least 10852059 bytes
lost at least 10858963 bytes
lost at least 10743562 bytes
lost at least 10760693 bytes
lost at least 10824795 bytes
lost at least 10878276 bytes
lost at least 10729908 bytes
lost at least 10531768 bytes
lost at least 10574356 bytes
lost at least 11139220 bytes
lost at least 11054612 bytes
lost at least 11001626 bytes
lost at least 11192666 bytes
lost at least 10956216 bytes
lost at least 10987050 bytes
lost at least 10852059 bytes
lost at least 10858963 bytes
lost at least 10743562 bytes
lost at least 10760693 bytes
lost at least 10824795 bytes
lost at least 10878276 bytes
lost at least 10729908 bytes
lost at least 10531768 bytes
lost at least 10574356 bytes
lost at least 11139220 bytes
lost at least 11054612 bytes
lost at least 11001626 bytes
lost at least 11192666 bytes
lost at least 10956216 bytes
^CSignal caught, exiting!

User cancel, exiting...
Samples per million lost (minimum): 41501624

I try with 18.06.1 and 18.06.2, now is latest snapshot but all is same.
Some body have a idea where is a problem. I test rtl-sdr on other router and works perfect.

There are a few of things to note about running an RTL SDR device on a RasPi, particularly one being used as a router:

  • they're quite power hungry; make sure you have a good quality power supply for the Pi
  • rtlsdr is pretty CPU intensive, shouldn't be a problem for a Pi 3B+, though
  • the RTL stick is on the USB bus, as is the NIC on a Pi. rtlsdr is passing a lot of data over the bus and this could interact badly with any network traffic trying to do the same
  • USB is interrupt driven on the Pi, so that's going to be putting additional load on the CPU

Whatever it is you're hoping to achieve, I wouldn't try running rtlsdr on this setup.

1 Like

RTLSDR is running perfectly on a RPi 3B with Raspbian, so it is no general problem.

Oh, absolutely! I use a realtek tv tuner for grabbing aircraft transmissions with dump1090 on a RasPi and it works great. But that's with very little network throughput and little to no other tasks being performed by the CPU. My point was that trying to run rtlsdr on a Pi that's also operating as a router with all the OpenWrt subsystems running and passing packets between interfaces may not be such a good idea, especially as networking and the tv tuner are both on USB, which is a shared medium and interrupt driven.

3 Likes

Ok i test before with other distributions and all is fine. And now i try with a usb hub with power sorce but is the same problem.

This is very CPU intensive. I had issues on various routers with various USB chips.

Of all the devices I have, I have the best experience with rtl_dsr on Power PC (apm821xx) routers.

You may have to lower rates when configuring /etc/config/rtl_tcp

1 Like