GPS clock from RouterOS

RouterOS General
1

Recently got E50UG hEX refresh to replace a switch, original idea was just to transfer data with better management, later I started to use NTP client/server and GPS for TimeSync.

Got GPS UBlox VK-172.

Dont buy it if you are serious about GPS, its a counterfeit, yet it works and can be configured with U-Center software.

There are few considerations how to use GPS module for time syncing - mostly using PPS signal via serial port for 30 ns precision.

This is not available for hEX, just USB connection, which limits timesync for NMEA messages only.

I have few questions about GPS plugin:

gps
gps1272Ă—1253 86.7 KB

The plugin seems to work with RMC and and GLL messages:

https://receiverhelp.trimble.com/alloy-gnss/en-us/NMEA-0183messages_MessageOverview.html

Now, NMEA is by no means an accurate way of syncing. Given the USB 1.10 polling of 1000Hz, it can be accurate down to 1 milisecond at best.

I would like to increase the precision to level when hEX would not be rejected as a timesource by Chrony server.

Most guides include:

  • Increasing baud rate
  • Disable all NMEA messages except ZDA which carries just time and date.
    (in U-Center, there might be an INIT command, still looking)
  • Increasing polling rate on the GPS module from 1 to 5Hz or 10Hz

Few notes and hints I learned:
a) You can use USB cable with external power input, so you can back-up the USB module when rebooting router, and/or switching it between computers for re-configuration.

b) So far 38400 baud seems to work best in order to get acceptable time sync.

c) If the GPS has power source, router will sync with it as soon as it reboots.
However, now router powers down the USB during reboot, can be worked around using external power source.

So, the Questions:

  1. Is it possible to process ZDA messages by GPS plugin?
    At the moment, ZDA messages are not picked by GPS plugin, so I keep active RMC and GLL.

  2. How does the GPS plugin process time decimals?
    Messages send time in format 071255.15 translating to 07:12:55 and 150 miliseconds,

I just assume the decimals get rounded, so using 1 Hz polling rate sorts out uncertainty, as timestamp sent from gps is always whole second.

Knowing if there is a support for sub-second timeframe will improve the accuracy.

  1. Is it possible to keep USB powered during reboot?
    Consider usb GPS as an external local time source, it will sync the router instantly.

  2. Cloud sync on or off?
    Few times, router picked up time from cloud source before GPS key booted up, caught satellite signal… the time it had helped with first sub-milisecond sync (when PPS sync is not available), so Chrony server would not reject the router as a source, afterwards syncing was overtaken by GPS.

Later I turned it off just to rule out another factor.

2

Basic problem with using NMEA output is that NMEA timestamp is not transmitted (or rather: started to being transmitted) on the exact time contained in that message. It probably depends on actual GPS device, but generally NMEA message is transmitted with slight delay (can be hundreds of milliseconds). For any kind of precision one has to use NMEA messages (which give absolute time with precision of fraction of a second) together with PPS signal (to get actual beginning of a second with precision of a millisecond or so). If you "pimp up" transmissions of NMEA messages, you may be able to trim down the delay jitter (of those NMEA messages), but still see systematic time offset (if comparing to known good NTP sources). If not for other things, you'll have around 8ms of offset due to transmission delay (7.7ms ... 37 bytes at 38400bps; I'm pretty sure timestam might be current at time of starting to transmit first bit of that ZDA message) and processing delay.

3

Yes, however PPS is not an option for the hEX refresh.

How exactly works the usb port on gps dongle is also not clear, from the timestamps it seems data are transmitted in bulks, rather in traditional serial manner.

It is true that RMC message is received first and ZDA as the last one, with some delay - like 20-50 miliseconds. Yet if i am not mistaken, NMEA time should arrive before the actual start of the second, and pps signal marks it afterwards.

Pimp-up’d raspberry ntp clock with gps can set offset for each meter of the antenna cable, and given nature of usb, this setup is nowhere accurate as that.

I am aiming for ±0.05 second accuracy, given USB 1.10 polling rate, absence of PPS and reliance on solely NMEA 0183.

There is one specific message

NMEA-GN-ZDA_GNSS1TOS

So called top of second, which should be sent at the same time as PPS.

4

The point of my previous post is that whatever you do, NMEA (whichever message) won't get you anywhere near precision NTP requires (and deserves). It needs PPS. And if your hardware doesn't properly support PPS, then everything is pointless ... just go with plain old NTP over internet (or use proper hardware, such as Rpi). ROS devices are simply not fit to serve as precise time servers (NTP client/server combo comes closest to that).

