RTL Test Losing bytes on USB3.1

[air-scan]

I have ran rtl_test to find the issue with failed CRC's in DSD+FL. I don't know if it's the bottleneck of the RTL-SDR being a USB 2.0 device on a USB3.1 integrated circuit. There is no USB 2.0 connections. I know USB3.1 is backwards compatible. This much loss in bytes is concerning.

Found 1 device(s):
0: NooElec, NESDR Nano 3, SN: 7197503488

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T/2 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
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 (non-zero-copy) user-space buffers
lost at least 3220 bytes in buffer 0
lost at least 2888 bytes in buffer 2
lost at least 3688 bytes in buffer 3
lost at least 3480 bytes in buffer 4
lost at least 3400 bytes in buffer 5
lost at least 3584 bytes in buffer 6
lost at least 3500 bytes in buffer 7
lost at least 3648 bytes in buffer 8
lost at least 3296 bytes in buffer 9
...
.........
Signal caught, exiting!
lost at least 4396 bytes in buffer 339

User cancel after 340 buffers, exiting...
Samples per million lost (minimum): 24

C:\Users\ddejr\Downloads\librtlsdr-win32_2020-08-26>cd\

C:\>cd C:\Users\ddejr\Downloads\RelWithDebInfo\rtl-sdr-release\x64

C:\Users\ddejr\Downloads\RelWithDebInfo\rtl-sdr-release\x64>rtl_test
Found 1 device(s):
0: NooElec, NESDR Nano 3, SN: 7197503488

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
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...
lost at least 44 bytes
lost at least 5440 bytes
lost at least 3744 bytes
lost at least 3396 bytes
lost at least 3552 bytes
lost at least 3292 bytes
lost at least 5016 bytes
lost at least 2440 bytes
lost at least 3212 bytes
lost at least 3432 bytes
lost at least 3348 bytes
lost at least 3624 bytes
lost at least 2848 bytes
lost at least 1656 bytes
Signal caught, exiting!
lost at least 1672 bytes

wmic returns:

C:\windows\system32>wmic path CIM_LogicalDevice where "Description like 'USB%'" get /value


Availability=
Caption=Intel(R) USB 3.10 eXtensible Host Controller - 1.10 (Microsoft)
ConfigManagerErrorCode=0
ConfigManagerUserConfig=FALSE
CreationClassName=Win32_USBController
Description=USB xHCI Compliant Host Controller
DeviceID=PCI\VEN_8086&DEV_34ED&SUBSYS_86AB103C&REV_30\3&11583659&2&A0
ErrorCleared=
ErrorDescription=
InstallDate=
LastErrorCode=
Manufacturer=Generic USB xHCI Host Controller
MaxNumberControlled=
Name=Intel(R) USB 3.10 eXtensible Host Controller - 1.10 (Microsoft)
PNPDeviceID=PCI\VEN_8086&DEV_34ED&SUBSYS_86AB103C&REV_30\3&11583659&2&A0
PowerManagementCapabilities=
PowerManagementSupported=
ProtocolSupported=16
Status=OK
StatusInfo=
SystemCreationClassName=Win32_ComputerSystem
SystemName=LAPTOP-M9R2RSHR
TimeOfLastReset=


Availability=
Caption=USB Composite Device
ClassCode=
ConfigManagerErrorCode=0
ConfigManagerUserConfig=FALSE
CreationClassName=Win32_USBHub
CurrentAlternateSettings=
CurrentConfigValue=
Description=USB Composite Device
DeviceID=USB\VID_05C8&PID_03BC\5&2A3BC1ED&0&3
ErrorCleared=
ErrorDescription=
GangSwitched=
InstallDate=
LastErrorCode=
Name=USB Composite Device
NumberOfConfigs=
NumberOfPorts=
PNPDeviceID=USB\VID_05C8&PID_03BC\5&2A3BC1ED&0&3
PowerManagementCapabilities=
PowerManagementSupported=
ProtocolCode=
Status=OK
StatusInfo=
SubclassCode=
SystemCreationClassName=Win32_ComputerSystem
SystemName=LAPTOP-M9R2RSHR
USBVersion=


