# Problem with RTL-SDR v3 dongle - unusable PLL

I own an RTL-SDR v3 USB dongle (official version from rtl-sdr.com). I've successfully used it for decoding weather satellites past year. I use (GQRX + Audacity)/(Arch Linux 64bit) + (WXtoIMG)/(Windows 10 64bit) combination to receive and decode NOAA images and (glrpt)/(Arch Linux 64bit) to receive and decode images from Meteor-M sats. However now I observe strange behavior. I've tried to record about a dozen of NOAA passes but with no luck - my images are slanted and WXtoIMG can't do anything with that (see picture below). Also it says that it can't find telemetry data or complains about poor SNR ratio. This is strange because I constantly get about 40 dB SNR in GQRX for most prominent APT peaks.

In glrpt I observe issue with PLL locking. Signal level is awesome, AGC works fine, but PLL never locks even if satellite is flying right above my head. Previous summer I was able to start decoding from 2--4 degrees above the horizon.

At the same time I use GQRX quite well and can clearly hear FM broadcasting, NFM chatting and even AM broadcasting with the use of SpyVerter upconverter.

I don't know what can cause such issues as non-lockable PLL and troubles with NOAA reception (I think they are related to each other). I suppose my dongle become damaged somehow but don't know exactly how. It has protection diode on the input and I handle it with care so it shouldn't be ESD-smashed (I suppose it will not work at all after discharge).

May be someone has already faced such a problem and could give me some advice? Or how can I test my hypothesis on 3rd-party test?

Thank you!

UPDATE 1: I've tried with using LTS 5.4.32 kernel on Arch Linux, compiling glrpt with GCC 8.4.0, clang but still getting the same issue. WXtoIMG works fine - when I feed old recording to it then it gives me nice images. Moreover, I've found that its is impossible to decode DRM HF stations with DReaM decoder in realtime at all - it fails to get all three CRCs good. Only sometimes it's able to say me station name and show list of channels. At the same time feeding sample audio from other users works just fine. I suppose it's all related to the dongle - APT, LRPT, DRM fails while simple audio works fine.

UPDATE 2: I've analyzed audio spectra for two files: good recording from last year and a bad one from past week. Here are the results.

Good. I can see main 2.4 kHz peak, 4.8 kHz multiple and minor peaks. Frequency drift @2400 Hz is negligible.

Bad. There is no multiple of 4.8 KHz, main peak is very broad. I can't see minor frequencies. Also there is a quite significant drift from 2400 Hz.

UPDATE 3: Yesterday I got another dongle (simple blue from AliExpress). The problem is still here! I observe the same symptoms as with RTL SDR blog v3 dongle. Even spectra are the same.

UPDATE 4: I've found the cause of the problem - it's VOLK who ruined decoding. Filed an issue on GQRX GitHub. Seems like there are some serious bugs with VOLK's DSP, will recheck soon.

Also both dongles - cheap "blue Chinese" and RTL SDR v3 works just fine! So there is definitely no problem with crystals inside them.

UPDATE 5: I've investigated the problem even further and this is not a bug with a VOLK. GQRX's frequency correction seems to ruin decoding. See my answer for full details.

