[ntp:hackers] Drift of position with NTP/GPS.

Poul-Henning Kamp phk at phk.freebsd.dk
Wed Oct 8 18:30:14 UTC 2008

In message <200810081806.m98I6bMJ031735 at deneb.dwf.com>, Reg Clemens writes:

>I recently drug out that graphics program (I was recompiling the graphics 
>it depends on and wanted to see that it still worked) and have let it run for 
>two days.
>I find that my position has changed. The changes are 2-3m in each of the three
>directions, viz:
>	dLat = -3.202m
>	dLon =  3.255m
>	dHt  =  2.217m

There are places on the earth that move so fast, but I doubt you live 
there :-)

In general, the GPS signals have gotten a lot better over the last
four or five years, and that could simply be the reason: you get a
better fix now.

I spent some time trying to figure out what effects a slightly wrong
pos-hold position have on timing, to see if I could use that as a
way to improve the position.

In general, pos-hold position offsets show up as two-tone harmonic
signals with 1day and 12 hour periods, which I attribute to the
time/space varying range errors to the satellites.

Unfortunately, at my lattitude (56N), there are no usable satelites
north of me, so the math got pretty lop-sided and the uncertainties
rather unweildy.

These kinds of experiments would be much easier to carry out close
to the equator, but just 20 deg south of here should do wonders.

My results was inconclusive: I could improve performance for a few
days, but then the pattern would drift and I would have to optimize
the position again.

I attribute this to the fact that we are down in the range of the
basic stability of the GPS constellation, as received on the ground,
so that both satellite operation and ionosperic changes on a weekly
scale affect the result.

If you want to play with this, you need a reference frequency source
that is really stable on the day-week domain, in other words, a
free-running cesium, and then you basically try to shift the pos-hold
position a bit forth an back, trying to minimize the square of the
frequency offset corrected time-offset between the gps and the Cs.

If you want to get really evil, you start to look at the per-sat
residuals which the oncore reports, and that sat's position on the
sky and make educated guesses based on that.  Start out by plotting
the residuals versus alt/azi of the sat and see if you can spot
a trend.  The change coords 1 meter to one side, see how the pattern
changes, then change in another direction.  Repeat until happy.

I had some partial success with that, but didn't have time to keep
fiddling with it, and again the "no birds to the north" made my
variances pretty big.

I think it should be possible to write code that in the longish
term automatically would integrate these residuals and generate
small corrections to the pos-hold coords, to improve the day-ish


Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

More information about the hackers mailing list