GPS 18x firmware
Home Page Up Setup on Windows Using NTP Windows LAN tips Performance Events Cable modem notes Monitoring with MRTG GPS 18 + FreeBSD GPS 18 + Windows GPS 18x firmware GPS 18x waveforms NTP 4.2.4 vs. 4.2.5 NTP 4.2.7p241 Rapco 1804M notes Raspberry Pi RPi - quick-start RPi - notes RPi - cross-compile RPi vs BBBlack Sure GPS board Timestamp issues TSC Interpolation Vista & Windows-7/8 Wi-Fi warning Windows after reboot Win-7/8 & Internet Win-7 to Win-10 gains New versions

 

GPS 18x LVC firmware version issue

If 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 which you can download here:

Garmin GPS 18x LVC firmware download

  • This is actually the second firmware issue I have had with the GPS 18x LVC.  As I reported here, the device once stopped working and had to be replaced by Garmin.  I am reminded by Dave Hart that it was due to a firmware bug that bricks the unit until it's left off power long enough to drain the capacitor that retains its settings, sort of a poor-man's NVRAM.  This can take some weeks.  It happens unpredictably during normal use (e.g. unrelated to changing the device settings).  This may happen on firmware 3.20, the last version before the NMEA timing issues fixed in 3.70, hence the recommendation to update to 3.70 as soon as possible.
  • Neither problem affects the earlier GPS 18 LVC unit, which will not accept the 3.70 firmware upgrade.

The problem

In 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.  
However, the problem re-occurred in November 2010, and persisted even after moving the puck to a more favourable location.  I noticed that the Garmin firmware download may have been slightly different, even though it carried the same version number, so I tried updating the firmware again.  I also noted that the NMEA clock was seen as being almost exactly one second fast or slow, and hence I concluded that the serial output was not precisely in sync with the PPS output.  I therefore checked that the puck was sending just a single GPS sentence (which it was), and I increased the serial speed from the 4800 baud default to 19200 to try and reduce any serial delay.  Quite why this should be needed when the unit had been working correctly for a year was not obvious to me.
In December 2010 I noticed the problem again, and I updated to the most recent 3.50 firmware.  However, this did not cure the problem this time, and after discussions with Dave Hart, I disabled the NMEA driver, while leaving the ATOM (PPS) driver running.  I marked one of the other servers as "prefer" rather than the now disabled NMEA driver.  This new arrangement appears to be working correctly.
Checking on the 'scope it seems that with firmware 3.50 the NMEA output is now sufficiently delayed compared to the leading edge of the PPS that it's very close to, if not after, the leading edge of the next PPS - i.e. about one second out.  Version 3.00 of the firmware is reported to be OK, but I haven't tested this myself as a downgrade from the 3.50 firmware.  Please write to Garmin if this issue affects your use of the device - it seems to render it out of specification as far as I can see.  See also: Configuring Garmin Ref-clocks.

Update - 3.70 firmware

Garmin 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.

Kiwi Geoff writes:

Hi David,

A few days ago I did a 24 Hr log of the NMEA latency with the new firmware (3.70) for the Garmin 18x.  I sent the raw data to Hal Murray - and he made a nice graph.

There is a constant 149 milliseconds between $GPRMC start and finish, however as you can see from the graph, there is quite a variation in start time.  So still not great as just a NMEA time standard - but much better than version 3.60.

Regards, Kiwi Geoff (Christchurch, South Island , New Zealand)


Click for a full-size graph

Update - 3.90 firmware

In 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.
He writes: 

"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.

Item Firmware
3.70
Firmware
3.90
Minimum delay of RMC first character 330 ms 336 ms
Maximum delay of RMC first character 504 ms 517 ms
Delta (Max - Min) RMC first character over 24 hour period 174 ms 181 ms

"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 resolution

With 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
55570 2412.754 127.127.20.1 901b -1.000030548 0.000000000 0.000234037 0.000017345
55570 2428.753 127.127.20.1 901b -1.000011761 0.000000000 0.000233831 0.000025733

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.

Acknowledgements

I received much help from Dave Hart, Hal Murray, Steve Sommars, Kiwi Geoff and others.  
Thanks folks!

 
Copyright © David Taylor, Edinburgh   Last modified: 2015 Jan 18 at 09:32