Availability=
Caption=USB Root Hub (USB 3.0)
ClassCode=
ConfigManagerErrorCode=0
ConfigManagerUserConfig=FALSE
CreationClassName=Win32_USBHub
CurrentAlternateSettings=
CurrentConfigValue=
Description=USB Root Hub (USB 3.0)
DeviceID=USB\ROOT_HUB30\4&2217AD68&0&0
ErrorCleared=
ErrorDescription=
GangSwitched=
InstallDate=
LastErrorCode=
Name=USB Root Hub (USB 3.0)
NumberOfConfigs=
NumberOfPorts=
PNPDeviceID=USB\ROOT_HUB30\4&2217AD68&0&0
PowerManagementCapabilities=
PowerManagementSupported=
ProtocolCode=
Status=OK
StatusInfo=
SubclassCode=
SystemCreationClassName=Win32_ComputerSystem
SystemName=LAPTOP-M9R2RSHR
USBVersion=


Availability=
Caption=USB Composite Device
ClassGuid={36fc9e60-c465-11cf-8056-444553540000}
CompatibleID={"USB\DevClass_00&SubClass_00&Prot_00","USB\DevClass_00&SubClass_00","USB\DevClass_00","USB\COMPOSITE"}
ConfigManagerErrorCode=0
ConfigManagerUserConfig=FALSE
CreationClassName=Win32_PnPEntity
Description=USB Composite Device
DeviceID=USB\VID_05C8&PID_03BC\5&2A3BC1ED&0&3
ErrorCleared=
ErrorDescription=
HardwareID={"USB\VID_05C8&PID_03BC&REV_0003","USB\VID_05C8&PID_03BC"}
InstallDate=
LastErrorCode=
Manufacturer=(Standard USB Host Controller)
Name=USB Composite Device
PNPClass=USB
PNPDeviceID=USB\VID_05C8&PID_03BC\5&2A3BC1ED&0&3
PowerManagementCapabilities=
PowerManagementSupported=
Present=TRUE
Service=usbccgp
Status=OK
StatusInfo=
SystemCreationClassName=Win32_ComputerSystem
SystemName=LAPTOP-M9R2RSHR


Availability=
Caption=Intel(R) USB 3.10 eXtensible Host Controller - 1.10 (Microsoft)
ClassGuid={36fc9e60-c465-11cf-8056-444553540000}
CompatibleID={"PCI\VEN_8086&DEV_34ED&REV_30","PCI\VEN_8086&DEV_34ED","PCI\VEN_8086&CC_0C0330","PCI\VEN_8086&CC_0C03","PCI\VEN_8086","PCI\CC_0C0330","PCI\CC_0C03"}
ConfigManagerErrorCode=0
ConfigManagerUserConfig=FALSE
CreationClassName=Win32_PnPEntity
Description=USB xHCI Compliant Host Controller
DeviceID=PCI\VEN_8086&DEV_34ED&SUBSYS_86AB103C&REV_30\3&11583659&2&A0
ErrorCleared=
ErrorDescription=
HardwareID={"PCI\VEN_8086&DEV_34ED&SUBSYS_86AB103C&REV_30","PCI\VEN_8086&DEV_34ED&SUBSYS_86AB103C","PCI\VEN_8086&DEV_34ED&CC_0C0330","PCI\VEN_8086&DEV_34ED&CC_0C03"}
InstallDate=
LastErrorCode=
Manufacturer=Generic USB xHCI Host Controller
Name=Intel(R) USB 3.10 eXtensible Host Controller - 1.10 (Microsoft)
PNPClass=USB
PNPDeviceID=PCI\VEN_8086&DEV_34ED&SUBSYS_86AB103C&REV_30\3&11583659&2&A0
PowerManagementCapabilities=
PowerManagementSupported=
Present=TRUE
Service=USBXHCI
Status=OK
StatusInfo=
SystemCreationClassName=Win32_ComputerSystem
SystemName=LAPTOP-M9R2RSHR


