[ntp:questions] YEA! My Sure Electronics GPS just arrived.

David J Taylor david-taylor at blueyonder.co.uk.invalid
Sat Mar 24 16:11:45 UTC 2012


"Ron Frazier (NTP)" <timekeepingntplist at c3energy.com> wrote in message 
news:4F6DDA72.30407 at c3energy.com...
[]
> Hi David,
>
> You appear to be up early.  I'm curious to know what time this email 
> says it arrived.  If it says it arrived at about 1030, then that's my 
> time.  If it says it arrived at about 14:30, then that's your time.

I am on UTC here, and the posting was made in the (very) early hours.

> Since I wrote that, it seems to have centered itself around zero.  I now 
> have a very nice + 1.2 ms / - 1.2 ms offset pattern.  Since I've been 
> struggling to get anything under 50 ms with other technology, this looks 
> really sweet to me.
>
> http://dl.dropbox.com/u/9879631/Sure%20board%20first%20night%20pt1.jpg
> http://dl.dropbox.com/u/9879631/Sure%20board%20first%20night%20pt2.jpg
>
> Conversion of these images to jpeg reduced the clarity a bit, but you 
> can still see what's happening.

I vaguely recall that USB has a polling interval of ~1 millisecond. 
Additionally, unless you use interpolation, Windows timestamping 
introduces a further  1 millisecond quantisation in its timestamps of the 
USB data (that 0.977 ms jitter is the signature of plain Windows 
timestamps), so your +/- 2 milliseconds max seems to be of the correct 
order

> MICROSECONDS, did you say?  I'm nowhere near that territory with 
> everything going through a serial - USB converter.  However, I'm quite 
> happy with 1.2 ms under the circumstances.

That millisecond polling is the limiting factor, go for a hardware serial 
port and the kernel-mode timestamping and you're an order or two better 
again.

> I am NOW assuming that my clock is more accurate than the internet 
> clocks.  I am NOW hoping that neither will appear to be drifting away 
> and that nothing in the system will be having routine heart attacks.

Fingers crossed.  For the reasons mentioned above you could be up to a 
couple of milliseconds out in absolute terms.

> I notice there is a difference between my clock and the average internet 
> clock reading.  Hypothetically, even though mine is probably closer to 
> UTC than those readings, if I wanted to shift my offset to match them, 
> so NTP won't clockhop, how as long as the GPS is working, how would I do 
> that?
>
> Here are my config lines:
>
> # COM5 57600 windows lines for testing gps selected as main source - 
> gpgga 57600 baud
> server 127.127.22.5                        minpoll 3 maxpoll 3 
> # PPS
> fudge  127.127.22.5 flag2 0      refid PPS 
> # PPS standard polarity
> server 127.127.20.5                 prefer minpoll 3 maxpoll 3 mode 66 
> # NMEA
> fudge  127.127.20.5 time2 0.0000 refid GPS1 
> # use WITH PPS
>
> Also, why doesn't the PPS show up in my status screen anywhere?  I know 
> it's working, based on the graphs.
>
> Sincerely,
>
> Ron

Check the driver configuration.

PPS requires the kernel-mode timestamping of the DCD line going active, 
and that's only available in Dave Hart's serial-pps driver/DLL.  For the 
same PPS timesamps in other drivers would require e.g. USB providers to 
update their drivers as well, which isn't at all likely to happen.  If you 
knew that the average delay between true start-of-second and your PC 
timestamping the USB/serial packet was 1.5 milliseconds, you could 
probably use something like:

  fudge  127.127.20.5 time2 0.0015 refid GPS1

Looking at your plot of peer offset, though, that might bring the best 
Internet server /nearer/ to zero offset.

BTW: you may find that PNG is a better format for saving graphics - except 
for the lines which are very "noisy" and would increase the file size. 
PNG is lossless, and can produce quite small files of plots.  That's one 
reason my program saves data in that format.

I'm delighted with your results so far.

Cheers,
David 



More information about the questions mailing list