This page contains some notes on different methods of synchronising clocks from other sources (eg, GPS).
PPS and Time relationship
GPS receivers can provide the "current" time over a serial connection, but this is usually delayed by a significant margin. Typically there is between 100 and 500ms delay, not taking into account any processing delays the device reading the time may have.
To facilitate getting a more accurate sense of "current", GPS chips often have a 1PPS signal. This signal should go high very close to the exact beginning of each UTC second. The diagram below covers the difference between 1PPS and when the time is reported by serial.
If your RTC is very simple, probably based on only full seconds, and you do not have access to any subsecond counters, then it may be easiest to just set the RTC time on receive of the serial data. This will have a significant error in it, but without control of how far through counting each second the device is, we cannot account for that error.
Zero on write
An RTC which zeros the subsecond counter when the time is written can be set much closer to the top of UTC. Since we know what the time will be when the next 1PPS signal fires (it will be exactly 1 second later than the time we just got from the GPS), the process to sync is then:
- Receive the most recent GPS time
- Increment this time to the next second
- In the interrupt handler for 1PPS line, commit the seconds first, then the other parts of the time
An example of an RTC chip which resets on seconds being written is the DS3234. (See DS3234 Datasheet, last paragraph of page 11). We have to write the seconds first otherwise the seconds may roll over and increment our minutes/hours etc.
We can also do the same with any locally stored clock.
To get much closer to the top of the UTC second, we need full access to the actual clock signal being sent into the RTC timer. We also need to compute the differences between our clock and the the 1PPS signal, so we know how much we need to adjust the clock by.
Synchronisation is therefore a two step process:
- Compute the difference between 1PPS top-of-second and our top-of-second
- Increase or decrease the rate of clock pulses going into the clock to close the difference
Typically this process is executed over a large number of seconds, as you may not be able to increase/decrease the rate by very much, and we may not want to introduce too much instability in the clock by running it wildly fast/slow.
Computing the difference can be done by saving the current clock state when the 1PPS signal goes high, and then taking the reported serial time from the GPS and comparing them. Thus:
difference = GPS eeported time - Saved time triggered by 1PPS
If there is a small difference between the two, we only need a small change to the clock rate. For example, we might insert or remove only one pulse of the clock for this round of synchronisation. If there is a larger difference, we might insert/remove many pulses.
If the difference is larger than a couple of seconds, it makes more sense to reset the clock. Just apply the last GPS reported time, which will be around half a second behind top of UTC, but is sufficiently close to begin slewing.