r13 - 2011-03-08 - 10:00:48 - DavidTaylorYou are here: NTP >  Support Web > ConfiguringNTP > ConfiguringRefclocks > ConfiguringGarminRefclocks
NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p10 was released on 21 March 2017. It addresses 6 medium- and 5 low-severity security issues, 4 informational security topics, 15 bugfixes, and contains other improvements over 4.2.8p9.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
REFACTOR See ConfiguringGarminRefclocksDev for discussion of this topic.

6.1.4. Configuring Garmin Refclocks General Notes

The Garmin GPS18-LVC works well with NTP. Beware: The other models of the GPS18 don't have PPS support. You should be able to get one for under $100.

It comes with bare wires. You need to supply 5V and wire it up to a DB-9 connector.

You can get the 5V from a USB connector.

You can also get 5V from some serial cards. (The context is powering things like bar code scanners.) The SIIG CyberSerial 4S has jumpers to supply 5V or 12V on pin 9/RI. GPS18x-LVC specifics

Please note that the GPS18x-LVC sometimes gives odd huge offsets in the range of -600ms upto -700ms. One specific model was examined a bit closer and showed a varying delay between the asserting edge of the PPS signal and the receive time of the $GPRMC sentence of 580ms to 610ms at 4800bd. (Only $GPRMC was enabled in the GPS18x and the NMEA driver, though according to the GPS18x spec $GPRMC should be the first sentence in a burst anyway if enabled in the receiver. See section 4.2 of Garmin's GPS18x tech spec.) Using a fudge time2 of 0.600 was needed to avoid malfunction of the NMEA clock driver. I (mailto:perlinger@ntp.org) do not know if this affects all GPS18x-LVC models or if this is baud rate dependent. (Apart from the transmission duration itself, which is of course baud rate dependent per se and should account for ~150ms for a $GPRMC at 4800bd.)

If you experience severe trouble with the GPS18x-LVC a possible solution is to configure a few good public NTP servers as reference and configure the NMEA driver as a 'noselect' peer with PPS disabled and a fudge time2 of 0.0. When the system becomes stable, use the negated offset given for the NMEA driver as fudge time2, remove the 'noselect' from the clock driver and enable PPS processing with fudge flag1.

It seems that using the GPS18x-LVC without PPS support and some basic calibration cannot be recommended. Related Links

Related Topics: GarminRefclockUsers

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r13 < r12 < r11 < r10 < r9 | More topic actions
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback