TS-7970 RTC Calibration
The TS-7970 Rev. H included a change due to parts availability the where the RTC functionality was moved from the temperature compensated Intersil ISl12022 RTC to the supervisory microcontroller. This provides a register set compatible with Linux's existing RTC driver so software is backwards compatibile, but the newer RTC has a higher drift.
A typical RTC crystal is approximately ±20 ppm accurate which results in drift while the system is offline of approximately ±631 seconds per year. A crystal's accuracy will become worse when run in different temperatures, or as the crystal ages.
The Intersil RTC was previously ±5 ppm which is approximately ±158 seconds per year. This is also temperature compensated so the Intersil RTC checks the temperature every 10 minutes and tunes itself to stay within a low drift.
The new supervisory microcontroller does not support temperature compensation with its RTC, however we have created a process for calibrating the RTC. This can be used to compensate for the typical temperature where the board operates. The RTC on TS-7970's before Rev. H are factory calibrated and temperature compensated and will not benefit from further calibration documented below.
Our circuit, operating temperature, the variance of each crystal as they are manufactured, and aging all contribute to crystal accuracy. In the TS-7970 production process we perform this calibration at room temperature. At the time of use in our factory this will give roughly <5 ppm immediately after calibration. The crystal will offset by ±3 ppm per year, and will vary more significantly based on the temperature.
The ppm offset range can be calculated with:
Eg, our calibration is performed at 22 C:
, or roughly ±139 ppm at 85 C.
To calculate the seconds offset per year:
| Temperature (C) | Estimated PPM range |
|---|---|
| 85 | ±139 |
| 50 | ±27 |
| 10 | ±5 |
| -40 | ±135 |
These are not exact ppm offsets, but a rough range to use for estimation of drift.
Recalibration will help compensate for the affects of aging on the crystal, and can be used to target a more application specific typical operating temperature. Calibration is performed by removing the offset in the RTC, then using an NTP client to sync up the clock. These instructions are for Debian, but will work under any distribution that can run Chrony and a recent kernel.
First, we must clear the RTC offset.
# This requires an up to date version of 4.9, or any release of 5.10 for the offset file:
echo 0 > /sys/class/rtc/rtc0/offset
After clearing the rtc offset, install chrony.
apt-get install chrony -y
Open /etc/chrony/chrony.conf, and add the line:
rtcfile /var/lib/chrony/rtcfile
Make sure there is no 'rtcsync' in the file since it cannot sync the hardware clock during this test, and that cannot be set with rtcfile.
Then restart chrony, and force a sync:
service chrony restart
chronyc makestep
At this step we must wait for the system clock to get in sync with the upstream NTP server. From our testing with a good network connection this can take 15-30 minutes until the RTC offset settles. From here we can query chrony for the RTC offset.
root@tsimx6:~# chronyc rtcdata RTC ref time (UTC) : Fri Nov 18 13:38:36 2022 Number of samples : 64 Number of runs : 40 Sample span period : 254m RTC is fast by : -0.198639 seconds RTC gains time at : -21.674 ppm
In this example, the RTC is offset is -21.674 ppm. Linux expects this value to be in parts per billion, and it should be indicated what value will correct the crystal. Multiply the ppm by 1000 * -1 to get a value we can write to the offsets file. For example:
# Parse rtcdata and get the PPM value
# Eg, with the above example this is:
# PPM=-21.674
PPM=$(chronyc rtcdata | grep ppm | awk '{print $6}')
# Convert to parts per billion and invert the value to apply a correction.
# Eg, with the above example this is:
# PPB_CORRECTION=21674
PPB_CORRECTION=$(echo "scale=0; ${PPM}*-1000/1" | bc)
echo $PPB_CORRECTION > /sys/class/rtc/rtc0/offset
After writing the offset, this is stored in flash in the emulated RTC and will persist between reboots. This should not be written constantly as to not wear the flash. If this is being written often, the driver could be modified to remove the flag that specifies this should be saved in flash, and then it will be loaded from ram only.