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

Steve Rooke sar10538 at gmail.com
Tue Dec 30 05:11:06 UTC 2008


Björn,

Thanks for your response.

2008/12/30 Björn Gabrielsson <bg at lysator.liu.se>:
>
> On Tue, 2008-12-30 at 02:46 +1300, Steve Rooke wrote:
>
> Measuring is more fun than theoretical pondering... so start there. ;-)

Indeed, although in this case I am not measuring absolute time, I'm
just trying to sync a GPSDO.

> 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

Thanks for the link but I will just be deriving the PPS and running it
in on something like CD or so.

> 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.

I would not expect that the absolute time from my PPS would be highly
accurate for this purpose. Wouldn't the jitter be filtered out by a
low pass filter following the phase-frequency detector in a GPSDO
using the method I propose?

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

Sorry, this is off-topic for me.

> 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!

Thanks & 73,
Steve
-- 
Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW
Omnium finis imminet




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