[time-nuts] Position accuracy and Thunderbolt performance

Poul-Henning Kamp phk at phk.freebsd.dk
Sun Jul 26 21:28:28 UTC 2009


In message <BLU125-W29155884599C7E38CB3A21CE170 at phx.gbl>, Mark Sims writes:

>But,  the key word is most.  Some were off over 50 feet lat/lon
>and 100 meters altitude.  Unless you have a known position to compare
>against you may never know for sure.  [...]

Actually, you will, if you monitor the per-sat time residuals
from the GPS.

A couple of years ago, I got to play around with 10 M12M's during
a burn-in test, and managed to get some hacked up code to improve
the pos-hold coords, while staying in pos-hold mode.

The basic trick is to project the per-sat time residuals onto their
hemispherical coords (alt+azi) and determine if there is a net E/W
or N/S imbalance.

The E/W direction worked great simply by comparing the eastern to
the western hemisphere and moving the pos-hold longitude accordingly.

It is easy to see that if your pos-hold longitude is too far east,
sats west of you will have a slightly longer signal path making
their signals arrive a little too late, and vice versa.

To test my hacked up code, I would intentionally give it a bogus
pos-hold to start with, and over a month it would edge onto the
right longitude.  It can probably be tuned to be much faster.

I never got the N/S direction working to my satisfaction, because
at 55°N, I have no usable sats north of my antenna, and I never
found a good way to do the N/S imbalance with only data for southern
half the plane.

And then I had to deliver the NTP servers and never got around
to play with it again...

It should be possible however, because the residuals vary strongly
with altitude: almost no effect on a sat right overhead, big effect
on sats near horizon (think: basic triangle geometry).

Some details at: http://phk.freebsd.dk/raga/sneak/

The above observation gave me another idea which I didn't get to
play with, so I don't know if it will work:

If your pos-hold is not correct, your time solution will jump
whenever a sat is added/deleted from the solution.  It may be
possible to detect the sign of these jumps, by monitoring the per-sat
residuals, and use it to twist the pos-hold coords without the
tedious detour over mapping and balancing hemispheres.

It is important to not be fooled by near-horizon artifacts, so
a high mask-angle is probably required for this to work.

Somebody[tm] should really pick up this idea...

Poul-Henning

-- 
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 Time-nuts_lists.febo.com mailing list