[time-nuts] Deriving PPS from hockey-puck G-Mouse GPS receiver to lock an oscillator

Björn Gabrielsson bg at lysator.liu.se
Mon Dec 29 15:11:51 UTC 2008


On Tue, 2008-12-30 at 02:46 +1300, Steve Rooke wrote:
[...
> even with the gusty winds we have been experiencing here. Now I have
> looked at the output of these which from a reset state run at 4800bd
> and produce the requisite NMEA 0183 protocol as expected. Looking at
> the TTL output on a scope there is a burst of data, at 4800bd, each
> second with a reasonable gap between each burst. Each packet of data
> starts with a $GPGGA message and time-stamping these shows they seem
> to occur at 1 second intervals. What I was thinking about building was
> a small circuit which would switch on the start of the data block and
> then time out at the end of the block thereby producing a 1Hz signal,
> albeit not 50% duty cycle, which could possibly be used to lock a ocxo
> via a phase-frequency detector, like a MC4044, and a low pass filter.
> Has anyone looked at this before and, perhaps discarded it or
> whatever? Yes, I know it is no substitute for a Thunderbolt but I
> don't have one of those yet and this may be a cheap and cheerful way
> to sync to GPS.

Measuring is more fun than theoretical pondering... so start there. ;-)

Try to measure the jitter on that 1Hz signal. Either with "external"
hardware, or software. One way to do this is by configuring the GPS as a
refclock to a computer running NTP.

  http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html

When you have the computer running you can query NTP of what kind of
jitter it sees. Look at the last column in the query below. With a few
external network servers you can also estimate approximate delay or
offset. Both are in milliseconds below.

NOTE: The GENERIC clock here IS using PPS.

$ ntpq -c pe timehost.lysator.liu.se
     remote       refid    st t when poll reach   delay   offset  jitter
==============================================================================
*GENERIC(0)      .GPS.     0 l   64   64  377    0.000    0.001   0.002
+nissan.ifm.liu. .PPS.     1 u  644 1024  377    0.655   -0.009   0.033
+ntp1.sth.netnod .PPS.     1 u  593 1024  377    3.661   -0.037   0.053
+ntp2.gbg.netnod .PPS.     1 u  619 1024  377   10.967   -0.025   0.042
-ntp1.mmo.netnod .PPS.     1 u  623 1024  377   13.933   -0.097   0.050

Last time I tried a NMEA without PPS i got jitter of about 10ms. Delay
(offset) was a few hundred ms.

Why is NMEA probably the worst way to get time out of a generic GPS
receiver?  

The receiver has more important stuff to do than putting the first bit
of a long serial message on a slow 4800baud link exactly at the correct
time. If the receiver is busy tending to its correlator chip. Serial
output will have to wait.

There are often two serial protocols implemented in the receiver. A
binary format different for each manufacturer. Trimble has TSIP, SIRF
Binary etc. This require less CPU to generate than the ascii NMEA. The
binary protocol often has better timing.

The number of CPU cycles to compute a PVT solution is not constant. With
4 satelite measurements its quicker than with 12 SVs in view. 

If the NMEA output is the task with lowest priority in the receiver the
leading pulse timing accuracy will suffer. 

There are sometimes a short binary timing message that have better
specifications on jitter and offset. This would probably be an order of
magnitude better than NMEA. A real PPS would be another 3 or so
magnitudes better.

There are surely exceptions to the above arguments not to use straight
NMEA. Measuring the performance over some time of cause gives you the
best answer for your particular GPS.

good luck!

    Björn

> Be gentle Bruce :-)
> 
> 73, Steve





More information about the Time-nuts_lists.febo.com mailing list