next topic »

[Reply #15 on:]

An RTC has a full calendar (normally 200 years), you do have to set it up of course but once done as long as you keep the power to the chip all you have to do is read the time and date.

but can count more accurately

That depends on the chip used. Bottom line is an RTC and the Arduino are both dependant on the quality of the crystal used and the temperature. In general they will have about the same accuracy but it's possible to get RTCs with internal temperature-compensated oscillators (TCXO), these are a lot more accurate (2-3ppm) than the standard RTCs and Arduinos (maybe 20-50ppm).


______
Rob

[Reply #16 on:]

Sounds neat.  If the project has an Ethernet shield included anyways, is there an (dis)advantage of using an network time service (NTS) instead of an RTC, say, if the script needs to execute at the same time each day?

My guesses:
NTS won't need a battery backup if power is lost, since the code can reset/retrieve the time on next boot up.   
Looping code could even periodically check the NTS to resynch it's internal time.

RTS avoids the dependency on an external service and a internet connection
I assume there's lower overall power consumption with this IC.
Reduced code complexity

Any others?

(hoping not to hijack the OP's thread, as this does seem relevant to good Longterm programming decisions and practice)

[Reply #17 on:]

I've not used NTS but all the pros and cons you mention are correct I would say.

if power is lost

It's easy to battery back an RTC.

One thing is that an Enet shield uses a lot of power AFAIK, for battery supplied gadgets that would be a problem, an RTC uses two fifths of five eights of half a fempto watt.

Also RTCs are now included in the modern 32-bit chips, so you don't even have to add anything except a 32kHz crystal (unless you need the super accuracy of a TCXO).

______
Rob

[Reply #18 on:]

I would definitely not use NTP as a replacement for an onboard clock, if what you need is a clock.

With an RTC, you always have a running date/time.  It has a coin-cell backup battery to make sure it keeps ticking even when the power's off, or your code locks up, or whatever.

Without the RTC, your code will need to keep track of time somehow.  Usually, this is by setting an interrupt timer to fire once a (e.g.) second and increment a seconds-since-epoch counter, or do date math on the fly to increment minutes, hours, days, months, years.  The accuracy of this method depends on how reliable that interrupt timer is (which is in turn dependent on the crystal driving the timer -- already covered adequately here), and of course how quickly you can respond to that interrupt and update your time variables.

This is inherently sloppy as compared to a dedicated RTC chip.  But, it's plenty good enough for a lot of projects.  If your project is reliant on time enough that you're considering either an RTC or NTP, you should probably go with the RTC.  If you're already using the Ethernet shield for some other aspect of your project, maybe adding NTP isn't such a big deal, but it's a huge waste if your primary point of network connectivity is to get the time from your network.  And less accurate, due to the software clock implementation described above.

Plus, what do you do before NTP is available?  Does it matter if the time is not known for some period?  What if NTP is down, or the network is misconfigured?  NTP doesn't seem too difficult, but it's not exactly trivial.  Far easier to query an RTC.

Now, if precision time is essential to your project, maybe it's worth having both the RTC to keep the time consistent, and NTP to keep it accurate.

[Reply #19 on:]

@SirNickity
I have used millis very less in the program. Now that I think of it I guess RTC could be a better option Not much heavy work. Changing a few lines of code should do the trick...

[Reply #20 on:]

I've used GPS to calibrate my Arduino clock to nearly 1ppm.  It's stable and consistent at a given temperature.  The calibration process takes about an hour.  With GPS you do not need an accurate RTC.  Even when you briefly lose the signal.  <10ppm.