Björn, Thanks for your response.
2008/12/30 Björn Gabrielsson <[email protected]>: > > 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 _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
