Software-based temperature compensated timekeeping

Idea: With temperature data, a microcontroller can partially compensate for temperature-related oscillation variation in a quartz crystal.

Motivation: When attempting a redesign of the Ice Tube Clock, I was unable to incorporate the TCXO modification on the board for temperature-compensated timekeeping. But I noticed a temperature parameter in the clock crystal datasheet relating error (ppm) to temperature (°C). A quick Google search revealed a Wikipedia entry explaining that relationship, which gave me hope that software temperature-compensation might be feasible.

Experiment: To explore that idea, I wired an ATmega328P chip to a watch crystal, TMP36 temperature sensor, and the pulse-per-second output of the Adafruit Ultimate GPS module. On the software side, the ATmega328P outputted the average temperature and number of crystal oscillations at 100 second intervals via USART. I placed the circuit in a portable cooler. A laptop running outside the cooler (at room temperature) recorded data and provided +5v USB power via an Adafruit FTDI friend.

To acquire data, I slowly heated the cooler to 50°C with an incandescent light bulb, slowly cooled the cooler to near freezing with ice packs, and finally, allowed the cooller to return to room temperature.

Results: The data were analyzed and visualized with R:

In the plot above, the data points represent temperature-frequency observations, and the yellow line represents a linear fit to a second order polynomial. The fitted coefficients on that polynomial correspond to a center frequency of 32.76902 kHz, a center temperature of 21.3°C, and a beta (also called "parabolic coefficient" and "frequency stability over temp") of -0.0344 ppm/°C². Those measured parameters are within the crystal specifications: a center temperature of 25±5°C and beta of -0.0340±0.006 ppm/°C². I was surprised at the huge error on the center frequency... the datasheet specified an ideal frequency of 2.768 kHz but gave no range on error. I think I now understand why!

EDIT: The datasheet frequency figure of "2.768" above was a typo. It was supposed to be "32.768", but that's still below the y-scale on the above plot! That's a huge amount of systematic error!

Interpretation: Systematic error (i.e., error on the center frequency) can be easily compensated for in software. Thus, temperature compensation only needs consideration of error from the center frequency:

The data points represent error derived from the empirical measurements. The yellow line represents the corresponding parabolic fit. The blue line represents what the ideal parabola would be given the ideal datasheet parameters for center temperature and beta.

If clock software can determine temperature, it can compensate timekeeping assuming the ideal parabola as specified by the datasheet parameters (blue curve above). The chart below illustrates the effect of that compensation:

The red data points represent the measured crystal error. The blue data points represent the measured crystal error after temperature compensation assuming the center temperature and beta specified in the datasheet. The red lines represent the theoretical minimum and maximum error given the range of the center temperature and beta specified in the datasheet. And the blue lines represent the theoretical range of error after temperature compensation.

Summary: Give these data, I suspect that software temperature compensation can compensate quite well for temperature effects. Within a reasonable temperature range, I am hoping for an error of less than 10 ppm--comparable to the 7.5 ppm of the DS32kHz TCXO used in the TCXO mod.

The empirical observations (data points / crosses in the plots) in this post are on a single crystal during a single evening. To prove that software temperature correction is a reasonable alternative to a TCXO, I would need to try many crystals over a long time period (months or years). But the theoretical calculations (lines) are based on the datasheet values and should be correct. Those data also support the idea that temperature related effects can be compensated for in software with knowledge of temperature.
Last edited by jarchie on Sat Nov 02, 2013 10:38 pm, edited 1 time in total.
--John <www.jarchie.com/email>

jarchie

Posts: 595
Joined: Sun Jun 24, 2012 2:16 pm
Location: Santa Cruz, California, United States

Re: Software-based temperature compensated timekeeping

Nice work as always John. Are you planning to incorporate this into one of your Ice-Tube mods?

Posts: 81551
Joined: Sat Feb 07, 2009 10:11 am

Re: Software-based temperature compensated timekeeping

adafruit_support_bill wrote:Nice work as always John.

Thank you!

adafruit_support_bill wrote:Are you planning to incorporate this into one of your Ice-Tube mods?

I hope so! The code for software temperature compensation might be functional now, in fact. But I'll feel better when it has been better tested and if no one finds any fatal flaws in my reasoning. But here's the current status of this mod:

Today I pushed code for software-based temperature-compensated timekeeping using the DS18B20 temperature sensor in parasitic mode on the ATmega328P PC1 pin of the Ice Tube Clock. (I couldn't get the TMP36 to measure temperature accurately. My guess is that electrical noise from boosting limits the ATmega328P analog-to-digital converter accuracy.) The new code is available in the xmas-b branch of my xmas-icetube alternative firmware project.

Unfortunately, I have been committing to the xmas-b branch without testing the code on the official Adafruit Ice Tube Clock--only on my hardware revision. When I'm convinced the new code is working well, I will check that it still works on Adafruit's Ice Tube Clock v1.1 and merge the xmas-b branch back into master.
--John <www.jarchie.com/email>

jarchie

Posts: 595
Joined: Sun Jun 24, 2012 2:16 pm
Location: Santa Cruz, California, United States

Re: Software-based temperature compensated timekeeping

So far this hack seems to be working well and code for the Ice Tube Clock has been merged into the xmas-icetube master branch.

As an easy test, I ran two Ice Tube Clocks side-by-side: one with the hardware TCXO mod and the other with a custom board using the software TCXO method described in this thread. Both clocks also used automatic drift correction to compensate for systematic timekeeping error. Over about a week, the hardware TCXO clock drifted by ~1.5 seconds (~2.5 ppm error), and the software TCXO clock drifted by only ~0.5 seconds (~0.8 ppm error)!

Although the results are only anecdotal, they do suggest that the combination of automatic drift correction and software TCXO can keep accurate time. :-)
--John <www.jarchie.com/email>

jarchie

Posts: 595
Joined: Sun Jun 24, 2012 2:16 pm
Location: Santa Cruz, California, United States