[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