SDR# Issues with NooElec / RTL-SDR.com on new Win10 PC

[w2lie]

HI All

I'm running into a huge problem that I've been trying to find a solution to for the entire day.

If you don't feel like reading, this video describes my issues




I just built a new computer to run some SDR projects. This PC was built for this and I think Murphy has his hands in this build.
AMD Ryzen 3700X at 3.60Ghz, 32GB RAM, Windows 10 Home 64Bit, and Radeon RX 5500 XT display adapter.
PC was built primarily to run many different SDR applications and hardware. I haven't had any problems like this on any other computer until now. (go figure)

I'm running NooElec, RTL-Blog V3, and AirSpy hardware as well as SDR# and SDR-Console

The problem does not appear on my laptop with the same hardware/software and is not present when I use the AirSpy on the new desktop.
This only happens with the NooElec or RTL-Blog devices with both SDR# and with SDR-Console.

Issue 1. SDR# will crash if I start, stop, and then attempt to restart the receiver

Issue 2. SDR# and SDR-Console will begin to receive "off frequency". I begin on frequency with FM Broadcast Radio. Eventually while moving down the dial, the frequency will continue to move down, but the actual received frequency will just keep repeating. It never moves down to match the displayed frequency

Issue 3. Same as above with SDR# and SDR-Console will begin to receive "off frequency". So instead of showing say 94.3, the center frequency is 94.4MHz (which we don't use here in the US). The actual received frequency is about 1.5Mhz off from where things look on the display. Moving the dial in the opposite direction corrects the display and received frequency.


I'm running SDR# 1.0.0.1803 (did not have the computer built to try any other previous versions). I did install .NET 5 x86 per instructions on the Airspy website.
Zadig has WinUSB V6.1.7600.16385 installed for the SDR's, with the exception of the AirSpy.

I've tried to install some DLL files that I found on the RTL-Blog forums, but those didn't seem to help. Apparently there might be an issue with new AMD Ryzen chips and these dongles? I hope that is not the case because I was planning on running a stack of RTL sticks on this computer.

I've been researching possible solutions all day and can't seem to find anything that fixes my issue.

Thanks in advance for any help you can provide.

73
Phil / w2lie

 

[GTR8000]

