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