Pages: 1 2 [3] 4   Go Down
Author Topic: Keeping accurate time  (Read 14384 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Edison Member
*
Karma: 3
Posts: 1001
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

1) Keeping accurate date/time without main power supply.
2) The Arduino is NOT a "real-time" system. There are things you can program that could keep the internal millis() or micros() from keeping accurate time.
3) You want to run something for more than 50 days (for millis) or 70 minutes (for micros)
4) You want to actually know what time and/or date it is in the real world.
If we maintain a count of seconds, we can easily keep track of time for more than 100 years irrespective of millis/micros overflow. Tracking real-time is also no show stopper as it is just a matter of setting initial time as will be required for a RTC as well. Real-time accuracy is a property of the oscillator and not unique to RTC. It is also possible to operate a timer (timer2 on AtMega328) independent of the main clock from a separate external crystal.
 
The main benefit of using a RTC chip as I see it is low power battery operation. A dime-size coin cell battery will keep a DS1307 ticking for 10 years. You can even use the RTC without a crystal as a low cost I2C NVRAM chip to preserve accumulators/state/preferences across microcontroller power cycles or add the crystal to get both time keeping and data retention.
Logged

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 106
Posts: 6373
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

The better RTC chips have built-in temperature compensation, making them more accurate than a normal (microprocessor) crystal oscillator.
Logged

0
Offline Offline
God Member
*****
Karma: 0
Posts: 511
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Yes but the point is that an rtc is essentially a processor too.  Insisting that a cpu cannot keep accurate time is 100% false/incorrect, it is merely a function of the quality of the oscillator, and there are processing strategies that can assist too if it is really important (i.e. read a thermistor).  

And it is far simpler to read a variable from memory and format it, than to figure out how to communicate with a time processor, i.e. DS1306 (and format the results).

They work the same way, oh look, a crystal is also needed for the rtc (duh):


Responses 1-5 are a matter of implementation.  I could see a couple situations why a developer might like an RTC if they are plugging and unplugging things a lot, and reprogramming the cpu, but for a clock with set buttons on it (and most clocks reset on unplugging anyway, so this is feature creep), no need.


EDIT:  The frustrating thing though is the abundance of ceramic resonators.  Arduino was crystal driven when I got involved, and the ceramic resonators and onboard oscillator designs really murdered the idea of onboard timekeeping for the masses, and everybody and their brother wants to build a clock.  So buy an arduino with a crystal if you care about having a semblance of accuracy, or mod it like MarkT, thumbs up there!  http://arduino.cc/forum/index.php/topic,54621.msg391290.html#msg391290 , but if you have a crystal, and are building a clock, the time library was meant just for you, no extra hardware required.

re: uno, they put a crystal on the bleeding com chip, but not the main chip?!?  Sorry guys, but wtf?  You could have even shared the com chip crystal with the main chip if you just wanted to save a few cents:


« Last Edit: June 10, 2011, 07:54:48 am by dcb » Logged

0
Offline Offline
God Member
*****
Karma: 0
Posts: 511
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

...OTOH, the main Arduino controller chip was never intended for precision timekeeping

You joined last february, you are talking out your ass, "never intended", stfu.  The main chip is at the heart of may a precision timepiece.
« Last Edit: June 10, 2011, 11:49:49 am by dcb » Logged

0
Offline Offline
God Member
*****
Karma: 0
Posts: 511
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

people who make up bullcrap statements will be called on it, it isn't personal.  Please try to stick to facts and not dabble in fantasy.
Logged

0
Offline Offline
God Member
*****
Karma: 0
Posts: 511
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

more bullcrap from a newbie who claims to know what the original intent of the atmega was in regards to timekeeping.  I cannot help that you are full of crap, that is your problem, deal with it.
Logged

0
Offline Offline
God Member
*****
Karma: 0
Posts: 511
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

your post count and registration date must have gotten hosed then (speaking of bad timekeeping).  Still it is microcontrollers and logic what make possible small and accurate clocks that can make adjustments, combined with decent oscillators.  But to be in the ballpark you do not need to pimp rtc modules. Use the library, tell vendors to not cut corners on oscillators so you can have a decent timepiece in your arduino by itself.
Logged

0
Offline Offline
Shannon Member
****
Karma: 161
Posts: 10445
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

In fact I got motivated enough to replace the resonator on my Uno board, partly to see how tricky it was to do.

By any chance to you have a part # for the crystal?

Thanks,
William

Just a standard 16MHz crystal I think - there are different suppliers and different grades but most are 50ppm or better.
Logged

