I bought a job lot of Polstar G-Mouse receivers to play with. These use the Sony CXD2951GA-4 chipset which has a PPS output but this is not made available at the end of the cable unfortunately. The units themselves are fully waterproof so they are happy to sit through all kinds of weather outside and cling like limpets to a metal surface 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. Be gentle Bruce :-) 73, Steve -- Steve Rooke - ZL3TUV & G8KVD & JAKDTTNW Omnium finis imminet

Björn

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

Björn, Thanks for your response. 2008/12/30 Björn Gabrielsson <bg@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