5

I think that is your best solution. I have built a couple of units. My current NTP server with GPS receiver is based on the RPI5.

6

Aside from that solution, you can also get complete ready-to-use GPS synced NTP servers from Aliexpress and similar stores.

E.g. the “HamGeek” type is available for 60-70 euros. That will be cheaper than an RPi5 solution, but of course it does only NTP and not the many other things that you could do on a RPi5 at the same time (DNS, WWW etc).

7

Atm I have Home Assistant Green with Chrony plugin. I am checking the docs of gpsd and Chrony can be configured in a way as you have.

I have no doubt that GPS with PPS is the best solution for a gps synced ntp clock.

But currently, In case of network outage, most of my devices will start to drift, 20-30 seconds in 5 days, while 15 seconds will cause timeouts - that includes Chrony hardware, other possible NTP server in NAS are also prone to this. Local services will die without network timesync, regardless of power (or use bad time and work in limited mode)

GPS over USB can achieve ± 1 second at worst, ±0,05ms at best, nowhere near to 30ns over pps, but it will keep things running.

8

These dont support PPS as well, and have exactly same precision as the solution I already have. ( At least those i have checked. Teltonika, Hamgeek some others.)

Rpi builds and ESP builds are usually differrent.

9

That actually surprises me… I do not have a HamGeek NTP server myself, but I do have other cheap stuff like their GPSDO and it outputs 10 MHz and PPS with high accuracy. It would surprise me when the NTP server is not similarly built and use the PPS internally.

(I do have a LeoNTP 1st generation here myself, unnecessary to state that it works flawlessly, but this is a different price category)

MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
#* PPS                           0   4   377    17   -107ns[ -420ns] +/-  261ns
^- leontp.pe1chl.hamnet.nl       1   6   377    59    -20us[  -21us] +/-   76us
^- mikrotik                      2   6   377    15   -292us[ -292us] +/-   40ms

(this is the chrony output of my PC which has the PPS output of the LeoNTP on a serial port and the network connection of the same LeoNTP as well. the third line is a local RB4011 router synced to both the LeoNTP and the PC)

10

To put things in perspective:

Teltonika NTP001:

https://www.teltonika-networks.com/products/gateways/ntp001

Precision ±1ms
113 Euro

Hamgeek FC-NTP-MINI

https://www.aliexpress.com/item/1005006199371815.html#nav-specification

Precision ±0.5-2ms
76 euro

Just found another similar device for 450 Euro, with similar parameters.

The USB i got:
VK-172

https://techfun.sk/produkt/gps-glonass-modul-usb-vk-172/

Precision 0.5-1ms
6.63 euro.
(not counting E50ug since it serves mainly as a managed switch)

Went through ntp.pool forums, looking for recommendations, and they were trash-talking some of these devices. 0,5-2ms precision is a dead giveaway, at least they dont lie about that.

Such device can and will save your home or small company network from sync issues, but usually its 10+ years old GPS chip repurposed for NTP GPS time sync…

So, plugging old GPS module (± 2012 - 2016) into already functioning device, install plugin software and and have 0,05-1ms precision for about 7 euro is a bargain.

11

You are right, I checked on the Teltonika forum and indeed the NTP001 does not use PPS. Unbelievable.

It surprises me that the HamGeek device is similar, because I expected the design to be similar to the GPSDO device that I think comes from the same source, and it uses a cloned GPS module that does provide PPS. It seems that when designing and selling a dedicated NTP device one would at least use PPS, but apparently these have become the victim of the downward spiral in design quality as well.

Of course it all depends on your purpose if this is acceptable. To just have all devices on an isolated network (otherwise you would use Internet NTP) to the same time for management, 2ms will be adequate. At least when the software on the NTP clock is of reasonable quality and is smoothing the derived time, not jumping around for every NMEA message. In such cases USB-based time sync is fine as well.

Microsecond precision is usually only needed for things like co-channel transmitters or other audio synchronization, not for network monitoring.

12

Its for syncing phones, pcs, android tvs, NAS and home assistant system (sensors, heating, ventilation). Those were calling differrent time sources and running fairly out of sync from each other.

Chrony helped by centralising NTP time locally, but it became single point of failure.

If Chrony will not reject E50UG + GPS USB as a false ticker it will solve dependency on network time.

Now it works for few days, time sync is very precise, but I fear there will be issues on next router reboot.

13