[ I won't respond to messages, use the forum please ]

0
Offline Offline
Faraday Member
**
Karma: 19
Posts: 3420
20 LEDs are enough
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

You have to have proper load capacitance otherwise you may be off >100ppm. The datasheets contain the formula for proper matching of crystal load capacitance and the caps.
Logged

Check out my experiments http://blog.blinkenlight.net

Dallas, Texas
Offline Offline
Sr. Member
****
Karma: 3
Posts: 267
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I saw this got pretty heated but I'm chiming in anyways. The original question was about making a clock. The simple fact is, the common resonator absolutely stinks for any reliable time reference over time. Furthermore, a simple MCU with a resonator makes for horrible accuracy. The drift alone is typically extremely noteworthy. And that completely ignores that the MCU only knows a relative time since last power up and not an absolute time reference.

This is why RTCs are so popular. Not only do they tend to have an absolute time reference, they tend to also be reasonably accurate (moreso than a simple resonator), take care of details like days, weeks, months, and especially leap years, and have extremely low power requirements to maintain time without external power. Even better, even cheap RTCs tend to have some form of modest calibration when installed according to their datasheet and more expensive units are both calibrated and actively compensated.

Frankly, creating anything other than the most simpletons of clocks without an RTC is highly questionable, unless its the trip than matters moreso than the destination.

I also read others talking about slamming time corrections from an external source. Be warned this also has some potential issues. If your application is dependent on alarms, relative time, and especially delays, its a great way to either miss them (if using poorly written software), potentially create alarm cascades (if using properly written software), or completely screw up fixed delays. Frequently, SNTP is what people incorrectly refer to when they mention NTP. There is a difference. A good implementation of time management which accommodates for drift will do so via tick interpolation over a finite period of time as well as rejection and error when skew is too large; typically based on accuracy requirements. So for example, if we have 100 ticks of error, it should be slowly interpolated over something like five seconds, minimizing the imposed error over those five seconds. Otherwise, simply slamming in 100 ticks over a 1 tick duration, may cause a cascade of alarms to fire, not to mention completely throw off all relative time measurements by 100 ticks (sleeping for 200 ticks just woke up 100 ticks short). And on real time systems, an alarm cascade can really screw things up royally.

Long story short, any clock should seriously consider even a modest RTC; especially when CPU clocking is a resonator. They have lots of advantages, especially where simple resonators are in use. I have created systems which managed clock skew and distributed time references (SNTP & NTP) for P25 digital radio systems. If you want to point at my low post count, I'll happily laugh in your face. Bluntly, proper time management is a surprisingly deep and complex subject with lots of subtleties waiting to whack the unprepared. Be extremely wary of anyone who attempts to trivialize time management, especially when their sole reference is a resonator. That's not to say CPU counters are without merit, but they can be deceptively alluring for the ignorant.
« Last Edit: July 13, 2011, 12:22:16 pm by gerg » Logged


London
Offline Offline
Faraday Member
**
Karma: 8
Posts: 6240
Have fun!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
creating anything other than the most simpletons of clocks without an RTC is highly questionable, unless its the trip than matters more than the destination.

I agree with that, but point out that a high proportion of the Arduino projects one sees are more about the trip rather than the destination.

At Maker Faire I saw an LED clock that displayed time in base 12 on a charlieplexed 9 by 14 LED grid. However accurate or not that clock may be, the maker was more interested in the fun of getting it to work then using it to tell accurate time.
Logged

Global Moderator
Netherlands
Offline Offline
Shannon Member
*****
Karma: 170
Posts: 12465
In theory there is no difference between theory and practice, however in practice there are many...
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

@gerg]
Thanks for this wisdom, you are right that SNTP and NTP are used mixed. I do too - I'm guilty smiley -

(S)NTP is most used for synchronizing RTC's (or a software datetime lib) in Arduinoland. All RTC (but one)  I know can be set up to 1 second precision, so in practice NTP and SNTP have "too much" precision for them. It would be nice if the millis() or micros() could be set according to the decimal part but unfortunately this is not possible on an Arduino AFAIK. OK one can create NTPmillis() and NTPmicros() that uses an offset or a hardware timer or ...  So in Arduinoland the decimal part of (S)NTP is mostly dropped, and yes sometimes it is used for rounding to which second is nearest. IN fact 99% of the Arduino sketches would just need the Time protocol (RFC868).

