Expected Clock drift for Electronic Devices with no correction

[sacherjj]

I see that quartz watch drift can be on the order of 15 seconds per 30 days, but can't find any possible drift for typical RTC chip based time and date used in consumer electronics devices.

We are looking at a device that will have no network connection of any time, other than occasionally to their like devices in the field.   So we have no method of using an NTP server or cell tower and getting a time fix.  I'm trying to figure out a worse case scenario for date shift and if it will be enough to mess up plans for exchanging data.  (We will be passing data between devices for eventually making it to one of these devices that is brought to a syncing station with internet to upload this to the master DB.)

I'm trying to determine if worst case is acceptable.  Or if we look at a more expensive hardware solution for a time base with less drift or a software solution that takes into account this possible inaccuracy.

When I look at a combination chip like http://www.datasheetcatalog.org/datasheet2/b/0ff4cxsj6xtos2tzj8jtq8rekofy.pdf 

It looks like a 40 ppm error could be worse case for the temperature swing we are expecting, according to the graph for typical outside temp ranges of -15 to 50C.

So 1 million seconds is around 11.6 days with +/- 40 seconds in that time frame.  Is that math correct for an application like this?

[bingo600]

Haven't checked the math.



But the Maxim DS32kHz (Series) gets good reviews for RTC use :
Time-Nuts would know that this statement from PHK means the chip is "quite decent"
http://www.febo.com/pipermail/time-nuts/2011-April/056180.html


Maxim table - see bottom
http://para.maximintegrated.com/en/results.mvp?fam=osc_mod


Pure 32Khz Osc
http://www.maximintegrated.com/datasheet/index.mvp/id/2940

And RTC with the above inside (and better specs)
http://www.maximintegrated.com/datasheet/index.mvp/id/4051
http://www.maximintegrated.com/datasheet/index.mvp/id/4627
http://www.maximintegrated.com/datasheet/index.mvp/id/4984


Hmmm: It just struck me ... You aren't designing the RTC , just determining worst case ?

Well consider the above anyway , and use it to sync the consumer thingy (like with NTP)


/Bingo

[sacherjj]

Well we are possibly designing the RTC, as we are designing the whole product.  I'm trying to do some back of the napkin order of magnitude calculations to see if a non-updated clock over a number of years would cause issues.

Those links are helpful though.  I'll read through them. 

[PA0PBZ]

Math seems correct, what accuracy are you looking for?
There's a lot of very accurate clocks up in the sky, but I don't know about your power/cost etc.

[bingo600]

I didn't think you would spend a "Kazillion $$" that's why i mentioned the maxim ones.

But if you have the $$ , then symmetricom has the "chip"
http://www.symmetricom.com/products/frequency-references/chip-scale-atomic-clock-csac/SA.45s-CSAC/

/Bingo

[sacherjj]

Math seems correct, what accuracy are you looking for?
There's a lot of very accurate clocks up in the sky, but I don't know about your power/cost etc.

We are doing sort of a adhoc mesh networking between these devices to find out what version of software each have and update each others.  For this we maintain a small DB of a device's serial number and last time we "saw" it and the version it had.  These will be in third-world countries and only a few will ever get to a sync station and push this data to the master DB and get software and data updates.  Then the software and data will update like a virus to all the devices it meets. 

It isn't necessarily about getting to most accurate clock, but more characterizing the clock to see if we can accomplish what we want with it or if we need software adjustment or better quality RTC.  I'm guessing that we will probably maintain an offset value that is updated by looking at each device's time that it runs into and weighting the "accuracy" of the time based on how long it has been since it had a valid update at a syncing station.

Just wanted to sanity check my thoughts on this.  An error of 21 mins a year for a couple dollar per unit clock worse case (with more likely case much under that).  We could probably handle even more than this.  So looks like it won't be a show stopper of any sort.  One less things that could topple the house of cards that is system design. 

[jerry507]

The math is correct, but characterizing the frequency is a bit annoying. As far as I know you have:

1. Initial tolerance, which is usually what the number you see is (10,20,etc ppm +/-)
2. Age related drift, usually given as drift over the first year
3. Temperature drift

#1 you can tune out on the line and maybe even pre-adjust for #2, but #3 is only controlled by using some kind of oven.

If you need to get more accurate you can always just use a dedicated rtc or the rtc built into your micro. As far as I know there is essentially no difference in accuracy between a microcontroller rtc and a dedicated chip. Maybe someone else can provide more insight on that.

[sacherjj]

It looks like some integrated RTC solutions use temp sensors to adjust and some use age to adjust crystal aging, etc.  Definitely an interesting subject.

Thanks for all the info and thoughts all.