I would say it is GREAT that chrony rejects the time source as falseticker when it does have an actual internet NTP source. That would normally be more accurate (except when the delay on the internet line is very asymmetric e.g. because it is always fully loaded)

Chrony would keep the accurate time reference for your network (of course the devices should be configured to use that) and when the internet fails it will be synced to the less-than-accurate GPS solution.

The only thing you need to test is if that actually works, both in case of a network failure after it had worked OK (you can simulate that with a firewall rule for NTP in the raw table), and also after a powercycle.

It may take quite some time for chrony to switch from its own lock to reliable servers (e.g. pool.ntp.org) to the local device that it knows is a falseticker. That is because it will normally continue to run the synced clock using the previously measured frequency error, and it may take hours before that “calculated” clock deviates enough for the “NMEA synced GPS clock” to become better.

14

Having E50ug to act as gps clock and chrony as server taking 3-5 sources - one of them local, all in sync without falsetickers is preferred state.

Closest atomic clock, 6ms away by ping usually has 0.05s offset to local GPS on Mikrotik, gives about 1ms dispersion, ntp pools give about same results.

Docker supervisor has time from gps, chrony container has network time so i can monitor offset simply by restarting chrony. Its not changing at all for days now.

So, setting the gps to be an acceptable source for local Chrony should not be much of a problem, and info i requested in first post would help.

So far the tips like using mininum NMEA messages (Just two), with higher bitrate (38400) seems to work.

15

Generally using Mikrotik device as any kind of stable time source is less desirable than any other solution.

  1. Main reason is that Mikrotik devices don't have (battery-backed) RTC hardware on board which means that when device is booted, it has (in best case) only rough estimate about correct time (often by tens of seconds if not minutes in the past).
  2. NTP implementation in ROS is not as extensive as "reference" implementations (as we're used to in linux world)
  3. support for Stratum 0 hardware (e.g. GPS receivers, not to mention others) is only partial
  4. I'd guess that clock stability might be an issue as well, which means that "free running" (with adjusting according to previously determined frequency error) might be less stable than one might expect

Which, all in all, means that using MT device as a time source for the rest, is iffy (at least as much as a replacement for a proper NAS or virtualization server). Just because it seems it can be made to work it doesn't mean it'll work fine.

16

It is already much better than it used to be in v6 and early v7. It no longer is a SNTP client syncing a free-running NTP server, now it actually calculates and applies a drift and it replies times within a millisecond or so, with occasional outliers of tens of ms. When used to sync other NTP servers (chrony, ntpd) or to get “wrist watch time” (e.g. for another router, printer, or Windows machines) it works fine.

17

I partially fixed that with adding external power source to the USB cable. If router reboots and GPS is still on, it will pick it as a timesource immediatelly - no critical error regarding time drift.

20 000mAh battery might keep it alive for more than a week + router is on an UPS.

GPS itself has internal clock, which is supposed to be TXCO 0.5ppm oscillator, so it will hold quite precise time even without signal.

Also, i would say that GPS module is stratum 1, the router is stratum 2, its more fitting description.

18

Currently i have NTP client off, NTP server is on providing its internal time as a source, while GPS is syncing them.

Having NTP client on, with multiple sources, including local time was more troublesome.

From the outside view, checking the offset on a 3rd device it seems to be working, at least in the manner as those overpriced low-precise solutions.

Also my E50ug is mostly used as a switch (ports 2-5) and whole cpu capacity can go towards gps timesync and NTP.

edit: just went throught this:

https://austinsnerdythings.com/2025/02/14/revisiting-microsecond-accurate-ntp-for-raspberry-pi-with-gps-pps-in-2025/

I did some of the tuning mentioned here. Fixed position is used (configured from Pc), unnused messages are off, however i cannot use ZDA with ROS.

Offset of 70ms from pps, in my case 50ms compared to atomic clock is definitely acceptable.

19

Just been testing few things.

Once offset is established by the NTP client, I can turn it off and ROS with GPS sync wont be rejected by the Chrony as a false ticker:

enabled: no
mode: unicast
servers: atomic clock NTP
ISP NTP
vrf: main
freq-drift: 0 PPM
status: stopped
synced-server: 127.127.1.0
synced-stratum: 1
system-offset: 49.015 ms

so far I am monitoring the drift by

w32tm /stripchart /computer:x.x.x.x /samples:200

Chrony is drifting by 4th decimal, ROS by 3rd. I’ll give it few days to settle. So far, an option do add system offset would be a great start.