GPS clock accuracy
Hal Murray
using the PPS/ATOM driver. They differ by about 20 microseconds.
Is there any way to find out how accurate a GPS unit is at the
microsecond level short of carrying it to someplace with a better
clock?
Has anybody done that with either the GPSClock 200 or HP Z3801a?
Is there much unit-to-unit variation within a particular model?
PS: Many thanks to Jeff Mock for his heads up about the HP Z3801A
and patches to the HP driver.
--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
David Schwartz
> I now have two GPS/PPS units plugged into the same PC. They are both
> using the PPS/ATOM driver. They differ by about 20 microseconds.
>
> Is there any way to find out how accurate a GPS unit is at the
> microsecond level short of carrying it to someplace with a better
> clock?
>
> Has anybody done that with either the GPSClock 200 or HP Z3801a?
>
> Is there much unit-to-unit variation within a particular model?
>
> PS: Many thanks to Jeff Mock for his heads up about the HP Z3801A
> and patches to the HP driver.
3 years ago, I confirmed the GPSClock 200's accuracy to be +/- 3
microseconds or better once calibrated (in other words, I'm testing
repeatability, not absolute accuracy). This test was over a period of
two weeks and does not count data points when fewer than 4 satellites
were in view. (Which I think worked out to be about 12 minutes out of
those 3 weeks.)
I tested a single unit and later quickly tested about 5 more. (I used
to sell the GPSClock 200.) I confirmed that these five were within 5
microseconds of the unit I tested more thoroughly (after a two hour warm
up / lock in).
The manufacturer of the GPS board inside (Furuno) claims +/- 1 uS, and
I have no reason to doubt that claim. I don't have sufficiently accurate
equipment to verify it though. The GPSClock 200 has a command you can
use to advance/delay the PPS pulse. If you have access to a very
accurate calibrated PPS pulse, you can work out the correct
advance/delay for your unit and cable lengths.
You should definitely get 10uS absolute accuracy out of the box with no
calibration.
You may want to look at the offset between the two units with an
oscilloscope. The problem may be that one of the signals is rising too
slowly due to poor interfacing or excessive loading. A buffer might
help. If they sync better on an oscilloscope when disconnected from the
PC than when connected, this is definitely your problem.
One issue with the GPSClock 200, due to its 'board in the box on the
end of a cable' design, can be long lines with significant resistance
connecting to a PC serial port with high capacitance. While the GPSClock
200 attempts to transition the PPS line at the right time, it takes
quite some time for the voltage to be seen at the other end as the RS232
line driver has to charge a capacitor (the receiver) through a resistor
(the wire).
Generally this is repeatable, and so it results in a fixed offset
rather than increased jitter. One solution is to measure it and
compensate either in the PPS driver (fudge) or by changing the
GPSClock's offset parameter.
I'll try to find the calibration procedure for you and post it as a
reply to this messaage. I don't have it handy now.
DS
David Schwartz
> I'll try to find the calibration procedure for you and post it as a
> reply to this messaage. I don't have it handy now.
The calibration procedure is documented in the manual, although only
briefly. Basically, you use the '$PFEC,GPset,Tsnnnn' command where 's'
is a + or - and 'nnnn' is the PPS correction in .1uS increments.
Negative numbers advance the PPS pulse while positive numbers delay it.
You need to correct for your cable distance (.1uS per 100 feet or so)
and for any risetime delay caused by cable length and receiver
capacitance. My bet is that if you're seeing late PPS pulses from the
200, it's because of wire resistance and input capacitance.
If you're using the standard GPSClock 200 driver for NTP, you can
configure it to send a command to the clock on startup. Just add a
'GPset' line after the existing 'GPint' line.
I regret not mentioning this in my initial draft of the manual. Frank,
if you're reading this, take note.
DS
Hal Murray
>end of a cable' design, can be long lines with significant resistance
>connecting to a PC serial port with high capacitance. While the GPSClock
>200 attempts to transition the PPS line at the right time, it takes
>quite some time for the voltage to be seen at the other end as the RS232
>line driver has to charge a capacitor (the receiver) through a resistor
>(the wire).
Thanks.
I guess I'll get out the scope tomorrow. 20 microseconds is
a long time. I'm using the normal 50 ft cable.
I expect most of the resistance is internal to the driver chip
rather than in the cable.
I had a good digital scope on one a while ago. If I triggered on one
PPS pulse and looked at the next one, it was off by 12 microseconds.
That is the osc in the scope was off by 12 ppm, and the signal was
clean enough that it was easy to measure.
David L. Mills
Once upon a time long ago the calibrate procedure for a GPS receiver was
to take it to one of many surveyor's monuments, which are in most cases
obelisks stuck in the ground in and previously accurately surveyed.
There are about fifty along the Mason Dixon line in this state, a few
less than a couple miles from my house.
More recently I calibrated my several GPS receivers via a portable
cesium clock. I equipped my wife's van with a 110-V inverter and the
clock with 20-minute batteries. Once every few months she would drive to
USNO in Washington and synchronize it to the USNO cesium herd. Upon
return I squeezed out the nanoseconds on my herd. I assumed the USNO lab
tech accounted for the cable delay at his end.
Over time I gained confidence that the GPS herd were getting better to
the point that a PPS from a good GPS timing receiver was better than the
cesium, at least over several months. One by one the tubes in my cesium
herd used up their atoms and were retired. Replacement tubes are too
expensive. Now, I keep the GPS herd in line by comparing GPS to GPS and
correcting for cable delays. More precisely, and accounting for velocity
factor, the cable delay is close to 0.7 nanosecond per foot.
As for 20 microseconds, yike! I get bent if mine differ more than 100
nanoseconds. What can I tell you? The jitter with the FreeBSD nanokernel
and parallel port on ISA bus is two microseconds.
Dave
Hans Jørgen Jakobsen
>
> I guess I'll get out the scope tomorrow. 20 microseconds is
> a long time. I'm using the normal 50 ft cable.
Could it be that 20 microseconds is the time it takes to handle
an interrupt? If you have 1 cpu only one interrupt can be
handled at a time.
/hjj
Hal Murray
>using the PPS/ATOM driver. They differ by about 20 microseconds.
Scopes are good.
The problem turned out to be that I was triggering on the wrong
edge of the PPS signal from the HP Z3801A. That PPS signal is
a 20 uSec pulse rather than a square wave. (Very suspicious
as soon as I got a scope on it.) If you trigger on the wrong
edge it's not off far enough to notice with normal sanity checks.
With flag2 turned on they now differ by about 5 microseconds
in the other direction.
That's a bit strange since I'd expect about a 1 microsecond offset
in the initial direction due to slow fall time. The Z3801A is
using a RS232 driver - slew rate limited to 1 or 2 uSec. The
GPSClock 200 uses a TTL/CMOS signal. Rise time is hard to see
with my old analog scope.
I swapped the TTY ports to see if the order of scanning made
any difference. If there was a change, it's not significant.
Anybody know how long it takes to do the work in the interrupt
handler? (I suppose I could wire the same signal up to two
ports.) I'm running Linux on a 566 MHz Celeron, 66 MHz front
side bus. 5 microseconds is the right ballpark, but it seems
a bit high to me. (But my head is probably calibrated to
newer/faster machines.)
Maybe I'll go back to using the wrong side of the pulse and
fudge the offset back where it belongs.
Hal Murray
>Once upon a time long ago the calibrate procedure for a GPS receiver was
>to take it to one of many surveyor's monuments, which are in most cases
>obelisks stuck in the ground in and previously accurately surveyed.
>There are about fifty along the Mason Dixon line in this state, a few
>less than a couple miles from my house.
I work near the USGS Menlo Park campus. I'll have to ask where
the local reference point is. They should have a good one nearby.
Does that help calibrate time too? If so, how?
>More recently I calibrated my several GPS receivers via a portable
>cesium clock. I equipped my wife's van with a 110-V inverter and the
>clock with 20-minute batteries. Once every few months she would drive to
>USNO in Washington and synchronize it to the USNO cesium herd. Upon
>return I squeezed out the nanoseconds on my herd. I assumed the USNO lab
>tech accounted for the cable delay at his end.
How far did your herd drift over a few months?
How long does it take to calibrate a clock? Almost sounds like
they should leave a cable hanging near a reserved parking spot.
>Over time I gained confidence that the GPS herd were getting better to
>the point that a PPS from a good GPS timing receiver was better than the
>cesium, at least over several months. One by one the tubes in my cesium
>herd used up their atoms and were retired. Replacement tubes are too
>expensive. Now, I keep the GPS herd in line by comparing GPS to GPS and
>correcting for cable delays. More precisely, and accounting for velocity
>factor, the cable delay is close to 0.7 nanosecond per foot.
I've only got 50 ft of cable on each setup. Looks like a lot of work
left until I get to where that matters.
Has anybody done any work on correcting for interrupt latency?
>As for 20 microseconds, yike! I get bent if mine differ more than 100
>nanoseconds. What can I tell you? The jitter with the FreeBSD nanokernel
>and parallel port on ISA bus is two microseconds.
I assume you are measuring the difference with a scope.
Two microseconds of jitter seems like a reasonable ballpark.
How fast a machine? How much other interrupt activity?
David L. Mills
My experience is that, if the GPS receiver has an accurate geographic
fix, its time is accurate, too. Yes, I know that some receivers are
optimized for navigation, others for timing. But, my experience is that
an accurate fix using either type results in the best time.
Dave
David L. Mills
The PPS API has provisions to toggle a parallel port bit at the on-time
epoch. Assuming Linux has not lost that wrinkle, which works in FreeBSD,
trigger your scope on the PPS and watch the pin. Last I noted the
interrupt time was about 20 us on a Sun IPC with SunOS(!). A quick trip
through the kernel on a Blade 1000 is about 400 ns, so I expect the
interrupt time to be consistent with that.
For comparison, my Blade with Solaris 8 shows nominal jitter with ntpq
about 8 microseconds. Not too trashy.
Dave
John Ackermann N8UR
>I now have two GPS/PPS units plugged into the same PC. They are both
>using the PPS/ATOM driver. They differ by about 20 microseconds.
>
>Is there any way to find out how accurate a GPS unit is at the
>microsecond level short of carrying it to someplace with a better
>clock?
>
>Has anybody done that with either the GPSClock 200 or HP Z3801a?
There is quite a herd of experimenters (mainly ham radio operators) playing
with the surplus Z3801As that are showing up all over the place. I'm at work
so don't have all the URLs handy, but at my own website --
http://www.febo.com/time-freq/gps -- there are links to:
(a) a page with all sorts of good info on the Z3801A;
(b) a Windows program called GPSCon that plots data from the Z3801A serial
port and lets you see the performance of the oscillator 1pps versus the
"filtered" (don't know the filter params) GPS 1pps, the current EFC setting,
and the predicted uncertainty; and
(c) a perl script I wrote for Linux (should work on other platforms) to log
the same kind of data to a disk file. I'm also working on an automated way to
creates graphs from the data, but that's not working yet.
A couple of comments on all this:
1. The 1pps output that is available on the Z3801A DB-25 connector is *not*
at RS-232 level but instead uses a "PECL" interface that is designed to move
fast signals over long cables. Problem is that it's a low voltage
differential signal that's hard to do much with -- even observe on a scope.
It also has a very short pulselength -- something like 20us. There have been
a couple of web articles published about generating a more useful 1PPS signal.
2. I'm not sure how much to make of the time difference data reported by the
Z3801A. While it's interesting to look at the plot, which typically shows
noise in the range of 20 nanoseconds or so with occasional bursts to 50 or
even 100 nanoseconds, I'm not sure how you differentiate oscillator drift from
GPS noise, given that the oscillator is being actively steered by the unit.
If you look at the plots on my page, you see a couple of spikes where the
EFC value is clearly tracking a temporary phase shift. I don't really
know whether that's a good or a bad thing.
More interesting will be to measure the Z3801A output against a Cesium, or
failing that (since I don't have a Cesium in the basement... yet), compare two
Z3801As and hope that the stability of one is in fact the square root of the
two measured against each other.
John Ackermann
j...@febo.com
Dave Perks
> I guess I'll get out the scope tomorrow. 20 microseconds is
> a long time..
If I calculate correctly one of the GPS units would be about 6 km wrong
with its position!
Hal Murray
>with the surplus Z3801As that are showing up all over the place. I'm at work
>so don't have all the URLs handy, but at my own website --
>http://www.febo.com/time-freq/gps -- there are links to:
Thanks. Another for the the bookmark collection.
>(c) a perl script I wrote for Linux (should work on other platforms) to log
>the same kind of data to a disk file. I'm also working on an automated way to
>creates graphs from the data, but that's not working yet.
Does your script work while ntpd is using the Z3801A?
I hacked the HP driver to add one more line to the clockstats file
containing all (most of?) the info I was interested in. (email me
for details if anybody is interested.)
>A couple of comments on all this:
>
>1. The 1pps output that is available on the Z3801A DB-25 connector is *not*
>at RS-232 level but instead uses a "PECL" interface that is designed to move
>fast signals over long cables. Problem is that it's a low voltage
>differential signal that's hard to do much with -- even observe on a scope.
>It also has a very short pulselength -- something like 20us. There have been
>a couple of web articles published about generating a more useful 1PPS signal.
Yup. Specs say PECL. I haven't checked with a scope. 20 uSec is what I saw
on the scope. Works OK if you use the correct edge.
Jeff Mock's recipe includes using a section in the RS232 level shifter
for the PPS signal. I avoided his cut on the PCB by using an unused pin on
the DB25. Since I was already making a home-brew DB25 to DB9 adapter it was
easy to customize it to use a strange pin.
Hal Murray
>with its position!
Sounds about right. :)
I setup the GPSClock 200 to send both the $GPRMC and $GPGGA messages
every minute. I hacked the NMEA driver to save both in the clockstats
file. A few scripts lets you graph the number of satellites and it's
(claimed) position and ...
If I graph the reported lat/long vs the "average", I'm occasionally off
more than 150 ft. Most of the time it's much better than that.
That's in my home with the antenna inside my junk/spare/computer room.
It runs out of satellites (un)reasonably often. Usually a couple of times
per day.
At work with the antenna outside and a good sky view, it's rarely off
more than 75 ft, and rarely runs out of satellites.
I spent some time trying to sanity check the lat/long it prints out
with a USGS topo map. I think it agrees in the 100 yard range. I'm
not sure I would bet much on closer than that. That's getting down to
the range I can read the map and/or correct for coordinate quirks.
My script says the average is:
LAT=3726.0869
LONG=12212.2000
I think the units are degress*100 plus minutes and fractions of a minute.
Might be 2 digits and fraction of seconds to the right of the decimal point.
[I live in west Menlo Park if anybody wants to sanity check that.]
The Z3801A discovers it's lat/long via a "survey" dance. I haven't
gone through the exercise of checking the numbers, partly because I
don't know which coordinate system it is using. (The 1927 vs 1983? is
off by 100 ft or 100 yards in this area.)
HP Z3801A says:
N,+37,+26,+4.89000E+000 W,+122,+12,+1.56280E+001 +3.94200E+001
I think the units are degress, min, sec.
Last number is elevation in meters.
John Ackermann N8UR
>>http://www.febo.com/time-freq/gps -- there are links to:
>
>Thanks. Another for the the bookmark collection.
>
>>(c) a perl script I wrote for Linux (should work on other platforms) to log
>>the same kind of data to a disk file. I'm also working on an automated way to
>
>>creates graphs from the data, but that's not working yet.
>
>Does your script work while ntpd is using the Z3801A?
Probably not, since it needs to poll the receiver to get the data. At
present, I'm using my Z3801As only for their 10MHz frequency standard output;
I use a bare Oncore receiver for ntp.
John