David J Taylor wrote:
"David Lord" <sn...@lordynet.org> wrote in message
news:mhpbh7-ug9....@p4x2400c.home.lordynet.org...
[]
The serial RX data for my Garmin seems to have an offset > 500ms
and also vary by at least 20ms. Once PPS synchronises the GPS
offset comes more or less in line with PPS but unless that fudge
time is used PPS will never be used. That was a known problem
that has been fixed but not yet made it to NetBSD I use.
Strange, I've never seen that problem with the smaller serial offset in
the GPS-18 LVC, and I have had to add no fudge lines for either:
GPS-18 LVC on:
FreeBSD 5.4, type 20 ref.clock, NTP version - as supplied ~2006
FreeBSD 8.0, type 20 ref.clock, NTP version - as supplied: 4.2.4p5-a (1)
Windows, type 20 ref.clock, NTP version 4.2.6-o Dec 09
GPS-18x LVC on:
Windows-7, type 20 ref.clock, NTP version 4.2.6p2-RC5
PPS seems to come up more or less at the same time as GPS, even without
a ~200ms or 500ms+ offset being coded in the config file.
I wonder what the specification is for the NTP ref.clock drivers, in
terms of maximum delay of serial data compared to the PPS signal?
When I first tried parallel port PPS I had to google and
unusually it didn't take much searching to find a bug report
and that the issue was fixed in later versions of ntpd.
I think it was [1238] fixed in ntpd-4.2.6
The problem shows when the pps comes from another source,
eg. gps2 and pps0 and the absence of serial DCD to gps2.
The fix by adding a fudge time1 is messy because it depends
on the particular nmea sentences but so long as GPS is fudged
to 30ms or so of the other servers the PPS kicks in ok.
I've not found it possible to compile a more recent ntpd
(4.2.6p1-RC4) on NetBSD as there seems to be many changes
and a lot of magic required. I might download 4.2.4p6-o
and see how the NetBSD version differs.
David
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
