LEDE as Stratum 1 NTP server using USB GPS


Hi, I need to run a local stratum 1 NTP service on LEDE, using a Globalsat USB GPS reciever.

I've had a quick search but can't find any references for this. Any advice would be much appreciated.



From my own documentation for a vk-172 gps dongle:

===== Feed GPS time to ntpd =====

Source: [[https://forum.openwrt.org/viewtopic.php?id=61161]]\
See also [[openwrt:ntpd|ntpd]]

  • Install the following packages:
    • ''kmod-usb-acm'' # for vk-172 gps dongle
    • ''gpsd'' # supports various nmea/binary gps protocols
    • ''gpsd-clients'' # some clients for testing (cgps, gpspipe, ...)
    • ''ntpd'' # real ntpd to replace busybox
    • ''ntp-utils'' # ntpq needed for testing ntp
  • Plug in your USB GPS dongle
  • Check for presence of ''/dev/ttyACM0''\
    ls -l /dev/ttyACM0
  • Edit ''/etc/config/gpsd'' and set device to ''/dev/ttyACM0''\
    config gpsd core
    option device "/dev/ttyACM0"
    option port "2947"
    option listen_globally "false"
    option enabled "true"
    Set ''listen_globally'' to true to enable remote access to gpsd. If remote access is not desired, set to false.
  • Add this to ''/etc/ntpd.conf'':\
    # GPS
    server minpoll 4 prefer
    fudge refid GPS
    [[http://doc.ntp.org/4.2.8p6/drivers/driver28.html|Config options and fudge factors]]
  • Disable sysntpd\
    /etc/init.d/sysntpd stop
    /etc/init.d/sysntpd disable
  • Restart ntpd + gpsd\
    killall -9 gpsd ntpd
    /etc/init.d/gpsd start && sleep 2 && /etc/init.d/ntpd start
  • Check gps function\
    cgps -s -u m
    gpspipe -v -r /dev/ttyACM0
  • Check ntp function\
    ntpq -p

See also



You cannot run a stratum 0 NTP server, because stratum 0 is reserved for the device generating the reference time (in your case, the GPS receiver); your LEDE device will be a stratum 1 NTP server.

1 Like


Thanks people. That's an awesome HOWTO.



Hi, I actually had two posts on the openwrt wiki for setting up ntp with a cheap usb gps device.

The post above referenced by tmomas required both gpsd and ntpd to be configured and was more complicated.

Later, I posted a simpler solution requiring only ntpd. The difference I found was ntpd has a reference clock that will talk directly to a gps device.

the post is here: https://forum.openwrt.org/viewtopic.php?id=67532

That said, I haven't tried this with LEDE so I can't verify that it works (yet)

also, since the time of that post, I haven't refined the config file lines. I don't think the PPS signal applies to a USB gps device, it's usually a separate input to your system.

maybe a LEDE howto that people can refine is in order?



I was able to make it with basic tools: ntpd from Busybox (system default) and with ugps (with this fix in init script).

There is currently one problem with ntpd from Busybox - it loops forever (before starting server routine) on resolving address of the provided serves, which for devices without Internet access makes it useless (ntpd server routine never starts).

For now, we don't allow to start ntpd without any upstream server provided (-p option), I'm planning to propose some patch for this soon.



Thanks again. Being a fan of the KISS approach, I followed mike866's recipe.

The only significant change was that for my device, a Globalsat BU353, I used kmod-usb-serial-pl2303 & dev/ttyUSB0.

This works fine, if I manually run "/etc/init.d/ntpd start", it loads up runs as expected.

root@c-fw:~# ntpq -p
 remote           refid      st t when poll reach   delay   offset  jitter

*GPS_NMEA(0) .GPS. 0 l 5 16 377 0.000 2.541 5.297

However, after running "/etc/init.d/ntpd enable" and rebooting, ntpd loads but then exits shortly after:

Fri Mar  3 16:14:53 2017 daemon.info ntpd[1997]: Command line: /sbin/ntpd -g -u ntp:ntp -p /var/run/ntpd.pid -n
Fri Mar  3 16:14:53 2017 daemon.info ntpd[1997]: proto: precision = 1.900 usec (-19)
Fri Mar  3 16:14:53 2017 daemon.info ntpd[1997]: Listen and drop on 0 v6wildcard [::]:123
Fri Mar  3 16:14:53 2017 daemon.info ntpd[1997]: Listen and drop on 1 v4wildcard
Fri Mar  3 16:14:53 2017 daemon.info ntpd[1997]: Listening on routing socket on fd #50 for interface updates

Fri Mar  3 16:15:18 2017 daemon.notice ntpd[1997]: ntpd exiting on signal 15 (Terminated)

Seems that ntpd is killed by something happening during LEDE boot. Any suggestions as to where to look ?



OK, I've fixed this, by installing the 'ntpdate' package in addition to the ones mentioned in the article linked above. After a reboot, ntpd started normally. My recipe for running LEDE as a stratum 1 server with a Globalsat USB GPS is therefore something like this:

opkg update
opkg install kmod-usb-core
opkg install kmod-usb2
opkg install kmod-usb-serial-pl2303
opkg install ntpd
opkg install ntp-utils
opkg install ntpdate

Insert USB device, check for presence of: "/dev/ttyUSB0"
Edit "/etc/init.d/ntpd", add:

ln -sf /dev/ttyUSB0 /dev/gps0

Edit "/etc/ntp.conf", uncomment:

server minpoll 4 prefer
fudge flag3 1 flag2 0

Stop and disable Busybox ntpd service:

/etc/init.d/sysntpd stop
/etc/init.d/sysntpd disable

Start and enable ISC ntpd service:

/etc/init.d/ntpd start
/etc/init.d/ntpd enable

Check proper function:

root@c-fw:~# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
*GPS_NMEA(0)     .GPS.            0 l    5   16  377    0.000    2.541   5.297

This is just the basic setup, further work may be needed to tailor it for a specific environment, security considerations etc. etc.



We should add both our recipes to the LEDE wiki.

I'm taking care of this...

Done, see https://lede-project.org/docs/howto/ntp.gps



BTW: Which Globalsat USB GPS device are we talking about?
This one? http://usglobalsat.com/p-688-bu-353-s4.aspx



Mine is an earlier version using SiRFstar III module, that one is SiRFstar IV.

It's a reasonable assumption they should be compatible, but it would be good to verify..

(Mine has given over 10 years good service, I've used it with a little netbook PC on the dash of my VW T3 Syncro on many interesting travels..)



Can you update the linked page accordingly?
Maybe you also have a usbID of this device (vid:pid)? Or something else to identify this device, so that other users are able to find / buy it?



Done, thanks!



why in my openwrt "/etc/ntp.conf" not found?
or I have to add it? whats the default config actually?



I used tutorial in main docs of openwrt like what it said (Globalsat BU353S4...
can you help me to resolve this issue?
I already install all of it, al of them is running but the gps location is not update (n/a),
I think the problem is in /etc/ntp.conf, because I don't have it in my openwrt...
can all of you show me the correct configuration of /etc/ntp.conf, I open link (https://forum.openwrt.org/viewtopic.php?id=67532) it's not working,

any help I appreciate it...



Please realize that connecting a consumer-grade (designed for location, not for time keeping) GPS unit over USB serial does not have the accuracy of "proper" GPS synchronization due to significant and inconsistent delays in the serial line itself, as well as in the USB system. Your notion of time will likely be delayed by tens of milliseconds if not hundreds of milliseconds. Any such-configured NTP server certainly can serve as a backup for local timekeeping when Internet connectivity is not available, but should never be advertised on the Internet as a Stratum 1 clock.

Proper GPS synchronization uses a PPS output (or similar) from the device, fed directly into an interrupt-generating line, for example a GPIO or native parallel port. A GSPDO (GPS Disciplined Oscillator) is typically used which locks a temperature-compensated oscillator to the GPS time and provides a stable, reliable reference.

1 Like


how to do that? advertised not as Stratum 1 clock,



Don't accept incoming connections from anything but your own subnet.

See, for example, http://support.ntp.org/bin/view/Support/AccessRestrictions

1 Like


Are there any open ports in a standard OpenWrt installation that would allow incomming connections from WAN to ntpd?



You'd likely have to open UDP 123 to allow externally initiated connections, but you also wouldn't want to have NTP that wasn't really "up to snuff" establishing a peering arrangement with an Internet-resident NTP server (outbound connection opens the firewall and NAT by virtue of conntrack). While NTP is pretty resilient to "rogue" or "mis-sync-ed" servers, it's pretty bad form to knowingly peer when your sense of time is much poorer than your stratum indicates.

As a backup, this home-brew approach works pretty well when used in concert with a "main", local NTP server. The main server has multiple Internet peers, as well as having the stand-alone server as a peer. When there is good Internet connectivity, the NTP clock-selection algorithms, at least those in the reference implementation, will likely reject the stand-alone server as it is inconsistent with, for example, the other three peers. When the Internet gets flakey or fails entirely, it will resort to the stand-alone server.

ACTS is another "no-Internet" synchronization approach that strives to remove the effects of serial/modem/phone delays. However, it requires a "dedicated" phone line and a modem that still works with the pre-compression modulation rates. (Edit: Looks like with only 2,000 calls a day, ACTS has fallen out of active use. Given the inexpensive price of a time-keeping GPS unit and suitable hardware, I wouldn't use ACTS any more.)

Best is a GPS unit designed for time synchronization and an interrupt-driven input for the PPS output. Such GPS units are available on the surplus market in the US$25-150 range, with the more reputable "tinkerer grade" GPSDO units around US$150. (Check out eevblog for information on many of the GPSDO options and opinions on them.)

Edit: I can't vouch for the seller on eBay, nor for the unit itself, but https://www.eevblog.com/forum/repair/symmetricom-nts-200-time-server/ is one "turn-key" NTP box that might make a good project. They were formerly sold under the TrueTime name, prior to acquisition by Symmetricom. The one I saw looks like it needs an antenna. Beware of the "Week-1024 bug" (mentioned in the linked thread on eevblog) as surplus GPS gear can easily be over 19 years old now.