Hello.
I've been looking for this RTC component for a while so to make an alarm but I cannot find it onboard. All forums i've seen use a DS1377 chip to get the time and date. Is there an onboard RTC and where can I get more information about how to program it?
Thanks!
There is no on-board RTC on a 2009.
But you can use the time library to keep track of time.
You will need a way to set the time in the library but then the library will
track it from there.
http://www.arduino.cc/playground/Code/Time
--- bill
Timer/Counter2 is designed to allow for an external crystal (they mention a 32 kHz watch crystal). Unfortunately the pins used for TOSC1 and TOSC2 are the same pins used for XTAL1 and XTAL2: the 16 MHz crystal for the system clock. If you switch to using the 8 MHz internal RC clock for the system clock you can put a high-precision crystal of 2 MHz or slower (less than 1/4 the system clock rate) on TOSC1 and TOSC2 to get a high-precision real-time clock.
You could also use a high-precison 16 MHz crystal for the system clock and just use the existing millis() etc.
In both cases you will have to provide continuous power to maintain the time.
There is on my Loading... 
And an XBEE too
I have a RTC library and some example code for the DS1337 on my site.
(* jcl *)
You can add a DS1307 RTC to your arduino. BTW, I have a shield with LCD and RTC etc. Here is my alarm clock project:
http://liudr.wordpress.com/?s=alarm
You're welcome to take the code.
liudr:
You can add a DS1307 RTC to your arduino.
Or a ChronoDot, or a DS3234 (on a breakout board, if you want something simple), or one of a number of RTCs. Or get it from a GPS shield, or from WWV. Lots of ways to skin that cat.
GPS works well outside but inside of a building you will have trouble getting a lock. I'm not sure if the clock will be any good from gps.
My board has an RTC & SD socket as well
www.crossroadsfencing.com/BobuinoRev17
and some sample sketches to read/write the DS137 registers
Looking at the datasheet, the ATMEGA168 has an internal 32khz RTC, but I think it needs constant power and I'm not sure how to enable it using Arduino code
Looking at the datasheet, the ATMEGA168 has
the ability to configure Counter/timer 2 as a real-time counter.
@fou2:
The RTC is just a piece of the overall system needed to have a time on a project. Most of the board manufacturers for RTC reference a sketch that you must load and run to set the clock which is generally backed-up by a lithium battery. Then you must reflash the Arduino to use your code and read the time from the RTC. But what if you need to reset the clock?
Another way to think of a solution is to think about if a RTC will ever need resetting. Likely. How... run a sketch? What about using a TV controller (one of the universal kinds.) With IR you can then decode the key inputs into numeric entries. Now, all an Arduino project needs to do is have a little code routine to set the RTC when IR is being received. A sample sketch is here:
http://forum.arduino.cc/index.php?topic=139907
It is not the only solution, but it is a simple solution and will also get you thinking about doing other off-loading of dedicated processing such as IR or SD data logging. The uC are inexpensive when attached directly with a sensor and the interfacing is easy. Plus, once a design is finalized for a sensor, you can reuse that design for other projects. The IR project is very useful whenever an Arduino needs a numeric input value... not just HH:MM:SS
Ray
If your Arduino is near a window another choice is to use a GPS module to get the time. It's very accurate and never needs setting.
jacksons:
Looking at the datasheet, the ATMEGA168 has an internal 32khz RTC, but I think it needs constant power and I'm not sure how to enable it using Arduino code
If you check the d/s, you'll see the timing on those internal oscillators tend to not be very accurate.
oric_dan:
jacksons:
Looking at the datasheet, the ATMEGA168 has an internal 32khz RTC, but I think it needs constant power and I'm not sure how to enable it using Arduino codeIf you check the d/s, you'll see the timing on those internal oscillators tend to not be very accurate.
As I said a year ago (see reply 3) the 32 kHz clock feature requires an external 32 kHz crystal (in place of the 16 MHz resonator). The 'clock' will be as accurate as the crystal. You are thinking of the various RC (resistor capacitor) clocks.
Or, for about a dollar U.S., you can build a 1 second clock-crystal source. Use this to interrupt your Arduino and do whatever clock stuff you require.
I've built this and can attest that the code and schematic are correct.
http://www.insidegadgets.com/2011/10/08/how-to-use-a-32khz-watch-crystal-on-an-attiny85/
Ray
johnwasser:
If your Arduino is near a window another choice is to use a GPS module to get the time. It's very accurate and never needs setting.
At the risk of bringing to mind a Chicago Transit Authority song, I'll just mention that GPS time is, currently, about 16 seconds out of sync with UTC. Randall doesn't mention whether it's ahead or behind. Might not matter, depending on the application. See also How accurate is the TIME DISPLAY on my GPS?
justjed:
johnwasser:
If your Arduino is near a window another choice is to use a GPS module to get the time. It's very accurate and never needs setting.I'll just mention that GPS time is, currently, about 16 seconds out of sync with UTC.
The regularly used NMEA messages ($GPRMC and $GPGGA) provide UTC time. That should almost always be correct within 100 nanoseconds (0.1 microseconds). The minor exceptions are cause by the 20-minute interval between updates of the GPS-UTC Offset value. I don't know if the satellites are synchronized in the time they send the offset updates. If they are synchronized the average wait time for an update will be ten minutes. If the satellite updates aren't synchronized then tracking multiple satellites satellites should bring that average way down.
If you cold-start a GPS (all prior memory erased) it won't have an accurate offset value until it sees an update (maximum of 20 minutes).
If your GPS is not clever enough to process the "Leap Second coming up" data (and commercial GPS units generally aren't) its GPS-UTC Offset will be off by a second for up to 20 minutes each time a Leap Second is added.