Hi,
How can a DS1307 or any other RTC chip claim to maintain time with any given accuracy
when it is driven by a crystal?
Printable View
Hi,
How can a DS1307 or any other RTC chip claim to maintain time with any given accuracy
when it is driven by a crystal?
The accuracy is not determined by the chip itself. The accuracy is determined by the crystal.
The DS1337C has a built in OSC.
Saves you from setting up an accurate crystal.
I keep showing my age. I keep using a DS1307
With an accuracy of..??Quote:
Originally Posted by mackrackit
Better or worse than a good crystal? (10-20ppm?)
Just curious, but too tired to go hunt up the 1337 data sheet...
steve
I guess it is about the same as a good crystal.
Quote:
DS1337C ONLY
The DS1337C integrates a standard 32,768Hz crystal in the package. Typical accuracy at nominal VCC and +25°C is approximately +10ppm. Refer to Application Note 58 for information about crystal accuracy vs. temperature.
Well, without reading AN58, it sounds comparable to a decent crystal.
Or is it..?Quote:
at nominal VCC and +25°C
Sigh... so many data sheets, so little time...
steve
Ok, I don't know why I thought it was the chip datasheet that claimed a certain degree of accuracy.
If you want precise time keeping, an idea would be to use a cheap GPS module with PPS signal output (1 pulse per second).
Ioannis
I use on average a couple of thousand DS1307's annually. If it's better than 15 minutes per year (and that's matching it exactly with a 12.5pF xtal), you've got a good one. For the money you pay (say around $0.75 in quantity) they are totally rubbish.
I keep meaning to program up a 18F part with a secondary 32kHz xtal and have a background interrupt timekeeping program... finally consign the 1307 to anals (deliberate spelling) of History.
That is interesting. I only use around ten per year so I do not have the kind of data you do, but I typically see errors less than a minute per six months.Quote:
Originally Posted by Melanie
Maybe the built in crystal in the DS1337C is better???
I haven't tried that part... my only external RTC usage is in old products that were designed some years back. I almost certainly won't go that route for future projects. The reasoning for that being...
(1) Most 18F Parts for example have heaps of spare capacity - both in program space and performance.
(2) You can select a micropower part that doesn't suck a lot of juice
(3) With little effort you can redesign your PSU so that it powers the PIC all the time, whilst powering-off the remainder of your device, so the PIC remains quiesced on just minimal residual backup Battery Power.
Ultimately the name of the game is to reduce the parts count...
(a) Removes the cost of the parts (which considering an RTC is half the price of a decent PIC doesn't give you a great deal of bang-for-buck).
(b) Makes the PCB smaller (thereby cheaper)
(c) Removes the Labour cost involved in mounting the parts, in ordering the parts and in inventory.
(d) If it's the only I2C device, you lose two pull-up Resistors as well.
Eight or even six years ago, the state of electronics was such that your microprocessor needed all the external help it could get. This has changed. Today, you chose the part that could do as much of the job at hand that you can possibly make it do. There isn't the budget for unnescessary extravagence - you need to leverage maximum profit and in so doing need to think clever.
Today if I have a production run of say 1000 pcs of a new product needing an RTC, I can earn an extra $750 in return for two hours worth of programming - I'll do it. Wouldn't you?
Yup, now to get that 1000 part run. :oQuote:
Originally Posted by Melanie
Melanie, I remember you bagging them in another RTC thread.
My use of Maxim/Dallas RTCs is 0.056 per year, but that figure might be rising
I wonder if the calender on the RTC can solve the problem of converting UTC time to a local time where the date is different for part of the day.
Best example is it's 1:00 am, 1st of March but to convert to local time I might
have to decrement the date and be left wondering if it is a leap year, etc.
Does the possibility exist of using the RTC to test for a valid date just by trying to set it?
Does that help?Quote:
The date at the end of the month is automatically adjusted for months with fewer than 31 days, including corrections for leap year.
The DS3231 also has an internal crystal.
But the tolerance is +/-2 PPM, which is about 1 minute / year.
DS3231 - Extremely Accurate I²C-Integrated RTC/TCXO/Crystal
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4627/t/al
<br>
Extract from my routine for setting T&D... for convenience, I set YEAR, then MONTH and finally DAYS... here I set the maximum number of Days you can increment the DAY count to...
Stupidly, the DS1307 can be set for Day 55 in month 55 in year 55. It's just a brainless incremental counter that checks for validity once it rolls past midnight. So you CAN have a DAY of total rubbish before it becomes sensible.Code:RTCDayMax=31
If RTCMonth=4 then RTCDayMax=30
If RTCMonth=6 then RTCDayMax=30
If RTCMonth=9 then RTCDayMax=30
If RTCMonth=11 then RTCDayMax=30
If RTCMonth=2 then
RTCDayMax=28
If (RTCYear&03)=0 then RTCDayMax=29
endif
Well yes... you CAN convert UTC (say from a GPS Data-stream) to Local Time at any part of the globe... the Time difference is simply 1 HOUR per 15 Degrees rotation away from the Prime Meridian (which you can also get from the GPS). It's actually based on 15 Degree wide BANDS the centres of which are 15 Degrees apart from the Prime Meridian. The trouble is, the Great-Circle Meridians comprising the Band edges have been skewed in many parts of the world to maintain the same Local Time across for example whole groups of Pacific Islands or other geographic anomalies which otherwise would put an odd corner of a country or region into another Time Zone. So whilst you CAN easilly work out EXACT LOCAL TIME based on Longitude, without actually containing a Database to correct for the odd skew here and there, you're pretty much, well... skewed!
And then of course you need a Second Database, to hold Daylight Savings information, because different parts of the world have different Dates (and Times) that they switch. The UK for example just had their Summer-Time switch at 2am last Sunday morning. Other parts of the world have already had it - some yet to have it... don't you just love Time? Such a simple subject (dividing the rotation of the planet into equal increments), yet made so complex...
Finally we get to the good folks that need to pray at Sunrise and Sunset... with published Tables and Charts of the exact time of the event based on where on the Globe you happen to lay down your prayer mat. Did any one of the great scholars that compile these charts stop and think that Sunrise and Sunset is effected by ELEVATION and if you happen to be at the bottom of a North-South running mountain range on the Western side at Sunrise or the Eastern side at Sunset affects the outcome quite CONSIDERABLY? Nope! Anybody know if it messes your chances of getting to Heaven if you get it wrong?