The Arduino has little resources and I assume that adjusting gradually for the drift for an Arduino is possible but it would take quite a bit of the resources leaving little room for the main sketch. (please let someone prove me wrong by building an Arduino NTP server library smiley

The one second precision of the RTC mentioned before also means - from observing the apps discussed at the forum - that the RTC is seldom (never?) used for high precision timing, in Arduino context most people use millis() and micros() for this. The time of the RTC is mostly used for display and logging, and yes also for low precision timing like switching on/off the light of an aquarium or so. I see two different kind of clocks working side by side each for their specific purpose. And I think it is not bad.



Logged

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Dallas, Texas
Offline Offline
Sr. Member
****
Karma: 3
Posts: 267
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Please keep in mind I was speaking in generalities. I was purposely trying not to be overly specific. Some of my comments need not necessarily apply to the typical Arduino user. An example of this is one thread slamming in a new time while another thread is sleeping. Concurrency is not likely a typical Arduino user's concern. Though is possible if done via an ISR.

(S)NTP is most used for synchronizing RTC's (or a software datetime lib) in Arduinoland. All RTC (but one)  I know can be set up to 1 second precision, so in practice NTP and SNTP have "too much" precision for them. It would be nice if the millis() or micros() could be set according to the decimal part but unfortunately this is not possible on an Arduino AFAIK. OK one can create NTPmillis() and NTPmicros() that uses an offset or a hardware timer or ...  So in Arduinoland the decimal part of (S)NTP is mostly dropped, and yes sometimes it is used for rounding to which second is nearest. IN fact 99% of the Arduino sketches would just need the Time protocol (RFC868).

The Arduino has little resources and I assume that adjusting gradually for the drift for an Arduino is possible but it would take quite a bit of the resources leaving little room for the main sketch. (please let someone prove me wrong by building an Arduino NTP server library smiley

The one second precision of the RTC mentioned before also means - from observing the apps discussed at the forum - that the RTC is seldom (never?) used for high precision timing, in Arduino context most people use millis() and micros() for this. The time of the RTC is mostly used for display and logging, and yes also for low precision timing like switching on/off the light of an aquarium or so. I see two different kind of clocks working side by side each for their specific purpose. And I think it is not bad.

I agree. Let's not lose track of the fact accuracy and precision is always relative to the purpose and requirements. For most people, accuracy to within a minute per year is acceptable for a wall clock. Whereas, accuracy to +- >2 minutes per week is pretty iffy. Still, for an electronics experiment its likely not a problem at all. For a clock beside the bed, its likely okay for the unemployed or soon to be, by the end of the year.  smiley-eek-blue

Generally RTCs are a reference source of some type. This may include a square wave generator or simply periodic fetching of absolute time whereby interpolation is then used to synchronize CPU timers. As (IIRC) dbc said, there really isn't anything special about RTCs. He's right you can do it on common, non-specialized hardware if your tolerances allow and you use a clocking source which provides the required precision, and then take the time to calibrate and compensate with temp and so on. But then again, RTCs are so cheap, reliable, persistent with low power requirements, frequently with wake on interrupt (frequently allowing for additional power savings), typically fairly accurate, sometimes even highly precise, and all too often completely mitigate a whole slew of subtle software time management bugs, they become really hard to overlook - especially when no other external absolute time reference is readily available (time, sntp, ntp, etc). Whooo! That's a mouthful.

IMOHO, part of the confusion here people are conflating time with timers. Relative timers are easily possible without absolute time. Absolute timers require absolute time. Time, SNTP, NTP, and RTCs are all common sources for obtaining an absolute time reference. So the question becomes, assuming the easy path, do you require absolute time or relative timers; or both. IMOHO, if you require absolute time, your solution needs to include one or more of Time, SNTP, NTP, or an RTC. Again, you're requirements will guide, if not dictate.

Like with most engineering tasks, this is no different. Define your requirements. Understand the problem domain. Craft a solution. My primary purpose for chiming is is that many people don't define their requirements and frequently when they do, time is such a simple construct we all know, so its frequently falsely understood the domain is mastered. As such, crafting a faulty solution is all too easy.

As I've pointed out in another thread, time is subtly hard to get right. As long as you don't underestimate its complexities and truly define your requirements, you'll likely be okay. Otherwise, expect a bumpy road and lessons learned.

« Last Edit: July 13, 2011, 12:15:15 pm by gerg » Logged


Left Coast, CA (USA)
Offline Offline
Brattain Member
*****
Karma: 331
Posts: 16520
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
As I've pointed out in another thread, time is subtly hard to get right. As long as you don't underestimate its complexities and truly define your requirements, you'll likely be okay. Otherwise, expect a bumpy road and lessons learned.

I agree. "Accuracy" is a term that is vastly undefined and relies on too many unstated assumptions to be useful in most conversations. Unless you are in marketing where there is much to gained by riding on those unstated assumptions.  smiley-wink


Lefty


Logged

Global Moderator
Netherlands
Offline Offline
Shannon Member
*****
Karma: 170
Posts: 12465
In theory there is no difference between theory and practice, however in practice there are many...
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
time is subtly hard to get right
Yeah definitely hard, I did some research upon the NTP protocol and the work of Mills years ago. To my suprise (then) the NTP uses statistics to handle latencies of the network and the server. For me that looked like "the first signs of some variant of the Heisenberg principle"  smiley-wink

I recall that Mills started to investigate NTP for intersolar communication (one time ref per solar system, NASA) to synchronize satellite data. Depending on the relative speed of things he needed to compensate for relativistic effects.

Definitely hard.
Logged

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Pages: 1 2 [3] 4   Go Up
Jump to: