|
|
GPS 18x LVC firmware version issueIf you are using a Garmin GPS 18x LVC, be sure to use firmware version 3.70 or later, as there is a problem with some earlier versions of the firmware where the NMEA data can be more that one second late compared to the PPS pulse, and hence present the incorrect time information to NTP. The problem, my flawed attempts to analyse it, and a working solution are described below. Be sure that your GPS 18x LVC is using the 3.70 or 3.90 firmware. As Garmin no longer provide a download for the 3.70 and 3.90 firmware, and as I have had reports that the 4.00 firmware re-introduced the problems fixed by 3.70 and 3.90, I am hosting the known working versions here.
The problemIn September 2010 I noticed that the
offset plot from the Windows system fed by the GPS 18x LVC had developed periods
of very poor synchronisation. Although I initially thought that some
software update must have been responsible, I could reproduce the problem on
another completely different system with the same GPS 18x LVC puck, so I
concluded the problem must be in the puck. At this stage I found that the
firmware was out of date, so I updated the firmware and it appeared to solve the
problem. Update - 3.60 firmware
Update - 3.70 firmwareGarmin did fix the problem after a number of us wrote to Garmin and explained the issue and its undesirable effects and, after some time, they updated the firmware to 3.70 which resolves the problem. You can download the current Garmin firmware here.
Update - 3.90 firmwareIn late August 2013, Garmin updated the firmware once again to
3.90 (there was a 3.80 update but I didn't apply that). Kiwi Geoff was
again kind enough to supply some measurements with the 3.90 firmware which show,
in essence, minimal change from 3.70 and no sign of the earlier timing problem. "Here is a quick comparison between version 3.70 and the (new) 3.90 firmware. The following times are the delay of the serial data with respect leading edge of the 1PPS, measured every second for 24 hours, thus 86,400 samples.
"The new (3.90) version has a similar latency to version 3.70 and thankfully not back to the bad old days of crossing second epoch boundaries!"
(Flawed) Analysis of the problem, and possible resolutionWith some help from Dave Hart and Hal Murray, I have been analysing this problem, and searching for a possible solution. The details below are for a Windows implementation, as that's the PC where I have the GPS 18x LVC attached, but the principles apply equally to other operating systems. Please note that I have since discovered that the +1.000s given below is due to the way the Windows implementation timestamps the sentences using the PPS pulse. The general idea of only using the PPS signal is valid, but not of measuring the offset as described here, unfortunately. The simplest resolution is to use a different source for the "seconds" part of time, while retaining the PPS signal for the precision part of the timing. You can do this simply by commenting out the NMEA driver (type 20) and leaving the ATOM driver (type 22), and marking another source as "prefer". So you may end up with your ntp.conf looking a little like the following. This works well on my Windows PC Stamsund. # NMEA ref-clock driver commented out # server 127.127.20.1 minpoll 4 prefer mode 33 # 19200bps, NMEA serial port # PPS/ATOM driver server 127.127.22.1 minpoll 4 # PPS - serialpps.sys # Use specific NTP servers server a.b.c.d iburst prefer However, it is also possible to measure the apparent offset of the NMEA signal as perceived by NTP, by adding the NMEA device back into the ntp.conf, but with a noselect qualifier. The means that the device will be monitored but not used for timekeeping. The offset data is collected in the peerstats statistics, so those need to be enabled as well. Change the ntp.conf to one containing: # PPS/ATOM driver server 127.127.22.1 minpoll 4 # PPS - serialpps.sys # NMEA ref-clock driver server 127.127.20.1 minpoll 4 mode 33 noselect # 19200bps, NMEA serial port # Statistics enable stats statsdir "K:\Tools\NTP\etc\" statistics loopstats peerstats This will produce a daily file named like peerstats.20110109 containing information on the various peer sources. You need to filter out lines containing the string "127.127.20.1" which are from the NMEA refclock - you can use the Windows findstr command for this. The resulting file has lines such as: 55570 2396.754 127.127.20.1 901b -1.000040789 0.000000000 0.000234622 0.000021469 where the fifth column contains the offset of the NMEA device. An ntpq -p command should also show the offset. As you can see from the above, it is about -1 second, which will really confuse NTP! Here's a histogram of the offsets - there were four outliers which I should perhaps have excluded as they may have been at the startup of NTP.
Knowing that the offset is around -1 second, the next step is to fudge the time as reported by the NMEA device to be nearer to the correct time, and this can be achieved by adding a "fudge" statement to the ntp.conf referring to the NMEA device, something like this: # PPS/ATOM driver server 127.127.22.1 minpoll 4 # PPS - serialpps.sys # NMEA ref-clock driver server 127.127.20.1 minpoll 4 mode 33 noselect # 19200bps, NMEA serial port fudge 127.127.20.1 time2 1.000 A histogram of peerstats from running with the time2 fudged by +1.000s shows that the offset as perceived by NTP is now close to zero.
Running with a fudge of +1.000 seconds is now showing that my GPS18x LVC has almost zero offset as seen by NTP, so the next step will be to determine a more precise value, replace the estimated +1.000 by that more precise value (just for the sake of knowing what the perceived offset actually is), and removing the noselect from the NMEA driver and see whether NTP stops the jumping I observed in late 2010. Update - I left the offset at +1.000 as there seemed to be no point in having a more precise value. Removing the noselect has not caused any further problems, so the NTP is now working again albeit with a 1-second offset for the NMEA serial data. AcknowledgementsI received much help from Dave Hart, Hal Murray, Steve Sommars,
Kiwi Geoff and
others. |
|
|