Availability=
Caption=USB Root Hub (USB 3.0)
ClassGuid={36fc9e60-c465-11cf-8056-444553540000}
CompatibleID=
ConfigManagerErrorCode=0
ConfigManagerUserConfig=FALSE
CreationClassName=Win32_PnPEntity
Description=USB Root Hub (USB 3.0)
DeviceID=USB\ROOT_HUB30\4&2217AD68&0&0
ErrorCleared=
ErrorDescription=
HardwareID={"USB\ROOT_HUB30&VID8086&PID34ED&REV0030","USB\ROOT_HUB30&VID8086&PID34ED","USB\ROOT_HUB30"}
InstallDate=
LastErrorCode=
Manufacturer=(Standard USB HUBs)
Name=USB Root Hub (USB 3.0)
PNPClass=USB
PNPDeviceID=USB\ROOT_HUB30\4&2217AD68&0&0
PowerManagementCapabilities=
PowerManagementSupported=
Present=TRUE
Service=USBHUB3
Status=OK
StatusInfo=
SystemCreationClassName=Win32_ComputerSystem
SystemName=LAPTOP-M9R2RSHR

Same results testing my other dongle. I suggest that on some USB3.1 hardware backwards compatibility to USB2.0 is limited or maybe restricted when using RTL-SDR's on USB3.1. It does work. I can run SDR#, SDRTrunk, RTL1090. I am also not even sure if rtl_test is able to read correctly from a USB3.1 controller very well.

Any thoughts?

 

[lwvmobile]

Could be to do with it being a Linux program being compiled to run in Windows, if I had to take a guess. Here is a side-by-side of the rtl_test running in a virtual machine and natively. The virtual machine is showing lost bytes, but my Windows 10 Virtual Machine has never had any problems with using Unitrunker or DSDplus or anything like that either. In this case, I'm not sure that rtl_test is going to be the end all test to determine why you are coming up with CRC failure, could be a weak signal, noise, or encryption perhaps.

I can also say I've tested this out on my weak ultrabook with Linux and a Celeron J processor in it and even with how slow that is, when I plug my dongle into the USB3.0 port, it doesn't lose bytes. Then again, that's a 3.0 port and not a 3.1 port.

 

[slicerwizard]

Well, those rtl_test numbers certainly look bad. My laptop, running Win10, has a mix of 2.0 and 3.0 USB ports; I'm getting good numbers (very few reports of dropped samples) from all ports, even when using an unpowered hub running off the laptop's USB-C connector. No 3.1 ports here to test.

 

[wesct]

I have ran rtl_test to find the issue with failed CRC's in DSD+FL. I don't know if it's the bottleneck of the RTL-SDR being a USB 2.0 device on a USB3.1 integrated circuit. There is no USB 2.0 connections. I know USB3.1 is backwards compatible. This much loss in bytes is concerning.


wmic returns:


Same results testing my other dongle. I suggest that on some USB3.1 hardware backwards compatibility to USB2.0 is limited or maybe restricted when using RTL-SDR's on USB3.1. It does work. I can run SDR#, SDRTrunk, RTL1090. I am also not even sure if rtl_test is able to read correctly from a USB3.1 controller very well.

Any thoughts?

It might be a good idea to turn off any antivirus software, as probing ports will disrupt and corrupt the data flow.

Been there, done that many times with other programming software. Uninstalled the antivirus and problem went away.

 

[a417]

Could be to do with it being a Linux program being compiled to run in Windows,

Probably not the issue.

I think the problem is that the device driver and USB host device has some slight issues with USB 2.0 compatibility mode that it is required to use when a USB 2.0 device (which is what the NooElec thing is) is plugged into a USB 3.1 host.

It's not until a USB 3.x+ native RTL-SDR device is plugged in that you can take full advantage of the bandwidth and host adapter speeds.

 

[air-scan]

This laptop does have a third USB 3.1 port that is Type-C i never plugged anything into but I don't have a female USB-A to male USB-C adaptor or cable.

