[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