• In that 9-minute-long image, you've drifted 0.25 seconds. That's a lot of drift. Since phase-locking to the 2400 Hz subcarrier is done within WxSAT, and WxSAT relies on your PC's clock, I'd be looking at the PC's clocking structure. In my IMSAI 8080, I had to tweak its 18MHz crystal clock to get the PLL within lock range. Its lock range was very narrow, but very noise-tolerant. Apr 20 '20 at 17:37
• Copied from "WXtoImg_Guide": Correcting Image Slant Enter the Options Menu where you must make sure that the 'Disable PLL' feature is ticked but all other options are deselected. Load and decode a WAV file. Once the image displays, click 'Slant Correction' in the 'Image menu'. If the image margins are not vertical, move the cursor to the top of the image margin then click and hold down the mouse; drag the mouse to a position lower down on the same margin then release it. Return to the Options Menu and uncheck 'Disable PLL'. Your images should now decode with perfect vertical alignment. Apr 20 '20 at 21:15
• @glen_geek How did you calculate 0.25 secs drift? I use the same PC as in previous year, my host OS is Arch Linux and I use GQRX installed on it. WXtoIMG is installed on Windows 10 on VirtualBox. Last year all worked fine. I observe the same issue for NOAA 18 and 19 as well. Moreover glrpt can't lock during reception of Meteor-M2 too. Absolutely nothing changed in software/hardware but I can't decode APT and LRPT images and it seems like PLL is the cause Apr 21 '20 at 8:00
• 0.25 sec: Bottom of your image is displaced approx one whole IR-frame compared with the top of your image. APT sends 4 frames-per-second. Counting minute-markers, your image is about 9 minutes "high". Your image also contains Doppler-shift, although it is dominated by mis-timing. 0.25s in 9min is one part in 2160 timing error. You might see that kind of error in Audacity FFT. I tried, but frequency resolution of Audacity's spectrum is poor. Hosing your dongle-receiver into SpectrumLab FFT might have better Freq resolution of 2400 Hz APT. That might give you a clue. Apr 21 '20 at 14:18
• About update2: Good spectra is what you should get. Its frequency drift is entirely due to Doppler. BAD spectra shows carrier a few Hz high, and unstable. Since two dongles give the same result, perhaps the occasional sample is dropped (about one or two each second) somewhere between dongle & WXtoimg. WXtoimg uses you're PC's sound A-to-D to re-sample audio. Have you checked that it is behaving properly? Can you sample a very stable audio tone, and get the right frequency? Apr 25 '20 at 14:51

One common thread in all those dis-similar softwares is ADC sampling rate. It might be worthwhile to do a frequency calibration run to see if there's a problem there.
NOAA's APT signal provides a convenient and very, very accurate frequency calibration reference: 2400 Hz audio carrier. If it's frequency is any other than 2400.00 Hz, then either samples have been dropped, or sampling rate is inaccurate. It might be worthwhile to examine a xxx.wav file and take a close look at carrier frequency.

To provide you a benchmark, an old xxx.wav file was pulled for examination. It was captured by Wxtoimg and saved. Sampling was done by WINDOWS 7 16-bit soundcard at 11025 samples-per-second. Wolf's SpectrumLab was used to track 2400 Hz carrier frequency using its maximum 524288-point FFT. Bin resolution is 0.021 Hz, and its peak-frequency tracking is excellent. FFT window span is about 47 seconds of audio:

• At signal acquisition, carrier frequency was high, at 2400.047 Hz
• At signal loss about 12 min. later, carrier frequency was low, at 2399.94 Hz

Carrier frequency variation is mostly due to doppler shift, nevertheless it would appear that sampling is a tiny bit off (mean frequency is 2399.9935 Hz). This does not cause a problem for the WXtoimg software.

Using other software with PLL-tracking turned off, the same PC soundcard yields a decent vertical image, with a bit of doppler skew top and bottom.
Take care to ensure that sample processing doesn't drop samples. Your image skew direction suggests that this is a possible cause instead of PLL-mistracking.

This sounds like the TCXO, or thermally corrected oscillator, crystal has failed in the dongle.

In my experience the dongles heat up during use. This heating (and cooling) can over time can deform the crystal beyond the tolerances that can be corrected by by the factory calibration of the TXCO. This may cause over and under corrections to the clock(bounces between the maximum and minimum).

Precise PLL locking is dependent on a stable local clock signal, any jitter, the amount of variation of non-uniform timing pulses, produced by the local oscillator disrupts the ability of the PLL to stabilize.

Since the PLL by definition compares the phase difference based on the local oscillator, a large jitter, the same value, but in this context the amount of phase difference from one pulse to the next, amount will disrupt the locking process.

