Hi, i'm using an RTC in my arduino project for keeping time even when it's reset.
In my code i read the time from the RTC in setup, then i sync it to the arduino's time with the Time library. Every time its midnight, i sync it again for precision.
My question is whether this is the best way to use the RTC. I was thinking about reading it every second with a software interrupt and just use that as my time, instead of also using the Time library
Thanks!
depends on the number of interrupts on your system as these affect local time keeping.
Furthermore depending on the accuracy you need, you can read the RTC once per hour or per day.
Note that the accuracy of RTC's is also limited, some drift more than others.
JoeWawaw:
In my code i read the time from the RTC in setup, then i sync it to the arduino's time with the Time library. Every time its midnight, i sync it again for precision.
My question is whether this is the best way to use the RTC. I was thinking about reading it every second with a software interrupt and just use that as my time, instead of also using the Time library
This doesn't sound like a good idea at all, and it certainly depends on the RTC you are using and the accuracy you need, neither of which are mentioned. For starters you imply you are using two clocks, neither if which may be very accurate, but one is dependent on the other.
Most projects get by with one clock, so you might explain why you need this to be so complicated. If your needs are valid, you are probably still going about it the wrong way, and I bet you also have the wrong clock.
Nick_Pyner:
Most projects get by with one clock, so you might explain why you need this to be so complicated. If your needs are valid, you are probably still going about it the wrong way, and I bet you also have the wrong clock.
Many projects use the Time library. The point of the Time library is track time using epoch time
which is really the best way to track time as it makes doing many other things much easier.
The Time library integrates with several other libraries like TimeAlarms and TimeZone for additional
capabilities.
The value of epoch time is it gives you a universal timestamp that is totally independent of
time zone.
If all that is ever needed is to display a local time in human readable form and things like
timestamps, or alarms, or other time offset type calculations are not needed, then epoch time and hence
the Time library is probably not necessary.
Just set the RTC to localtime and read it whenever you need the date/time.
The Time library tracks time the same way unix does, it tracks time based on the number of seconds
since midnight Jan 1970 UTC.
When using this type of epoch time, the timestamp (time_t values) makes calculating
time deltas as easy as simple addition or subtraction. Such is not the case when using
human readable time formats - which is how the RTCs track time.
Just think of how to calculate something as easy as 1 minute from now.
With epoch time you take the epoch time of "now" and simply add 60.
With human readable time, you have do all kinds of checks for roll overs of
minutes, hours, years, months, years, and even leap year stuff comes into play.
With epoch time everything is seconds until you need it to be human readable and
then it gets converted.
Once the time in the Time library set, the Time library uses the millis() clock to track time.
In order to have better accuracy than the AVR clock,
the epoch time down in the Time library will need to be periodically synchronized to something more accurate.
The Time library has the ability to configure a routine for synchronization and how often call it
using setSyncProvider() and setSyncInterval()
The library includes examples for how to use it.
Depending on the accuracy of your AVR clock, syncing the time at midnight might
still allow quite a bit of drift.
Rather than syncing at a specific time, it might better to sync it periodically using
the sync provider functions in the Time library. Sync it every so many minutes
5, 10, 60, 120, etc... whatever you think provides the needed accuracy.
As rob mentioned some RTCs drift more than others,
The DS3231 is one of the better ones as it is temperature compensated.
--- bill
You might want to check out the library RTClib.h GitHub - adafruit/RTClib: A fork of Jeelab's fantastic RTC Arduino library
I use it with my DS1307 RTC modules.
With RTClib.h the call DateTime now = RTC.now() contains now.unixtime() which I understand to be a "kind of" unix time. From review of the library, I think it is an unsigned 32 bit number, and I have cast the variables which are assigned this value as unsigned longs. What is coming back(the last time I checked some time ago) is a 10 digit number 1399XXXXXX (1.399 E9). I don't know if it will get to 4,294,967,295 or 2,147,483,647 and if it rolls over in 2038 or somewhere in a farther world is of no real concern to me.
It may not be exactly the epoch time given by the Time Library, but using now.unixtime() with RTClib keeps things simple, with small library overhead, and has certainly simplified programming from when I tracked and calculated daily rollover using the native hh:mm:ss data format of the DS1307.
Yea, I decided to use only the RTC without the Time library. If ever there are any significant drifts in my RTC time (i dont need to be precise to the second) i'll rewrite the time using a wirless module thats included in my project (nRF24l01+)
Thanks guys!
That sounds pretty wise.
I just use DS1307s with no libraries and no worries. Jack Christensen is the guru about temperature problems but I find that, in normal and reasonably stable room temperatures they typically gain about four minutes in three months, which I find manageable.
There is often no need for split-second accuracy. The clock may simply be a way to distinguish one reading for another, and a means for creating filenames.
I have a DS3231, but I have never bothered to use it because of its physical size, and lack of real need, but I understand they are considerably more accurate and they use the same software.