RTL Test Losing bytes on USB3.1

air-scan

Member
Premium Subscriber
Joined
Oct 6, 2019
Messages
306
Location
Oklahoma City, OK
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?
 
Last edited:

lwvmobile

Member
Joined
Apr 26, 2020
Messages
116
Location
Lafayette County, FL
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 :ROFLMAO: :ROFLMAO: 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.
 

Attachments

slicerwizard

Member
Joined
Sep 19, 2002
Messages
6,643
Location
Toronto, Ontario
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

Member
Joined
Jul 20, 2005
Messages
754
Location
Connecticut
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

!#
Joined
Mar 14, 2004
Messages
1,708
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

Member
Premium Subscriber
Joined
Oct 6, 2019
Messages
306
Location
Oklahoma City, OK
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

Member
Premium Subscriber
Joined
Oct 6, 2019
Messages
306
Location
Oklahoma City, OK
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

Member
Premium Subscriber
Joined
Feb 20, 2006
Messages
368
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

Member
Premium Subscriber
Joined
Oct 6, 2019
Messages
306
Location
Oklahoma City, OK
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

Member
Joined
Jul 20, 2005
Messages
754
Location
Connecticut
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.
 

air-scan

Member
Premium Subscriber
Joined
Oct 6, 2019
Messages
306
Location
Oklahoma City, OK
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.
 
Last edited:

Chance

Member
Feed Provider
Joined
Dec 19, 2002
Messages
88
Location
Sachse, Texas
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

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.
 

air-scan

Member
Premium Subscriber
Joined
Oct 6, 2019
Messages
306
Location
Oklahoma City, OK
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.
Annotation 2020-09-09 105305.png

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
 
Last edited:

lwvmobile

Member
Joined
Apr 26, 2020
Messages
116
Location
Lafayette County, FL
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.

 

air-scan

Member
Premium Subscriber
Joined
Oct 6, 2019
Messages
306
Location
Oklahoma City, OK
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.

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