Problem with RTL-SDR v3 dongle - unusable PLL

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.