[SOLVED] Archer C2600 & RTL SDR - Issues running `rtl_test` or `rtl_tcp`

I've been trying to use the rtl-sdr package (in particular rtl_tcp) to stream RF captures across my network using a Nooelec NESDR - which is a full-speed USB-2 bus-powered device.

I'm seeing what I think are USB I/O issues

I'm running 19.07.5 on an Archer C2600

I'm using openwebrx to visualise the capture on another machine, and it shows what I initially thought to be a huge amount of noise:

But this is actually a total "white-out" - I can blast a signal in this particular band at it and it doesn't register.

rtl_test is also showing significant drops, even at the lowest sample rate, which rules out a bunch of things:

root@rtl:~# rtl_test -s 225001
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 225001 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 30997990 bytes
lost at least 19639627 bytes
lost at least 31768154 bytes
lost at least 17121486 bytes
...

Things I've learned so far:

  • The logs don't seem to contain anything pertaining to the tests
  • The RTL SDR device is just fine - works on other machines
  • It's not RFI related. I use the RTL SDR device right next to this router and it works fine
  • It's not USB cable related: same cables are fine when this RTL SDR is used on other machines
  • It's probably not USB power related: other bus-powered devices in the same USB 3 port work just fine, and I've tried putting a powered USB hub in-between (which also works fine when used on other machines)
  • It doesn't seem to be a CPU or memory constraint issue - atop shows almost completely idle cores and plenty of spare RAM
  • Results on my WDR4900 are much better (some buffering issues, but rtl_test is happy). This is a lower spec device, and only has USB-2 ports - which could be a clue

I'm hoping that there are others out there who might be able to provide some guidance as to what to try next to help isolate the root cause.

Any thoughts and ideas most welcome.

FWIW, I've cross posted to the RTL-SDR sub-reddit to reach the RTL-SDR community:

I forgot where but I heard that there's been issues with ipq806x devices and rtl-sdr. Give me a bit so I can test on my router (ipq8065) and I'll report back

Edit: everything seems fine with my router (keep in mind that it's on a slightly old snapshot build that I built myself since it isn't officially supported yet). In gqrx the spectrum is a bit blocky but the actual audio sounds perfectly fine and I don't get any samples lost with the rtl_test command you had. My router is the rt4230w (you can look at my profile to find the thread for it) and I'm using the rtl-sdr blog v3 radio.

1 Like

Thanks - that's useful to know!

I've installed usbmon and captured some usb traffic to try to understand more about what's going on:

opkg install usbmon

And captured some traffic whilst rtl_test is complaining about losing bytes, and for each rtl_test error, there is a corresponding line in the usbmon output. It looks like there's some normal looking handshaking, and then a bunch of errors:

$ cat /sys/kernel/debug/usb/usbmon/3u
...
dac9b680 689037251 C Co:3:002:0 0 2 >
dac9b680 689037501 S Co:3:002:0 s 40 00 2148 0110 0002 2 = 0000
dac9b680 689039071 C Co:3:002:0 0 2 >
dac9b680 689042751 S Bi:3:002:1 -115 262144 <
dc0f9d80 689042898 S Bi:3:002:1 -115 262144 <
dc0f9a00 689042977 S Bi:3:002:1 -115 262144 <
dc0f9e80 689043048 S Bi:3:002:1 -115 262144 <
dc0f9900 689043122 S Bi:3:002:1 -115 262144 <
dc0f9b00 689043191 S Bi:3:002:1 -115 262144 <
dc0f9f80 689043260 S Bi:3:002:1 -115 262144 <
dc0f9500 689043329 S Bi:3:002:1 -115 262144 <
dc0f9200 689043400 S Bi:3:002:1 -115 262144 <
dc0f9800 689043475 S Bi:3:002:1 -115 262144 <
dc0f9d00 689043547 S Bi:3:002:1 -115 262144 <
dc0f9080 689043621 S Bi:3:002:1 -115 262144 <
dc0f9300 689043691 S Bi:3:002:1 -115 262144 <
dc0f9480 689043761 S Bi:3:002:1 -115 262144 <
dc0f9100 689043831 S Bi:3:002:1 -115 262144 <
dac9b680 689106146 C Bi:3:002:1 0 262144 = 32333435 36373839 3a3b3c3d 3e3f4041 42434445 46474849 4a4b4c4d 4e4f5051
dc0f9000 689108128 S Bi:3:002:1 -115 262144 <
dc0f9d80 689170119 C Bi:3:002:1 0 262144 = 32333435 36373839 3a3b3c3d 3e3f4041 42434445 46474849 4a4b4c4d 4e4f5051
dc0f9d80 689172321 S Bi:3:002:1 -115 262144 <
dc0f9a00 689234101 C Bi:3:002:1 0 262144 = 32333435 36373839 3a3b3c3d 3e3f4041 42434445 46474849 4a4b4c4d 4e4f5051
dc0f9a00 689236113 S Bi:3:002:1 -115 262144 <

...

note: I've snipped lots of stuff before and after - which may or not be relevant.

I'm quite out of my depth, but according to format format, it looks like some errors reading - again though, totally out of my depth!

I put a 12ft of usb extension cords and wrapped it around the router while doing a speedtest and rtl_tcp at the same time and everything was fine interestingly enough.

1 Like

So I've been testing the NSS builds made by ACwifidude, and I thought I'd try the RTL SDR on the same build, and the problem has totally gone away!

So I guess it's either the kernel update (4.x -> 5.x), or the minor update to the rtl-sdr package (6.0.1 -> 6.0.2).

I suspect it's the kernel. If I find out, I'll post back. For now though, I'll mark this as solved.

2 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.