USB 3.1 with a RTL2832U dongle

[nothotscott]

I have a RTL2832U sdr dongle and everything was working fine, but I was encountering a strange error in logs of some programs on both windows and linux using the librtlsdr driver (an older branch with IR support). I narrowed it down to my USB 3.1 port causing it. My solution was to just move it to a USB 3.0 port and everything is fine now.

My question is (to anyone smarter than me when it comes to this stuff), what makes USB 3.1 throw these kinds of errors (error example is in image below) compared to USB 3.0? According to realtek, the RTL2832U SOC was designed USB 2.0.

USB 3.0 working as intended


USB 3.1 giving errors

rtlsdr_demod_write_reg failed with -9
r82xx_write: i2c wr failed=-9 reg=06 len=1

 

[lwvmobile]

 

[K9RPL]

USB Drivers up to date?

 

[a417]

My question is (to anyone smarter than me when it comes to this stuff), what makes USB 3.1 throw these kinds of errors (error example is in image below) compared to USB 3.0? According to realtek, the RTL2832U SOC was designed USB 2.0.

Long story short. USB hosts (which is the chip inside your computer that does the dirty USB deed) have to fall back to the lowest commonly supported protocol to all the devices in each chain (some of which may be inside the computer, permanently connected in some cases (think: touchpads, etc)) in order so that every device "just works". As soon as you plug in what is now a legacy device (that RTL device that supports USB 2.0) that blazing fast 3.1 port has to go to a stepped down mode to meet a protocol standard that is has evolved past.

Let's also remember that you using an RTL-SDR device is off-label, fringe-use as these devices were not even originally designed to be used like this. Do I think that the USB 3.1 driver/firmware people ever even considering testing a raw I+Q read of a 2.0 USB DVB tuner at maximum thruput? No. Why would they? It's a fringe use case of a device that came to fruition out of a hack. That USB 3.1 device has probably been tested to high hell against a majority of the newer supported devices on the market, and will continue to be improved in that case. ..and probably broadly covers most of the usb 2.0 devices out there...like printers, USB drives, keyboards, media devices,etc.

The fact that we are starting to see these issues pop up with 3.1 and these legacy 2.0 DVB devices doesn't suprise me.

just for kicks, what happens if you roll the sample rate back with rtl_test -s 1024000, do you get the same error?

 

[air-scan]

As far as backwards compatibility, I have a Logitech DualAction gamepad from 2004 that uses the USB 1.1 old tech which worked on xHCI USB 3.1. that's a different animal. It doesn't have a continuous stream of digitized RF spectrum to keep up with. Case in point USB 3.1 is flexible.

 

[a417]

I have a Logitech DualAction gamepad from 2004 that uses the USB 1.1 old tech which worked on xHCI USB 3.1. that's a different animal.

I can bet you that Logitech isn't pushing the limit of 1.1 in terms of throughput tho. If it was pushing 12 mbits/sec that's different.

 

[air-scan]

I can bet you that Logitech isn't pushing the limit of 1.1 in terms of throughput tho. If it was pushing 12 mbits/sec that's different.

It sure does a good job in Need for Speed The Run which isn't the scope of this thread. Guess I am trying to make the case that the backwards compatibility for RTL-SDR looks like it's choking for some software not all software. I think rtl_test (massive byte loss) FMP24(massive CRC errors) is not coping well with the way xHCI 3.1 works. I recommend the op to switch to SDRTrunk (libusb4java) and or Unitrunker (directly hooks with zadig drivers) because those two seem to do well with xHCI 3.1. I have no idea why that is. It's an anomaly I suppose. When 2 don't like to work with xHCI 3.1 and other 2 will. One would think it would work for all. Guess not.
Narrowing the sample rate helps too. FMP24 doesn't let us lower sample rate. It wants to work at 2.4msps only. 1.44msps is better.

 

[a417]

Narrowing the sample rate helps too. FMP24 doesn't let us lower sample rate. It wants to work at 2.4msps only. 1.44msps is better.

That is frustrating, i feel your pain... what's the highest sample rate you get with rtl_test -s that doesn't start barfing errors?

 

[air-scan]

That is frustrating, i feel your pain... what's the highest sample rate you get with rtl_test -s that doesn't start barfing errors?

No I haven't because I don't know all the sample rates it recognizes. SDRTRunk will hiccup a little bit with 2 dongles at 2.4msps until I lower them to 1.60msps then the hiccups go away. Didn't matter what I used in SDR# which just flat out runs lol!

So basically the gist of it I get is the bottleneck in the functions of the action of backwards compatibility. Basically it's saying "USB 2.0 you get this safe thoroughput" not absolute.