AVR Freaks

A nice alternative seems to be the internal RTC of the Xmega (we're using the Xmega 256a3). If we could use that we could fully eliminate the need for the external RTC.

Are you using an ATXmega256A3 or the Xmega256A3U:

The A3U's RTC can be clocked by:

An external 32 KHz Xtal

An external clock signal

A 32 KHz Internal Oscillator

A 32 KHz Ultra Low Power internal oscillator, (which is less accurate...)

The 256A3 data sheet also shows the internal 32KHz Osc, and mentions it as a clock source for the RTC, and it is in the Xmega A manual.

So, I think it should exist in the chip, and be usable.

Have you tried configuring it?

(Enable it, wait for it to stabilize, select it as the RTC source, etc.)

To answer your specific question, I do not see a straight forward way to use the External (4 MHz Xtal in your case) clock as the RTC clock source.

(But it looks like you should be able to use the internal 32 KHz clock, without an external 32 KHz Xtal, so you should be back in business!)

JC

I build similar products, sensors that live underground for 5-10 years running on batteries.

Did you calibrate the XMEGA's internal temperature sensor? There is a one point factory calibration at 85C, but to get any kind of accuracy you need to do at least one other point, ideally close to operating temperature. You might then be able to calibrate the internal 32kHz oscillator and get some kind of useful accuracy. How good do you need? 30 minutes a year might be possible that way, assuming your environment is similar to mine (utility pits) where temperature changes are relatively slow.

To calibrate the 32kHz RC oscillator, I'd suggest doing a factory calibration against an accurate reference (say 10MHz) and then using a lookup table based on the temperature profile given in the datasheet. You could also try to do runtime calibration by comparing it to the 4MHz clock.

Perhaps you could characterize the DS1374C below 0C and compensate for its error too.

The best option from a timing accuracy point of view would be to make a little carrier PCB that matches the footprint of the DS1374C, stick a proper TCXO on it and attach that.

One thing about calibrating the RC32K oscillator though, the resolution of the calibration register is rather low. You won't get good results over a number of sample devices unless you do some dithering. It's not terribly hard, although there is of course a cost in terms of energy consumed, but I did something similar on a 10 year battery life product.

Depends on how often you wake to 4MHz, and how much time you run for ?

ie There are systems that improve on classic/poor  32.768kHz Crystal tempcos, by running a higher Xtal in bursts, and calibrating a internal RC osc.

This also assumes you can capture from the 32kHz signal

Obviously, you need at least one full cycle at 32kHz and at 4MHz you resolve that to one part in ~122, which is not great.

To get to a measure precision of 100ppm, you need a 4MHz run time of > 82 RTC cycles, or 2.5ms, or 0.1% is ~ 244us   - How much do you need ?

You then try to do that calibrate as infrequently as you can, to save energy - eg 2mA  added for 2.5ms every 25 seconds, adds 0.2uA to your power budget. (2m*(2.5m/(25))  = 2.0e-7)

You are lucky, your temperature slews will be very slow.

It is not needed to trim the RTC-RC, as that may actually complicate the long-term maths, you just need to arrange the time to the next measure cycle, and total that in SW.

If you want that 512 sps to be a correct average, then you would derive a fractional swallow rate - eg 64/65 or 63/64 (etc) from ~32kHz, and the ratio of 64:65 sets the long term average.

eg a Swallow NCO running at 16b fractional part, 32kHz to 512Hz, I make has a LSB step precision of  0.238ppm, way better than that 2.5ms capture precision.

You could do a band-aid for existing products of a hybrid, that checks for external RTC and uses internal if it is missing.

If doing a new PCB, I'd allow footprints for a choice of  a RTC crystal, or one of those new 32kHz oscillators mentioned above.

Just noticed that, - that improves your capture by a factor of 8, so one RTC cycle is one part in 1024, and ~100ppm needs 10 RTC Cycles capture-time, for 102ppm result.

34 Cycles capture gives a 15b result, for 30ppm LSB and ~1.04ms required capture time.

Good point, I did not think of that. However, as you point out, you will need to run the main clock, which in turn means higher power consumption.

TCXOs are really cheap now. I've been using EME32T3 which are only €0.70 in smallish quantities. At this point I view crystals as an ultra low-cost "better than nothing" option.