Compensated Temperature RTC

I am planing to do that with a LaunchPad for MSP430G2231. My scheme is as follows.

I assume the “32768 Hz” crystal is not really 32768 Hz but 32760+Delta Hz, where Delta consists of a constant part unique to that particular crystal and a variable part depending on temperature (and possibly voltage, age, or other things).

I will use this 32760+Delta Hz to clock the Timer to produce a 1 pps tick. But since Delta is not necessarily an integer number of Hz and the Timer can only count in integers, I will do something in the ISR to reduce accumulative error.

I will use the ADC to estimate the temperature and calculate an integer Delta in units of 1/256 Hz instead of whole Hz. I will define another integer Accum and initialize that to 128 (one half of 256 for rounding). Inside the ISR, I will do this:

(a) Accum = Accum + Delta;

(b) Use (32760 + Accum / 256) for Timer to count.

(c) Accum = Accum % 256; for next ISR.

I do not have any accurate frequency reference. But I can synchronize this RTC with a wall clock or something. A week later, I can check it and estimate the error within one part per million.

I think OCY's approach is similar to what I've seen done for many RTC drift compensation techniques where the error is mostly considered predictable and stable.

One doesn't try to correct the actual oscillation frequency better than a certain tolerance considered acceptable for factory tuning accuracy at a given set of temperatures and

over a given set of voltages and over a given period of calibration / test time.  The tuning may be done by adjusting the crystal load capacitance values in many discrete crystal oscillator designs.  Then one has some small residual error of X parts per million where the magnitude of the likely correction might well be in the small number of seconds per week or milliseconds per day range.  If one can observe factors like supply voltage, temperature variations, et. al. with estimated correction coefficients relative to changes in these parameters, one can just predict an average expected error due to the static and dynamic frequency errors and then make small compensation corrections for these errors infrequently when they add up to enough of an error that one can correct for them precisely enough given the limited precision to which the RTC time is internally calculated / stored -- seconds per week, seconds per month, milliseconds per day, whatever. 

A good source of precision time reference is a GPS receiver if you have one that can output to a PC via bluetooth or a serial port, the GPS time is generally accurate to a small fraction of a second assuming the GPS signal is locked on.  Some GPS receivers even output a hardware 1 pulse per second waveform which can be used to discipline an external timing system.

Another option is the WWV or WWVH broadcast radio stations since these broadcast a voice and a digital / analog time reference accurate to within a few milliseconds or (usually much) better by the time you account for the receiver and the propagation delays and such like.

Just using 'NTP' or 'Internet time' will also keep a PC's clock accurate to within a few fractions of a second using a multitude of relatively precise time servers on the internet and compensating for the propagation delays of the traffic et. al.

The MSP430F54xx series has an RTC timer module which allows for adjusting the count frequency by several PPM in steps of a few PPM. The actual adjustment is done by skipping/adding some divider steps for every Nth second (details in the datasheet), so the adjustment of the clock count is done on hardware. All you need to do is 1) finding the absolute error at room temperature (this is a calibration step) and the differential error cause by temperature and change the adjustement registers from time to time.
The temperature may be measured by the internal temp sensor, but the effect of self-heating (which does not apply to the crystal) needs to be taken into account. It's not a temperature offset butrather has a negative temperature coefficient.

As for the calibration, some (many) years ago on the C64, I mass-produced an RTC for the cassette port. (using an I2C RTC chip I still use in recent projects). The setup required a load capacitor of 12pF and I used an adjustable one.
I synced the clock with the 1MHz clock of the C64 (Which was quite stable, but had an unknown error), then looked for the resulting error one week later. With this I adjusted the sync point and the late produced devices ran with an error of a few seconds per month. Better than any wall clock (there were no radio-controlled wall clocks available at this time) and definitely better than any wrist watch or PC RTC (without NTP).

Today, I have a temperature-compensated 10MHz frequency counter and trim the capacitor based on its readings. The results aren't much better than the 'observation-based' calibration I did 25 years before.

Sometimes, much effort is too much effort for the desired effect :)

Thank you for your answer. I use a MSP430F149 so I haven't a RTC timer module, but I'll try to adjust the capacitor one by one. For the temperature, I've a external sensor so I haven't the self-heating effect and I'll use this one to correct the frequency.

Hello,

To create a 1 pps tick, do you use the timer A? And your timer interrupt create the one seconde ISR?

Your idea is nearly the same than this document:

http://focus-webapps.ti.com/general/docs/sitesearch/searchsite.tsp;jsessionid=43OSK10SS1XUTQC1JAWCM4Q?selectedTopic=1653260327&numRecords=25&searchTerm=slap107&statusCode=null

I'll try to write the code to do this method.