NTP users are strongly urged to take immediate action to ensure that their NTP daemon is not susceptible to use in a reflected denial-of-service (DRDoS) attack. Please see the NTP Security Notice
for vulnerability and mitigation details, and the Network Time Foundation Blog
for more information. (January 2014) &#&# See ConfiguringNMEARefclocksDev for discussion of this topic.
6.1.12. Configuring NMEA Refclocks
Generic NMEA refclocks use the
driver. The configuration directives required depends on the receiver and its internal configuration. The basic
For configuration details please see the examples listed below or the distribution documentation Generic NMEA GPS Receiver page
Configuring NMEA clocks
184.108.40.206. Accord NAV2300 GPS Clock
NAV2300 GPS Clock generates few standard NMEA sentences and a custom NMEA sentence at 9600B. Unlike the standard NMEA sentences which contain UTC time, the custom NMEA sentence has GPS time as shown below:
It contains the GPS timestamp valid for next PPS pulse. Apart from the familiar fields,
- 'AA.BB' denotes the signal strength( should be < 05.00 )
- 'V' denotes the GPS sync status :
- '0' indicates INVALID time,
- '1' indicates accuracy of +/-20 ms
- '2' indicates accuracy of +/-100 ns
Since the NMEA refclock driver was designed to work at 4800B, this GPS Clock cannot be used with NTP. To enable the support, the reference clock driver has been updated with following features:
- Support for 9600B (default is 4800B)
- Support for parsing Accord's custom NMEA sentence (contains GPS Time not UTC)
The unused bits of the mode field have been used for this purpose.
- bit 0 - enables RMC (1)
- bit 1 - enables GGA (2)
- bit 2 - enables GLL (4)
- bit 3 - enables ZGD (8) - Accord GPS Clock's custom sentence with GPS time
- bit 4 - selects the baudrate for serial port :
- 0 for 4800B (default)
- 1 for 9600B
Multiple sentences may be selected except when ZDG is selected. In case of incorrect mode selection, the driver falls back to standard NMEA sentences. The clock generates PPS pulse at TTL levels (with 5 ms on time). A sample configuration for this clock is shown below:
server 127.127.20.0 mode 24
fudge 127.127.20.0 flag2 0
fudge 127.127.20.0 flag3 1
- 11 Apr 2008
220.127.116.11. Garmin GPS18x LVC
The Garmin GPS18x LVC exposes a behaviour that makes the receiver hard to use without PPS support: It seems to center its serial output roughly between the PPS pulses and has a noticeable jitter when doing so. Timing measurements are tricky, but if you use more output sentences per cycle then the GPRMC will have less delay in relation to the PPS pulse.
The Garmin manual states that the NMEA data transmitted is related to the PPS pulse prior to the serial data, and that GPRMC is always output first in a burst.
So at least for the Garmin GPS18x LVC the question about the size of the delay between the PPS pulse and a data sentence depends on the baudrate and the number of sentences to be transmitted. Using GPRMC only at 4800bd gives a delay of roughly 590ms, GPRMC only at 9600bd gives a delay of roughly 510ms.
Using the additional PPS feature of the NMEA driver is highly recommended for the GPS18x LVC: There is jitter of several milliseconds for the serial transmission, which makes synchronisation to this device very slow and sometimes even sluggish. The PPS-aware code of the NMEA driver after NTP-4.2.6p3-RC7 or NTP-4.2.7p72 can substitute the PPS time stamp for the serial receive time stamp when the difference between them is less than ±400ms. (This is not the full truth, but see below.) Since the delay between the end of the serial data and the PPS pulse is bigger than that, a fudge time2 of 500 to 600ms is needed to compensate for the delay. Otherwise the driver would either discard the PPS data or even lock to the next second pulse, which gets ntpd off by one second with micro-second accuracy.
So a recommended config entry in ntp.conf for a Garmin GPS18x LVC (using only GPRMC @ 4800bd) with PPS enabled would look like:
server 127.127.20.0 mode 0 prefer
fudge 127.127.20.0 flag1 1 flag2 0 time2 0.600
Setting flag1 to 1 enables PPS processing within the NMEA driver. Setting flag2 to zero is redundant, but will explicitely tell that we want the 'assert' edge of the PPS signal. The exact value for fudge time2 is not very critical when using PPS; as long as the fudge time2 gets the adjusted receive time stamp into ±400ms around the time of the PPS pulse the driver will lock the receive time stamp to the PPS time stamp. So basically setting the fudge time2 to 600ms (because the NMEA data is late for roughly 1/2second plus some ten milliseconds) should get you up and running quite fast.
If you want a good estimation for fudge time2 (perhaps because PPS is not an option for you) you could use the following procedure:
- Switch off the PPS processing for the NMEA driver and mark the clock as noselect. Set the fudge time2 to zero. Add a few good public time servers or another clock; here in Germany I can use my DCF77 radio clock for that purpose. Disable all output sentences of the GPS18x LVC but the GPRMC sentence.
- Restart the daemon and watch the offset for the NMEA clock. When the value gets stable, use the absolute value of the offset as fudge time2 for the NMEA driver.
- Optionally restart ntpd and verify that the offset remains small. Note the jitter, which is probably in the order of 5-10msec. If the offset is small enough (better than 2ms is doable, but takes a long time to stabilise), go to the next step. Otherwise fine-tune fudge time2 and repeat this step.
- Enable PPS processing again if you can. After restarting ntpd jitter and offset should decrease rather fast.
- Finally, remove the noselect statement and enjoy your fast-locking NMEA clock with a Garmin GPS18x LVC!
And now the truth about the PPS locking: actually only the sub-second part of the difference between PPS time stamp and (receive time stamp - fudge time2) is evaluated and checked. If this difference is less than 400ms or bigger than 600ms (which is equivalent to -400ms) the receive time stamp will be substituted with the properly adjusted PPS time stamp. This might sound a bit complicated, but if you have a device that sends the data before the associated PPS pulse, you can use the proper negative value for fudge time2 and compensate for that behaviour.
Note that firmware versions after 3.20 push the NMEA output even further after the PPS transition, perhaps even to the next PPS edge, making the device problematic as a single reference source. Given another refclock which will get the server within a second, it may be best to simply use the PPS signal from the 18x and not the NMEA output.
Update: the Garmin 3.70 firmware (https://buy.garmin.com/shop/store/downloadsDetails.jsp?id=4055&product=010-00321-51&cID=170&pID=223
) appears to resolve this issue, allowing the device to serve both the PPS and nearest second signals. The offset is around 600ms.
- 2011-03-08 & 2011-06-30
Note that the Garmin GPS18xLVC
operates at RS232 levels (more or less). Virtually all RS232 to CMOS interfaces invert the PPS signal, which is specified as the rising edge of the signal from the device. The falling edge (rising when inverted) is uncontrolled and should not be used as a reference.
You will notice that the wrong edge is being used if the initial offset is close to the PPS pulse width. You don't want to compensate for this with time2, because referencing the uncontrolled edge will cause excessive jitter.
If the PPS API generates clear events from your source (typically DCD, CTS, or a GPIO pin), select them with fudge 2. If not, you need to persuade PPS to generate assert events on correct edge. Exactly how this is done varies based on your hardware's capabilities. For a GPIO pin using the GPIO drivers, set .assert_falling_edge = true. For bare metal, look for a register bit that will invert the input signal or interrupt on the falling edge. Alternatively, you can use an external inverter after the level translator, or design a non-inverting level shifter. Both have serious drawbacks.
I recommend reducing the PPS pulse width from the 200 msec default, and also turning off all but the $GPRMC message. The NTP driver will only respond to one message (the first it gets each second); sending the others consumes power and bandwidth to no purpose. You can configure this with Garmin's windows utility. In theory, you can do this using the serial line, but changing the pulse width doesn't seem to work as specified.
18.104.22.168. Sure Electronics GPS evaluation board
I have sucessfully used the Sure Electronics GPS evaluation board (http://www.sureelectronics.net/goods.php?id=99
) with NTP. With that board, two patch wires are required to convert the on-board CMOS-level PPS signal to RS-232 level. I have documented those patches here: http://www.satsignal.eu/ntp/Sure-GPS.htm
I also found that with the Windows NTP version, the timing of the NMEA signal was such that NTP worked better when set to use $GPGGA, which is the first sentence sent. The configuration was then:
server 127.127.22.1 minpoll 4 # PPS - serialpps.sys
server 127.127.20.1 minpoll 4 mode 18 prefer # NMEA serial port, 16 = 9600 baud, 2 = $GPGGA
In earlier tests, I had also altered the baud rate, although I no longer believe this is required. With a 115,200 baud rate, the configuration was then:
server 127.127.22.1 minpoll 4 # PPS - serialpps.sys
server 127.127.20.1 minpoll 4 mode 82 prefer # NMEA serial port, 80 = 115200 baud, 2 = $GPGGA
In fact, it seems that the board may lose the baud rate setting after a period of being powered down, so best leave it set at 9600 baud.
Related Topics: NMEARefclockUsers
ntpd NMEA refclock driver update
, Generic NMEA GPS Receiver page