dump1090 has a feature where you can correct for your RTL-SDR’s inaccuracy by passing a plus or minus PPM number to set the frequency correction. For example, my dongle, when set to 1090 Mhz, in SDRSharp shows that the signals are coming in slightly off frequency. In my case, I pass --ppm -14 to the software so it corrects for the inaccuracy.
How can I do the same thing in PiAware’s init script? Is there a way to pass parameters, and if so, how?
Begs the question of the frequency accuracy of a $25 receiver versus the transmitters, costing several thousand dollars each and which require periodic checks using calibrated equipment. I wonder if there temperature sensitivity issues in play, too. Does he dongle drift with temp?
When looking in SDR#, were you looking at many aircraft transponder transmissions? I’d think the exact tx freq aircraft send will be pretty darn close and vary around the mean intended freq.
There is also the band pass of the dongle’s tuner and its selectivity. I would think these things were taken into consideration when designed / programmed but I have no way to know.
Only tested during a short period of time. I know I get better results running dump1090 by hand specifying --PPM than when I use PiAware. I’ve thought about buying the model with the TCXO but can’t justify spending money on something that is helping a corporation. They should buy me the receiver and a real antenna.
The dongles do drift substantially with temperature (I see perhaps 5 PPM over the course of a day) but each dongle has a characteristic offset that it will float around - so it does make sense to set the PPM offset when you can.
kalibrate (source here) is handy for getting a good measurement of the offset - it measures the received frequency of part of a GSM signal that should have a very stable transmitter.
Thanks. I compiled the kalibrate software, but when I run it, it doesn’t find anything. I’m doing:
** ./kal -s GSM850**
I also tried running it against PCS and get the following:
PCS-1900:
[R82XX] No valid PLL values for 1933770000 Hz!
r82xx_set_freq: failed=-1
I also found where dump1090 is running and am able to pass parameters to it in the startup.
There are a couple of gotchas: (1) it doesn’t set the tuner gain unless you pass -g; you probably need to use at least “-g 30” (2) you will want to pass “-e ” to provide an approximate starting PPM adjustment or it can miss the signal because it’s too far off the nominal frequency it looks for. You can get an initial estimate to pass to -e with “rtl_test -p”.
And of course you need a suitable GSM network nearby! 
This is what it looks like when it’s working (this is just with the standard whip antenna):
$ ./kal -s GSM900 -e 56 -g 30
Found 1 device(s):
0: Generic RTL2832U OEM
Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Exact sample rate is: 270833.002142 Hz
Setting gain: 30.0 dB
kal: Scanning for GSM-900 base stations.
GSM-900:
chan: 20 (939.0MHz - 273Hz) power: 240093.75
chan: 42 (943.4MHz - 2.133kHz) power: 357138.90
chan: 67 (948.4MHz - 3.188kHz) power: 623441.68
chan: 83 (951.6MHz - 4.385kHz) power: 184083.94
chan: 95 (954.0MHz - 3.929kHz) power: 782931.50
chan: 97 (954.4MHz - 2.983kHz) power: 450108.43
chan: 99 (954.8MHz - 3.720kHz) power: 383891.87
chan: 103 (955.6MHz - 3.470kHz) power: 389593.06
chan: 114 (957.8MHz - 2.383kHz) power: 350993.36
chan: 122 (959.4MHz - 2.963kHz) power: 1760475.67
$ ./kal -c 122 -e 56 -g 30
Found 1 device(s):
0: Generic RTL2832U OEM
Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Exact sample rate is: 270833.002142 Hz
Setting gain: 30.0 dB
kal: Calculating clock frequency offset.
Using GSM-900 channel 122 (959.4MHz)
average [min, max] (range, stddev)
- 2.429kHz -2448, -2404] (44, 11.909014)
overruns: 0
not found: 0
average absolute error: 58.532 ppm
I also tried running it against PCS and get the following:
PCS-1900:
[R82XX] No valid PLL values for 1933770000 Hz!
r82xx_set_freq: failed=-1
This just means the tuner can’t tune that high. A R820T with stock librtlsdr tops out around 1.7-1.8 IIRC.
Thank-you. That worked for me. I have minus 42 PPM!
Thanks for the post. It didn’t work. I am building a Pi from the wheezy base and after a websearch for kalibrate, found a site outlining the necessary libraries.
My last Unix experience dates back to when Linus was a teen 
and relearning is an experience in itself. thanx again for the post
Fun to use in a Cell service deadspot.
joel
I’m also interested in an answer to the original question:
How can I do the same thing in PiAware’s init script? Is there a way to pass parameters, and if so, how?
What file/location do I edit in piaware to use the --ppm parameter?
In my case, I have a script in /etc/init.d called dump1090.sh The parameters are in there.
Thanks.
Found what appears to be the correct location in my /etc/init.d/fadump1090.sh under PROG_ARGS=
Can’t get it to compile. Getting:
pi@piaware /etc/init.d $ /usr/local/bin/kal -s GSM900 -e 56 -g 30
shmat: Invalid argument
terminate called after throwing an instance of ‘std::runtime_error’
what(): circular_buffer: shmat
Aborted
I’ve googled it. Can’t seem to find the definitive fix. Any advice?
J
There’s a specific way you need to make it. That error is caused because of the Pi ARM memory or something. I just ran into it today. I’ll try to find you the link in the morning.
kalibrate wouldn’t compile for me at first either. I am building it from the basic wheezy image and had not installed some libraries. I got a leg up on the missing libraries at the link below and successfully compiled it:
Use this to install it:
sudo apt-get install libtool autoconf automake libfftw3-dev
git clone https://github.com/asdil12/kalibrate-rtl.git
cd kalibrate-rtl
git checkout arm_memory
./bootstrap
./configure
make
sudo make install
Don’t bother trying to do the PCS network as it’s out of the range for the SDR and it will throw errors.
Thanks Joel… that worked…
Now… how long does it take for the calibration to run???
J
On a PC it’s a couple of minutes for the scan, less for the calibration run once you pick a channel.
I would expect it to be similar on a Pi. (Hmm, I wonder if the Pi can keep up with the FFTs needed for the power scan?)
You might want to run with -v, that should give you some progress info. IIRC it can go very slow if you pick a channel where the signal is too weak to be usable.
Thanks… had to shift to GSM850 to find something with high enough power.
Re: Pi scan time: down in a hole here in the hills, I usually get 2 out of 3 channels. Successive scans needed to pick all of them up take 2 - 3 min each. Seems that the offset differs among the channels, but consistent on each channel. I try to average all three.
Why wouldn’t the Pi be able to keep up? You know what the first F in FFT is?