I've seen a decent amount of documentation for how one would use a GPS and its PPS signal along with an NTP package (like ntpd or chrony) to synchronize the computer's clock.

I have a need similar to this, but different enough that it's been complicated to see a straightforward solution.

The constraints

Note, my environment is inherently without internet access or GPS signal, and the up-time will be very short-lived, a couple hours at a time perhaps. Note, in this case we have an off-board micro-controller and a basic linux machine (likely some single board computer type thing), the ultimate goal is for these to be synchronized.

The microcontroller is connected to this RTC (with I2C) and the computer (through USB) and will be handling timekeeping and synchronizing of some external sensors. The computer takes information from the sensors and does various other things with it. Ethernet connection between linux machine and MCU is generally not possible, otherwise I would just use something like PTP or NTP more directly.

Difference from GPS PPS

The main difference here from the GPS PPS, is that the computer needs to read from the microcontroller serial communication for our purposes in addition to the synchronization. From my understanding this means we need modifications from the standard gpsd + ntpd/chrony since these two sources (our application and gpsd) can't simultaneously read from the same USB serial.


Note, I am aware that this will not reach GPS levels of drift. What I need is a synchronized time source between my MCU and computer which is accurate to some number of milliseconds. I can accept that this whole systems drifts with 1-3PPM (the RTC) as long as everything drifts together.

Idea for a solution

My idea so far would be upon PPS signal from the external RTC

  • RTC PPS captured by MCU and linux machines GPIO pins
  • MCU sends (over serial) corresponding unixstamp to our application node (on linux machine)

Our application then makes the PPS signal and unixstamp available to chrony. Which at this point should be able to treat it as if it was a GPS. So I'm basically circumventing gpsd so I don't have to share serial port access.

Could this make sense? I have found almost nothing from other people doing something similar

1 Answer 1


I am not sure I entirely understand your solution, but normally ntpd works because on PCs etc. Linux understands how to set the hardware RTC clock. So you can either

  • write a driver for your I2C-connected RTC, so ntpd just works out of the box
  • do a user-space approach: When you have internet, script the hooks for that so that ntpd runs. Then ntpd will synchronize the kernel (software-only) clock, and in a second step you can then sync your I2C-connected RTC with some piece of software. Vice versa, on boot and without internet, you can sync the kernel clock from the RTC with something in the boot script.

I am a bit confused about your mention of PPS, as you say you do not have any GPS. Or does your I2C-connected RTC provide some kind of PPS? It might be easier to just read the clock and sync the kernel from time to time (via cron, etc.).

  • The RTC provides a PPS. My solution was attempting to simplify w/ respect to hardware complexity. Note the linux machine still has it's own RTC, I have no intention of disabling it or anything like that. But the drift is such that I wouldn't want it to be the only source. Mar 9, 2023 at 12:30
  • Even with internet this needs to be kind of an ongoing process. The microcontroller is responsible for sensor time stamping so it's timekeeping is much more important, therefore it should be simple. That's why I wanted to do something on the computer side to tie everything together. I figured the simplest way to do this is by observing the PPS, as this doesn't have a chance of interfering with the I2C connection the RTC has with the MCU Mar 9, 2023 at 12:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .