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.