[LinuxPPS] Experience with current linuxPPS kernel patch.

[Bernhard Schiffner]

Am Donnerstag, 4. März 2010 15:13:20 schrieb Miroslav Lichvar:
> On Thu, Mar 04, 2010 at 01:47:31PM +0100, Bernhard Schiffner wrote:
> > Am Donnerstag, 4. März 2010 12:51:38 schrieb Miroslav Lichvar:
> > > I'm using GPS 18x LVC and I'm seeing about 1us dispersion too. But the
> > > specs say it's accurate only to 1 us, so I'm not sure if I can expect
> > > anything better from it.
> >
> > It's difficult to state, what's the reason.
> > Most receivers use a programmable counter to form the PPS-signal and keep
> > it aligned to the sky-segment. (Divide by x normaly and by x+/-1 in case
> > of a correction). Maximum possible accuracy here is one cycle of the
> > GPS-"CPU"- Clock. In my case this is about 10 MHz resulting in a
> > "regular" 100 ns jitter of PPS. But this is a case where developers paid
> > attention on these details. It's possible to be far worse (use of 16 bit
> > counters only etc.).
> 
> I've read somewhere that a limit for GPS receivers is around 150ns,
> unless it has its own OXCO where it can go to low nanoseconds.
Depends on the hardware. I think with state of art: 100ps, locked to the clock 
and their phase of the GPS satellites.

> If the high jitter was caused by too low frequency of the GPS chip or
> bad implementation, maybe it would be visible in offset distribution
> plot as an abnormality?
> 
> For last 120000 samples I'm seeing this:
> http://fedorapeople.org/~mlichvar/tmp/18xlvc_errdist.png
Yes, it should.
Think of your counter having an input of 5MHz. The factor to divide is 
5,000,000 (full programable 24 bit divider). But there is always a little 
offset. Let's say 5MHz+0,5Hz. Up from a perfect start the second pulse will be 
earlier (1s-100ns) the 3rd 2s-200ns and so on. Now (hopefully) the internal 
software recognizes the drift and corrects the timing by changing the divider 
a single time to 5,000,001. Next pulse will be later (3s-0ns).
So most pulses are wrong in the span given by clock, divider and software.

This is true even in a perfect environment, in reality it can be much more 
worse.
(Some receivers provide a pps signal even if there is _no_ satelite visible at 
all ...)

It's not impossible that you see this (a 200 ns Jitter by the receiver) at the 
center of your graph. BUT: Everything else must work perfectly to make a 
trustable statement.

> > The only way to state, what's kernel and what's GPS is to compare pulses
> > by scope or counter to a _good_ local quartz.
> 
> Unfortunately I don't have access to such equipment.
> 
> > Other question: How close to (a half sphere's) 2Pi angle does your GPS
> > antenna see the sky?
> > (If it's only 1Pi as from a normal window, 1µs is very good.)
> 
> It's only half of the sky. gpsd reports that 9 satellites are visible
> and 8 are used. In the specs the 1us accuracy actually seems like an
> upper bound:
> 
> 1us accuracy for all conditions in which the GPS 18x LVC or GPS
> 18x-5Hz has reported a valid and accurate position fix for at least
> the previous 4 seconds.
Measured with 2Pi (open) sky: ok, no rocket sience at all:

http://www.hochschule-bochum.de/fbv/messtechnik/gps-referenzstation.html

(They state about cm/sub-ns accuray, I'am interested what they do about their 
building. It heats up, moves by wind, vibrates . "Solid" earth has 2 dayly 
tides in cm region too ...)

1µs equals to 1000ft (300m) because of the speed of light.
Check your position reports. The error of position is in its origin an error 
in time. That means if your reported position "moves" 1000ft (3D!) there 
_must_ be a timing-problem of 1 µs. 
(Ok, this takes longer times. But no: with 1Pi sky your position is for sure 
_not_ in the middle.)


Bernhard