Well, those rtl_test numbers certainly look bad. My laptop, running Win10, has a mix of 2.0 and 3.0 USB ports; I'm getting good numbers (very few reports of dropped samples) from all ports, even when using an unpowered hub running off the laptop's USB-C connector. No 3.1 ports here to test.

Probably not the issue.

I think the problem is that the device driver and USB host device has some slight issues with USB 2.0 compatibility mode that it is required to use when a USB 2.0 device (which is what the NooElec thing is) is plugged into a USB 3.1 host.

It's not until a USB 3.x+ native RTL-SDR device is plugged in that you can take full advantage of the bandwidth and host adapter speeds.

That seems to be the piece of the puzzle I was looking for. Strange thing is SDRTrunk and SDR# sound really good. DSD+FL is the only app effected by the bottleneck from hardware compatibility limitations (USB3.1).

 

[air-scan]

It might be a good idea to turn off any antivirus software, as probing ports will disrupt and corrupt the data flow.

Been there, done that many times with other programming software. Uninstalled the antivirus and problem went away.

Well I don't have any 3rd party antivirus installed. Just Windows Defender is running and I seriously doubt Windows Defender is causing any negligible performance hits.

Thanks for your replies. Anything new comes out that can workaround it I would welcome.

 

[relicwr]

Check the power settings in Windows. It's possible that it's the USB selective suspend setting. It can be found in Power Options in the old control panel. The other option I can think of is a newer driver for that USB controller.

 

[air-scan]

Check the power settings in Windows. It's possible that it's the USB selective suspend setting. It can be found in Power Options in the old control panel. The other option I can think of is a newer driver for that USB controller.

I already disabled that for plugged in option also went into device manager and deselected allow this device to sleep with computer or something like that. Its not that option. Its the usb compatibility limitation.

 

[wesct]

Well I don't have any 3rd party antivirus installed. Just Windows Defender is running and I seriously doubt Windows Defender is causing any negligible performance hits.

Thanks for your replies. Anything new comes out that can workaround it I would welcome.

That is the problem with engineers and end users: Engineers want to scan the drive, End users do not want to wait.

Microsoft and data ports don't mix: 3 hours to setup a 396t: file corrupted after 2 hours into the send.

 

[slicerwizard]

Strange thing is SDRTrunk and SDR# sound really good. DSD+FL is the only app effected by the bottleneck from hardware compatibility limitations (USB3.1).

SDRTrunk and SDR# are probably 64 bit applications. They'd be using different, possibly newer, DLLs for starters.

 

[air-scan]

SDRTrunk and SDR# are probably 64 bit applications. They'd be using different, possibly newer, DLLs for starters.

There is a file version difference in libusb.dll between DSD+FL and SDR#(newer). SDR# and DSD+FL have same version rtlsdr.dll. SDRTrunk looks to be using a wrapper libusb4java and usb4java.

I don't see how all three dongles have such large byte loss. It's happened before but few and far between. It really does look like USB3.1 is the bummer. I do enjoy it's transfer speeds outside that.

 

[Chance]

Something that caught my eye in your output is " RelWithDebInfo" folder in your path. This generally indicates a program that is not compiled with optimizations that are standard in release mode. Try grabbing the official release version at Index of /binaries/windows/rtl-sdr/ Also try a different sample rate if your other programs are not using the test default of 2,048,000 samples per second.

The test program and library are written in C and is cross platform. It should run equally well under Windows or Linux. Generally a few missing samples is accommodated in the receiving application and will not ruin everything. Your CRC issue may be somewhere else. But with that low sample rate there should be no reason to see that many samples lost. The test program is a very good indicator that something is not optimal as it removes all unnecessary code from the equation to see if samples can be received. It puts the dongle into a mode that returns incrementing numbers. The test program listens to each dump of data to look for any gaps. What is left is a simple test of can the computer talk to the USB hardware. This is the main part of the code

    for (i = 0; i < len; i++) {
        if(bcnt != buf[i]) {
            lost += (buf[i] > bcnt) ? (buf[i] - bcnt) : (bcnt - buf[i]);
            bcnt = buf[i];
        }

        bcnt++;
    }

