[time-nuts] Low cost GPS gadgets for timing

Russell Rezaian rrezaian at motorola.com
Wed May 6 15:47:37 UTC 2009


Hi Hal,

I can't offer much in the way of recommendations for GPS receivers, 
but I have been doing some experimentation just lately with USB 
serial devices for serial time code to NTP.

I'd be very interested in comparing results!

So far I've been using reasonably decent GPS clocks and a USB serial 
port adapter, not the cheap USB GPS pucks.  I've been meaning to pick 
up one of the cheap pucks for comparison too, but haven't got that 
point.

So far I have noticed that I can get a pretty decent notion of the 
constant offset just using the NTP calibrate mode.

The random jitter is pretty noticeable too, but I've been surprised 
by how mild it can be in more "ideal" circumstances.  I was expecting 
much worse.

I have two systems I am testing on, one ancient slow system that's 
VERY busy (I use it as a main desktop for day to day use, and I can 
routinely peg the CPU for minutes at a time).  And one much newer 
dual core laptop that pretty much sits doing only NTP.  Yes I know 
it's odd to use the older laptop for my day to day work, and leave 
the newer one idle, but still use a lot of old software so...

Anyway, here's a little data:

Three random data points from the fast system, lowest jitter:

ntpq> peers
      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.1.90    .GPS.            1 u   66  128  377    0.529    0.061   0.068
+192.168.1.95    .GPS.            1 u  104  128  377    0.454    0.101   0.108
+192.168.1.101   .GPS.            1 u   76  128  377    0.557    0.053   0.065
+192.168.1.102   .GPS.            1 u   11  128  377    0.553    0.039   0.042
+192.168.1.103   .GPS.            1 u   78  128  377    0.523    0.024   0.049
-TRUETIME(0)     .GPS.            1 l   35   64  377    0.000   -0.437   0.537
ntpq> peers
      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-192.168.1.90    .GPS.            1 u   73  128  377    0.610    0.001   0.016
-192.168.1.95    .GPS.            1 u    1  128  377    0.585    0.007   0.016
+192.168.1.101   .GPS.            1 u   95  128  377    0.546    0.058   0.043
*192.168.1.102   .GPS.            1 u   22  128  377    0.574    0.036   0.024
+192.168.1.103   .GPS.            1 u   91  128  377    0.506    0.026   0.028
-TRUETIME(0)     .GPS.            1 l   24   64  377    0.000    0.233   0.360
ntpq> peers
      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-192.168.1.90    .GPS.            1 u   50  128  377    0.638    0.013   0.024
*192.168.1.95    .GPS.            1 u   97  128  377    0.575    0.051   0.041
-192.168.1.101   .GPS.            1 u   70  128  377    0.503    0.083   0.067
+192.168.1.102   .GPS.            1 u    1  128  377    0.623    0.022   0.015
-192.168.1.103   .GPS.            1 u   61  128  377    0.626   -0.011   0.020
-TRUETIME(0)     .GPS.            1 l   62   64  377    0.000    0.064   0.287
ntpq>

Most of the clocks run fairly close.  The serial time code swings 
much more wildly than the direct Ethernet connections.  Despite the 
much larger bounce, it still usually stays in sync with everything 
else within a swing of a millisecond or so.

On my other slower system the USB handling is much sloppier, no doubt 
due to the system being slower, older, busier and so on.  Don't read 
too much into this, the system below is NOT a perfect comparison.  I 
just threw it in to show that USB can be very seriously impacted by 
what else is going on with the system...  A busy system with more USB 
devices will degrade really badly compared to the gentler test case.

ntpq> peers
      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+192.168.1.90    .GPS.            1 u   89  128  377    0.545    0.055   0.059
+192.168.1.95    .GPS.            1 u  103  128  377    0.540    0.051   0.046
+192.168.1.100   .GPS.            1 u   98  128  377    0.422    0.042   0.031
*192.168.1.101   .GPS.            1 u    1  128  377    0.415   -0.003   0.043
+192.168.1.102   .GPS.            1 u   97  128  377    0.453   -0.011   0.038
+192.168.1.103   .GPS.            1 u  107  128  377    0.374    0.021   0.039
xTRUETIME(0)     .GPS.            1 l   57   64  377    0.000  -23.338  21.204
ntpq> peers
      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+192.168.1.90    .GPS.            1 u    2  128  377    0.555   -0.036   0.031
*192.168.1.95    .GPS.            1 u   23  128  377    0.503   -0.055   0.028
+192.168.1.100   .GPS.            1 u    2  128  377    0.437   -0.085   0.024
+192.168.1.101   .GPS.            1 u    1  128  377    0.439   -0.086   0.040
+192.168.1.102   .GPS.            1 u  107  128  377    0.439   -0.015   0.238
+192.168.1.103   .GPS.            1 u   14  128  377    0.451   -0.093   0.026
-TRUETIME(0)     .GPS.            1 l   51   64  377    0.000    0.779   0.431
ntpq>

Both systems have similar overall offsets for the USB service and 
handling time.  I am NOT using any special line disciplines, nor have 
I connected the PPS.  This is just plain serial time code.

I've been collecting NTP stats too, so when I have some time I will 
try to generate some pretty graphs.
--
Russell

At 3:24 AM -0700 2009/05/06, Hal Murray wrote:
>I'm looking for low cost GPS gadgets that are good for time keeping via ntpd.
>
>Any suggestions?
>
>I'm interested in not-so-good timing as well as the good stuff that attracts
>time-nuts.  As long as it's low cost.
>
>USB doesn't support PPS and it has a bad reputation because it's polled.  But
>the polling is done in hardware with a 1 ms time scale.  It won't be great,
>but for lots of uses it's good enough.
>
>The problem is that most of the low-cost GPS toys use the SiRF chip set.  It
>sucks for timing.  It looks like the NMEA sentences are sent from a timer
>with 100 ms ticks.
>   http://www.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif
>
>The Garmin GPS 18 LVC used to be popular.  It's been replaced by the GPS 18x
>which is much more sensitive.  Unfortunately, the timing went way downhill.
>   http://www.megapathdsl.net/~hmurray/ntp/GPS18LVCx-off.gif
>
>Anybody know how well the u-Blox chips work?  Are they used in any low cost
>units?  (USB ok.)
>
>
>Just to make sure we are on the same wavelength.  I don't care about a
>constant offset.  I can easily correct for that.  It's the jitter that I
>don't like.  The time scale is wrong.  It wanders too slowly.  I can't filter
>it out.
>
>
>
>--
>These are my opinions, not necessarily my employer's.  I hate spam.
>
>
>
>
>_______________________________________________
>time-nuts mailing list -- time-nuts at febo.com
>To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>and follow the instructions there.


More information about the time-nuts mailing list