Toit
#Setting system time from a GNSS device.
Thread channel in help
milkmansson 02/19/2026 08:38 AM
Tying to find the smartest/most accurate way to set system time using GNSS. Most GNSS devices I've seen so far can emit 'time' type messages, and some* GNSS devices have a PPS pin - so I am thinking of implementing two methods. Looking for feedback/better ideas in case anyone has any!
#1 (supports devices that don't have a pps pin): Take the exact time when a time message comes in. To account for system time not set - if difference is > 1 day, set the time immediately to the time in the packet. Take a moving average of the difference of GPS time to System time, for the next 3 (5? more?) messages. Adjust the system time by that difference. Assuming this will be less exact than #2, so we could add a fixed (configurable) +/- x ms/us to account for processing delay.
#2 (for devices with a pps pin): When configured, PPS pin can pulse exactly 1 time (usually 1x/sec, depending on device/config). Do the same as #1, but instead, take the moving average from the pin rising edge instead.
Other things:
- perhaps some holddowns, eg, set the time only when time difference is > threshold, do only once/day, etc. (maybe look at the NTP method and use the same from there)
- maybe adjust the 'time' message constructor to record the system time when the packet is received. (Or leave that to the driver - at the cost of an increase in the time difference.
Any thoughts appreciated!
#1 (supports devices that don't have a pps pin): Take the exact time when a time message comes in. To account for system time not set - if difference is > 1 day, set the time immediately to the time in the packet. Take a moving average of the difference of GPS time to System time, for the next 3 (5? more?) messages. Adjust the system time by that difference. Assuming this will be less exact than #2, so we could add a fixed (configurable) +/- x ms/us to account for processing delay.
#2 (for devices with a pps pin): When configured, PPS pin can pulse exactly 1 time (usually 1x/sec, depending on device/config). Do the same as #1, but instead, take the moving average from the pin rising edge instead.
Other things:
- perhaps some holddowns, eg, set the time only when time difference is > threshold, do only once/day, etc. (maybe look at the NTP method and use the same from there)
- maybe adjust the 'time' message constructor to record the system time when the packet is received. (Or leave that to the driver - at the cost of an increase in the time difference.
Any thoughts appreciated!
1 messages in total