Tuning the radio on an RTL SDR receiver, it’s very common to find the frequency read-out to be wildly inaccurate. To correct for this SDR applications request a PPM value which is unique to each RTL SDR USB dongle. To get your PPM value run the following command in the Linux CLI:

rtl_test -p

After several minutes you’ll have a read-out like the following:

Found 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 Sampling at 2048000 S/s. Reporting PPM error measurement every 10 seconds... Press ^C after a few minutes. Reading samples in async mode... lost at least 196 bytes real sample rate: 2048184 current PPM: 90 cumulative PPM: 90 real sample rate: 2048151 current PPM: 74 cumulative PPM: 82 real sample rate: 2048198 current PPM: 97 cumulative PPM: 87 real sample rate: 2048152 current PPM: 74 cumulative PPM: 84 real sample rate: 2048186 current PPM: 91 cumulative PPM: 85 real sample rate: 2048166 current PPM: 82 cumulative PPM: 85 real sample rate: 2048161 current PPM: 79 cumulative PPM: 84 real sample rate: 2048189 current PPM: 93 cumulative PPM: 85 real sample rate: 2048170 current PPM: 83 cumulative PPM: 85 real sample rate: 2048165 current PPM: 81 cumulative PPM: 84 real sample rate: 2048188 current PPM: 92 cumulative PPM: 85 real sample rate: 2048162 current PPM: 80 cumulative PPM: 85 real sample rate: 2048180 current PPM: 88 cumulative PPM: 85 real sample rate: 2048174 current PPM: 85 cumulative PPM: 85 real sample rate: 2048161 current PPM: 79 cumulative PPM: 84 real sample rate: 2048182 current PPM: 89 cumulative PPM: 85 real sample rate: 2048183 current PPM: 90 cumulative PPM: 85 real sample rate: 2048153 current PPM: 75 cumulative PPM: 84 real sample rate: 2048179 current PPM: 88 cumulative PPM: 85 real sample rate: 2048184 current PPM: 90 cumulative PPM: 85 real sample rate: 2048165 current PPM: 81 cumulative PPM: 85 real sample rate: 2048178 current PPM: 87 cumulative PPM: 85 real sample rate: 2048177 current PPM: 87 cumulative PPM: 85 real sample rate: 2048166 current PPM: 81 cumulative PPM: 85 real sample rate: 2048195 current PPM: 95 cumulative PPM: 85

As you can see. the value averages out over time to give a stable reading. My USB dongle is off by 85 PPM so I’ll enter this to correct my frequency reading.

However I found afterwards that this still leaves me slightly off the mark, so using a graphical SDR application such as GQRX, tune to a known frequency then fine-tune the PPM value until the signal meets the tuning line in the middle. Typically I find mine is ~73 PPM using this method, this can vary by ~1-2 PPM but it’s enough to hit signals when tuned to the right frequency.

For a known frequency I suggest finding a local repeater, preferably on 70cm to 23cm for highest precision, but one that is most active is best. You might also use APRS which is always 144.8MHz in Europe, different frequencies in other regions but it’s reliable. Both these choices are NFM so you should hit them exactly in the centre of the broadcast when tuned correctly.

sm313 on YouTube tried using GSM mobile frequencies, this is a good choice because it’s a high frequency so has good precision and is constantly broadcasting, but you need to know what you’re looking for in a very wide-band signal so might not be that straight-forward.

If you have other suggestions please leave advice in the comments.

rtl_test -p

result: [22:48 root@RB173 ~] > rtl_test -p

-bash: rtl_test: command not found

Looks like rtl_test is not installed, rtl_test is in the ‘rtl-sdr’ package on Debian family systems, other distributions may vary.

[20:32 root@RB3 ~] > rtl_test -p 30

Found 1 device(s):

0: Generic, RTL2832U, SN: 77771111153705700

Using device 0: Generic RTL2832U

usb_claim_interface error -6

Failed to open rtlsdr device #0.

Either you are not in the right user group to access the USB device or DVB drivers are still loading up claiming the hardware first. There may be other reasons but that’s usually the cause.

What about on Windows devices?

I don’t know, I don’t use Windows