[LinuxPPS] Garmin GPS18x - Jitter and adev lab measurements

[Kasper Pedersen]

Miroslav Lichvar wrote:
"Could you post the histogram on LinuxPPS list? I'd say most of the 18x
users (if not all) don't know what they have."

These are measurements on a Garmin GPS18x sitting indoors, the PPS fed 
to a 0.6ns resolution timer/counter. 

Jitter histogram: 

  http://n1.taur.dk/permanent/hist3.png

Most ticks have the same length, but some ticks are 61.25ns shorter or
longer. This is one clock cycle of the internal ~16MHz timer in the 18x,
and happens whenever the GPS18x decides that its clock is a bit ahead or
a bit behind, and needs to make an adjustment.

If you see more than 67ns jitter, it is not the GPS' fault.


Now for a bit of time nuttery:

  http://n1.taur.dk/permanent/adev3.png
  http://n1.taur.dk/permanent/adev3.plot 

There are two series in the image: One where the timer/counter is run
off of its internal TCXO, and one using a FE-5680A Rb standard.

If your adev is above the red line, it is not the GPS' fault.
The 18x is well behaved.

(For those not used to adev plots: A GPS has poor short term stability,
but good long term stability, and this produces a downward slope. A
crystal oscillator has good short term stability, but poor long term
stability, and this produces an upward slope. The adev plot shows the 
sum of the two, and becomes V-shaped. So if we wish to measure the GPS, 
we need an oscillator that is more stable. An Rb is much more stable, 
but it too must yield to the gps at long tau.)


Plotted as timestamps:

  http://n1.taur.dk/permanent/gpst3.png

A note about this plot: 100ns/38000s is 2*10^-12. This is far better
than the spec on the Rb, so the wander is likely the Rb's fault.


Absolute time offset:

I have measured it to be 60ns+/-100ns slow relative to UTC. 
(The offset I measure is less than the uncertainty I have on UTC 
measurement. The 60ns figure is compensated for cable length.)


/Kasper Pedersen