Possible driver issue? Frequency correction issue, R820T2

[KC9WWJ]

Alright, i have 6 SDR dongles. (Nooelec) 2 smaller black R820T sticks, and 4 larger blue R820T2 sticks. The problem I'm having is specific to the R820T2 units.

I have, gotten unitrunker+dsd to follow trunked voice successfully, but I'm having frequency correction issues with the newer units. I can set the correction and use the R820T's, and the *FIRST* R820T2 with no issue. Its just that any additional R820T2 plugged in cannot be centered/corrected with the PPM setting.

It doesn't matter which actual/physical stick i plug in. Ive tried plugging em all in, in different orders, with same effect. So, i don't think its the hardware thats the problem. Like i said, the only affected units are whichever R820T2's are subsequently plugged in. After some playing, i found these 2nd-4th units are all .5 mhz off, which explained why they were useless for voice following.

Ive been able to make use of these for now by using an affected R820T2 as the "signal" receiver, paired with an R820T for the voice following, and it works fine. I just have to manually make up the .5 difference with the signal receiver. Like i need follow 853.825, so i have to park at 853.775...
I start the receiver, the site window comes up and thinks its following 853.775. After a couple seconds of decoding, unitrunker corrects/sets 853.825 as the control channel, and begins following control traffic just fine. But this workaround has its bugs for sure...

I have installed drivers for each of these units with zadig. Ive tried on multiple machines (win 7 and win 10 machines, and some virtual win machines with virtual box on OSX) All machines had same symptom.

Ive tried with the units directly on motherboard usb ports, as well as on a usb hub.

This .5mhz shift was observable in both Unitrunker and SDR#, which is kinda why I'm wondering if this isn't a driver problem? Any thoughts, or similar experiences?? I'm out of ideas...

 

[br0adband]

The Zadig drivers are used only for the purpose of allowing the hardware to be accessed and controlled by the software, that's all they do in this case so I would seriously doubt they have anything to do with the ppm. The software you're using (whatever it is) talks to the hardware through the driver API (Application Programming Interface) over the HAL (the Windows Hardware Abstraction Layer) and just passes info that the stick itself then uses to configure itself.

To say that another way: the software you're using to control the RTL sticks is what controls things, not the drivers - the drivers exist only so Windows-based software can make use of the RTL stick hardware. The software sets the ppm according to whatever you've chosen then it passes that to the RTL stick which then configures itself as instructed - the driver(s) has nothing to do with the instruction being passed along.

Have you taken the time to verify the ppm for each of the 6 sticks individually (maybe even tagging them by writing on the sticks themselves or using some kind of sticker to ID each one's ppm as required)?

With Unitrunker, are you enabling the "Drift Correct" feature as well? I've noted in my own configuration (two R820T sticks) that without that checkbox it will not "stick" on the CC frequency for long, even after the stick has warmed up and mine have verified ppm settings (49 for one and 55 for the other). I check that Drift Correct option (for both the Signal and Voice receivers since I'm following trunked comms) and voila, no issues at all.

I'd suspect there could be a hardware issue with the R820T2 sticks you have and not your computers or the software or even the drivers. You said you've tested them on various computers and reinstalled the Zadig drivers, etc - basic troubleshooting methodology suggests that when you change a lot of variables but one thing (the R820T2 sticks) stays the same, that's where the problem lies and not with the other variables. The one constant in your statements is that you've used the same R820T2 sticks in other computers, native motherboard USB ports, USB hub ports, etc is that (most) everything changed except the sticks themselves and the issue(s) remained even so.

Sounds like some defective sticks to me but I could be wrong.

 

[SCPD]

Hello KC9 ...

That sounds very weird. I'll play around this weekend to see if I can cause this here.

Are your RTL sticks all on the same hub & USB Controller or different hub / controller?

 

[KC9WWJ]

Hey Uni, i had tried just about every combination of ports that night. A little bit of an update though after a step away lol; without using the 2 R820T's, and only using the four R820T2's on an external USB hub, I re-found the apporpriate correction value for each stick one at a time. Theyve been labeled 1-4, and kept in order since ive owned em, just did it for safe measure. But, im no longer observing the 0.5mghz issue.
I'll try to recreate it here again in the next day or two, but for now ill just leave the R820T's unplugged as it seems to be staying stable enough for feed providing.