If the jitter consistently exceeds the bandwidth and then does not, it will cause the received frequency to move slightly up and/or down. This shift would be so minor as to be imperceptible by the human ear, when listening to audio. Since the small corrections are happening very fast.

Analog audio(AM or FM) data only has to be close to the frequency not be rejected. The shifts are not noticeable. Digital data requires precise timing to be decoded precisely and accurately.

The sample rate which maxes out at 2.4MHz on most dongles, definitely plays a factor, as does the 8-bit resolution, hence the loop around the offset frequency.

The only test is to compare a your received time from radio digital non-moving time sources, such as the time beacons, and compare the offset with a GPS receiver. I cannot tell you how to do that with the precision required.

This damage could also be caused by an electrostatic charge or lightning strike nearby, if it were a direct hit the dongle would be gone.

Now after all of that, I would recommend replacing your your dongle and adding additional external heat-sinks and a fan, and a static discharge circuit to your antenna.

This entire answer is created upon my own experiences with these dongles. I cannot discount the oscillator on the computer theory, but the probability of fault leans to the dongle, due to the major temperature fluctuations in the dongle making this the more likely source of the issue.

• Actually my dongle have been spending its life on the shelf almost all the time from the last August. I've used it few times but much less than during summer receiving sessions. I have done calibration with Kalibrate tool last September and got 1.6 ppm. I'm using this value right now in GQRX. My sampling rate is 2.56 Mbps and I use it successfully all the time from the beginning. Also RTL SDR v3 dongles have an aluminum enclosure and still getting very hot. May be this finally killed TXCO. There was no lightning strikes nearby and I always handle it with care so ESD shouldn't be Apr 23 '20 at 21:09
• Should try with another dongle, though. I think I'll make custom case for my dongle just with computer fan Apr 23 '20 at 21:12
• I would try a heat sink(or multiples) + fan. The effectiveness of a fan is dependent on the temperature differential and surface area. Give it more surface area and the temperature difference will decrease close to exponentially. Apr 23 '20 at 23:05
• Has the room temperature changed significantly since you last calibrated the ppm? If so, you may need to recalibrate. Apr 24 '20 at 21:14
• no, calibration was held at 25 degrees. Now temperature is about 22-24 degrees Apr 25 '20 at 10:40

Seems like finally I was able to solve the problem!

Some time ago I've generated VOLK optimized profile according to the developer recommendations. After that I haven't been using real SDR receptions for several months and then faced a problem described in first post. Now I've remembered it and just deleted this optimal profile. Once that was done I was able to receive and decode APT transmissions just perfectly! Moreover, DRM radio works fine too! I think I'll file a bug for GQRX about this issue with VOLK.

Regarding LRPT reception: I've tried mlrpt software and it works brilliant while glrpt still shows me very strong signal and gives no PLL lock. I think my dongle is getting overloaded by some strong signal and auto AGC setting makes things even worser in this case. I can't figure out the exact cause of it right now. Should recheck with manual gain settings, though.

Many thanks to everyone participated in the discussion! Here was a lot of useful info for personal education and experience.

UPDATE 1: I've investigated the situation even further and found that actually this is not the VOLK to blame! When I removed VOLK config last time I also set Frequency Correction in GQRX to zero again (was -1.6 ppm). Then I thought that it's VOLK who ruins further decoding. However, I've re-generated VOLK profile again while leaving freq. correction at zero and things work just fine! After that I've stashed VOLK config and set freq. correction to -1.6 ppm again and all of my APT/DRM decoding failed again! Setting it to zero solves the problem. Seems like there is a bug with the GQRX itself. I've done some tests and you see the results on the corresponding issue page on GitHub.

• Thanks for following up and describing the fix! May 4 '20 at 14:44
• You could help with figuring out which VOLK algorithm has a bug by removing parts of the generated volk_config file (I assume this will reset to the default generic algorithm) and seeing which line(s) make the problem appear/go away. May 4 '20 at 23:57