Translation:
I should have 0, did I get 0?
I should have 1, did I get 1?
I should have 2, did I get 2?
I should have 3, did I get 3? Nope I got 4.. I missed 1 sample.


Also, which driver are you using in ZxDiag? It should be WinUSB. But you can try the others as well.

It's most likely a USB 3.1 issue. That is the only thing I have encountered before. Usually switching to a hub or finding a different device driver fixes the issue.

 

[slicerwizard]

This is the main part of the code

Seems to be needlessly complicated.

for (i = -1; ++i < len; )
 {
 lost += abs((int)buf[i] - next);
 next = buf[i] + 1;
 }

 

[Chance]

Much more elegant and you are covering every case I can think of! Not sure who is managing the project, but worth a PR at osmocom/rtl-sdr

Seems to be needlessly complicated.

for (i = -1; ++i < len; )
{
lost += abs((int)buf[i] - next);
next = buf[i] + 1;
}

 

[air-scan]

I just have what is in the DSD+ dll files they want you to put into the DSD+FL folder from scratch. I used the newest ZADIG v2.5 with WinUSB. Tried libusb, libusbk and the other one I can't remember without loading zadig. DSD+ FL FMP24 will not allow changing sample rate. It likes 2.4msps only. Believe me I already tried lower sample rate in FMP24.cfg. FMP24 barked at me for it and wouldn't run until I set it back.

HP doesn't have usb drivers for my laptop They rely on Microsoft it's a Microsoft driver. Intel isn't releasing the usb driver in their chipset drivers. They specifically state that in their description. That's how they treat laptops.

That's newest from Microsoft.


I don't see a way in the bios (Insyde F.11 Aug 2020) to enable hand off to Windows 10 which involves turning off Bios handling of xHCI.

As for trying different ports. It has 1 type-C USB3.1 port, 2x USB Type-A 3.0 ports all on that one USB 3.1 controller. I don't have the right cable for the type-C port and the manual says USB 3.1 only for that Type-C

 

[air-scan]

Was this issue supposedly fixed a long time ago? The multiple entries on a truncated voice channel. Every time a new line appears there is a break in voice. I just caught onto that.

 

[lwvmobile]

HP doesn't have usb drivers for my laptop They rely on Microsoft it's a Microsoft driver. Intel isn't releasing the usb driver in their chipset drivers. They specifically state that in their description. That's how they treat laptops.

That sounds about right. Chipset manufacturers aren't always so good about releasing vendor neutral drivers and force you to use your vendor for driver packs or Windows Update. I remember that being a big pain in the rear back in the day when you had to reload Windows on older hardware and didn't have the factory image or didn't want to use it because of all the bloatware.

If you're feeling a bit adventurous though and want to settle whether or not its a straight up hardware problem or a Windows driver issue though, you might try installing something like the Skywave Linux image on a USB thumb drive and booting your laptop with it and then running the rtl_test again just for the knowledge of knowing whether or not its hardware/chipset issue or a driver issue.

Software Defined Radio for Global Online Listening

 

[air-scan]

That sounds about right. Chipset manufacturers aren't always so good about releasing vendor neutral drivers and force you to use your vendor for driver packs or Windows Update. I remember that being a big pain in the rear back in the day when you had to reload Windows on older hardware and didn't have the factory image or didn't want to use it because of all the bloatware.

If you're feeling a bit adventurous though and want to settle whether or not its a straight up hardware problem or a Windows driver issue though, you might try installing something like the Skywave Linux image on a USB thumb drive and booting your laptop with it and then running the rtl_test again just for the knowledge of knowing whether or not its hardware/chipset issue or a driver issue.

Software Defined Radio for Global Online Listening

If there is a way to run rtl test on android my tablet has the ability to run sdr

 

[lwvmobile]

If there is a way to run rtl test on android my tablet has the ability to run sdr

I'm not sure. I thought the idea was to rule out whether or not this was a usb chipset or driver issue on your laptop though.