Phil, just for the heck of it, try reinstalling Zadig driver with only one dongle plugged in...except after selecting List All Devices, uncheck Ignore Hubs or Composite Parents. Make sure the driver is correct for the one RTL entry on that list (it doesn't hurt to reinstall the driver just to be sure). I don't necessarily think that's the issue, however there have been a few people recently who have run into various issues with the dongles, and that seems to have helped.

I'm also curious, is the dongle working with Unitrunker? No offense to SDR#, but I'd rather see a video of what the dongle is doing in UT 2.1 locked on a control channel. Or even DSD+ would be fine, but locked onto a control channel will give a better idea of what is going on vs looking at FM broadcast stations. The RTL-SDR.com dongles normally require an initial correction of anywhere between -1.5 to -3.0 ppm (they tend to be in the negatives, whereas NooElec tends to correct in the positives, normally +1 to +1.5).

 

[PDXh0b0]

new system, do you have visual c++ installed?

 

[rabbit108]

Issue 2. SDR# and SDR-Console will begin to receive "off frequency". I begin on frequency with FM Broadcast Radio. Eventually while moving down the dial, the frequency will continue to move down, but the actual received frequency will just keep repeating. It never moves down to match the displayed frequency

I have noticed that under certain conditions the frequency entered doesn't agree with the frequencies below the spectrum. This usually happens when the wrong source is entered and then you change to the correct source when the Tuning type is set to Sticky tuning.
Airspy W/HackOne RF US Weather heard on 155.55 but not 162.55



The SDRsharp Guide is here:
https://airspy.com/downloads/SDRSharp_The_Guide_v1.4_ENG.pdf

example:

 

[rabbit108]

Issue 1. SDR# will crash if I start, stop, and then attempt to restart the receiver

Ref: my previous post with similar problem:
Low to no signal in PDW

When I was hunting for more POCSAG signals with SDRsharp, my Windows 10 computer locked up. I had to do a forced shutdown and then it wouldn't restart. It took me 4 attempts to do a restore to an earlier date; seems to be OK now.

I couldn't use my computer until I fixed it. It happened when I stopped the signal in the SDRsharp software and then tried to turn it on again.

I tried to show the signal in the spectrum analyzer scan during a transmission AND the signal in the waterfall below it. That's when my computer got locked up from ON and OFF switching with the Play/Stop button. At this point, I don't want to do that again with the SDRsharp software. I might not be able to fix my computer again.

So I switched to my SDRplay RSP1A SDR with SDRuno software. My signal is also weak and the high noise level on VHF reduces the SNR of the signal.

 

[w2lie]

Thanks everyone for the suggestions so far....

I have seen issues on the RTL blog from 2019 with the new AMD Ryzen chipsets causing problems. I dropped well over a grand on this PC build with the mother board and chip eating most of the expense. (I overbuilt for just SDR but I do have needs for this type of machine in my shack). I've been building AMD computers for years since I normally find them better value for the money, but I'm guessing that maybe I should have gone with an Intel Chipset this time around? We'll have to keep that bridge in sight.

Phil, just for the heck of it, try reinstalling Zadig driver with only one dongle plugged in...except after selecting List All Devices, uncheck Ignore Hubs or Composite Parents. Make sure the driver is correct for the one RTL entry on that list (it doesn't hurt to reinstall the driver just to be sure). I don't necessarily think that's the issue, however there have been a few people recently who have run into various issues with the dongles, and that seems to have helped.

I only have 1 dongle plugged in at a time. I've moved the dongles around the USB ports using both 2.0 and 3.0 ports on my computer. All ports are connected to USB Headers on my motherboard and are not on expansion boards or routed through hubs (fyi).

Zadig drivers were reinstalled countless times. I've gone into Device Manager several times and removed the hardware from the list.
If it helps any, the first time I plugged in the USB stick windows did not auto detect it and throw on the generic driver and Zadig actually timed out the full 5 minutes. This is the first time I've seen that problem.

After a reboot Zadig was able to load the driver the first time around and this was the only time I had a problem with Zadig timing out.

I've also gone done the route of ignoring hubs or composite parents and this doesn't change the naming on the RTL at all.

I'm also curious, is the dongle working with Unitrunker? No offense to SDR#, but I'd rather see a video of what the dongle is doing in UT 2.1 locked on a control channel. Or even DSD+ would be fine, but locked onto a control channel will give a better idea of what is going on vs looking at FM broadcast stations. The RTL-SDR.com dongles normally require an initial correction of anywhere between -1.5 to -3.0 ppm (they tend to be in the negatives, whereas NooElec tends to correct in the positives, normally +1 to +1.5).

I haven't gotten that far on the install yet. My process is normally to play around with SDR# and then get my drift corrections done in here. Once I saw this problem I kind of started spending HOURS just trying to figure out what could be wrong. I can't even set drift in SDR# !


However, if these work fine tuning around and jumping with UT, DSD Plus, and SDR Trunk, I'll be happy. But if the constant tuning around on these cheap USB receivers is what is causing the problem on SDR# and SDR Console, then this entire project is a monument to failure

new system, do you have visual c++ installed?

Yes. C++ 2010, 2013, 2015-2019 are all installed on my system.

I have noticed that under certain conditions the frequency entered doesn't agree with the frequencies below the spectrum. This usually happens when the wrong source is entered and then you change to the correct source when the Tuning type is set to Sticky tuning.
Airspy W/HackOne RF US Weather heard on 155.55 but not 162.55

I'm only using a single source at the moment at one time, so not sure that is the problem. However, I am not using Sticky tuning.
I'll give that a go later today.

 

[w2lie]

So I switched to my SDRplay RSP1A SDR with SDRuno software.

I have an RSPdx and Hack RF One that I will also be testing on this system. I'm not locked into SDR# or SDR Console for my current requirements.

However, it would be easier (and cheaper) to use the NooElec and RTL-SDR v3 dongles for my monitoring needs when it comes to specialty projects such as running UniTrunker (et al) across several different bands (UHF, 700, and 800)

If the cheap dongles will work fine with software other than SDR# and Console, I'll be a happy camper. I'd just love to understand why this hardware doesn't want to work on this new computer.

 

[rabbit108]

At this point, I don't trust SDRsharp with my RTL-SDR.COM V3 dongle in my Windows 10 computer. SDRsharp seems to work OK with my Airspy R2; mostly use it with Spectrum Spy.

 

[GTR8000]

I haven't gotten that far on the install yet. My process is normally to play around with SDR# and then get my drift corrections done in here. Once I saw this problem I kind of started spending HOURS just trying to figure out what could be wrong. I can't even set drift in SDR# !

If the only software you've tried them with is SDR#, then you haven't eliminated SDR# as the culprit. Install Unitrunker and try tuning to a control channel, then report back the results.

 

[a417]

I have seen issues on the RTL blog from 2019 with the new AMD Ryzen chipsets causing problems. I dropped well over a grand on this PC

Have you tried a USB expansion daugher-card? If the problem truly lies with the onboard implementation of USB via the Ryzen chipsets - this may be a easy way to see if a separate USB root hub controller can solve your problems. There are many of them online that you can try for <$30.

 

[w2lie]

If the only software you've tried them with is SDR#, then you haven't eliminated SDR# as the culprit.

I also said I used SDR Console with the same issues.


So I am failing hard with this install
I also thought maybe my USB ports were not getting enough power, so I plugged the USB stick into a powered USB hub.


Getting the following problems with both DSDPlus Public release in FMP when I try to tune up or down from the starting frequency:

rtlsdr_demod_write_reg failed with -9

When I launch FMP24 and park on a frequency then start DSD Plus FL and try to tune around, I get the following:

rtlsdr_demod_write_reg failed with -9
Error - remove/reinsert dongle with serial string '00000001'
SDR device count = 1

So then let's look at rtl_test.exe

ound 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...
lost at least 32 bytes

I understand the PLL not locked is normal.
rtl_test stops printing any feedback after the first lost string.


Here is my Zadig:



Devices shown with check boxes next to both "List all Devices" and "Ignore Hubs or Composite Parents"


And now with the check box removed from "Ignore Hubs or Composite Parents"


And for sanity sake, let's look at Device Manager:

 

[w2lie]

Have you tried a USB expansion daugher-card? If the problem truly lies with the onboard implementation of USB via the Ryzen chipsets - this may be a easy way to see if a separate USB root hub controller can solve your problems. There are many of them online that you can try for <$30.

I was just thinking this but wasn't sure if a daughterboard would get me around the Ryzen chipset or not. Unfortunately I don't have any PCIe USB expansion cards laying around so I am going to have to order one.

I'm really hoping that because I've set so many of these that I am just overlooking something completely obvious, but the more I dig into this the less hopeful I become

I do appreciate all the tips and help.

 

[a417]

I was just thinking this but wasn't sure if a daughterboard would get me around the Ryzen chipset or not. Unfortunately I don't have any PCIe USB expansion cards laying around so I am going to have to order one.

I'm really hoping that because I've set so many of these that I am just overlooking something completely obvious, but the more I dig into this the less hopeful I become

I do appreciate all the tips and help.

The USB daugherboard would provide a separate root hub controller to all downstream devices, and connect thru to the system via PCIe(x) and would not present that device to the onboard USB controller. If the onboard USB controller is the culprit, you should be able to disable in the BIOS. Almost every BIOS i've been in recently allows me to disable/modeset/change the onboard USB root hubs.

 

[w2lie]

Interesting. So I'll have to disable the onboard USB controller in the BIOS once I plug in the PCIe board? I didn't know that. I thought they could live side by side.
I guess that effectively disables all the motherboard's onboard USB ports? And the case's built in USB ports would have to connect to a header pin on the PCIe card to be used at that point.

 

[VladeDoddy]

I was having the same issue a couple of months ago with a Ryzen 2700X system. I copied a different version of the rtlsdr.dll file into the SDR# folder and haven't had that issue since. The one that I used can be found here: Release RTL-SDR-BLOG Windows Release V1.0 · rtlsdrblog/rtl-sdr-blog · GitHub

Download the Release.zip file and extract the rtlsdr.dll file from it and copy it into your SDR# folder to see if that helps.

 

[w2lie]

Download the Release.zip file and extract the rtlsdr.dll file from it and copy it into your SDR# folder to see if that helps.

Thanks. That was one of the first things I tried but that didn't work. I'll give it another shot after work though.

 

[VladeDoddy]

The 1.01 version of the dll didn't work for me (it kept showing that my dongle was using an E4000 when it uses an R820T, the latest dll files from osmocon do the same thing). But the version 1.0 I linked to above did. I think I used a newer libusb.dll file as well but I can't remember and that may be worth trying if you haven't already.

 

[bama9999]

I was having the same issue a couple of months ago with a Ryzen 2700X system. I copied a different version of the rtlsdr.dll file into the SDR# folder and haven't had that issue since. The one that I used can be found here: Release RTL-SDR-BLOG Windows Release V1.0 · rtlsdrblog/rtl-sdr-blog · GitHub

Download the Release.zip file and extract the rtlsdr.dll file from it and copy it into your SDR# folder to see if that helps.

Thanks for that info! I couldn't get the latest version of SDR# to recognize my RTL-SDR V3 dongle, on Windows 10, but it worked ok with the earlier version of SDR# (No Skin). I followed your suggestion, and now the latest version of SDR# is working great with my RTL-SDR dongles.

Again, much appreciated!

 

[w2lie]

So it has been a couple of weeks since my initial post and I'd like to thank the community for helping out.

1st- an issue that was complicating my problems...
I installed a new PCIe card and immediately after I started to notice issues with my computer. My PC was extremely slow, would freeze, and was completely unhappy. It seemed that my brand new HDD decided to throw SMART errors at the same time, so I'm going to assume this was coincidence and my new HDD was bad.

2nd - the fix

updating the DLL files would not fix my issues.

However, @a417 's suggestion worked fine, and (knock on wood) continues to work! A new PCIe card allowed my computer to talk to the RTL chip SDR's just fine. My Airspy would work in any USB port, but my issue was trying to get my stack of sticks working.


I've also been trading e-mails with @GTR8000 and he sent me these two links, which at least makes me feel better. Now I know this type of problem isn't just my problem and I built a bad computer. I just picked parts that just happen to hate each other lol

FYI, I'm using an ASUS TUF Gaming B570 Motherboard with a Ryzen 3700 CPU. Guess what they say in the links below:

AMD Investigating USB Connectivity Issues with Ryzen PCs

AMD breaks out the magnifying glass

www.tomshardware.com

AMD Suggests Possible Fixes for Ryzen USB Connectivity Issues

Here, give this a shot

www.tomshardware.com

I have yet to check the suggestions in the second link to see if that helps solve my problems because right now I'm happy the way things are working. My mega SDR Machine build can continue.


Thanks all again for the help and I hope this thread helps someone else who finds themselves in my shoes.

 

[lwvmobile]

(Oops, didn't read the last post, my post was pretty much irrelevant)