#define START_TIME 1226243400 // set this to the Unix start time you want (0 is midnight Jan1 1970 UTC)//get unix time code from http://www.onlineconversion.com/unix_time.htmvoid setup(){ Serial.begin(9600); pinMode(13,OUTPUT); // we flash the LED each second DateTime.sync(START_TIME);}

void loop(){ unsigned long prevtime; // if(DateTime.available()) { // update clocks if time has been synced digitalWrite(13,LOW); // first flash the LED prevtime = DateTime.now(); while( prevtime == DateTime.now() ) // wait for the second to rollover ; //{ // the following lines to be added to your test sketch // Serial.print(millis(),DEC); delay(1500); // this reduces the number of serial message sent // }

I used the latest library from the playground and 0011. I tried both an older NG board as well as a Deicimilla board. In all cases the program compiles and runs for anywhere from a minute to several minutes, freezes and usually restarts again at some random date. It seems to run longer with the 1.5 second delay inserted after the second rollover while loop. Any suggestions? Thanks.

Hotcarrier, I ran that sketch for 10 minutes without problems, I will keep it running and see how it goes.

It would be worth you trying it using the latest arduino version. Although the DateTime library was designed and tested using 0011, I am now running 0012 and it may be easier to identify the problem if we are both running the current version.

Does the playground sketch run ok? if not, you could run this sketch. It will test if the problem has something to do with the Serial port or with accessing the millis function (which the library uses to get the current time).

void setup(){ Serial.begin(9600); pinMode(13,OUTPUT); // we flash the LED each second}void loop(){ digitalWrite(13,LOW); // first flash the LED delay(1500); // this reduces the number of serial message sent digitalWrite(13,HIGH); unsigned long time = millis(); Serial.println(time, DEC); delay(100);}

-----------------[glow]Update[/glow]

edit: I wonder if this is a RAM problem.

Could you do a test with the sketch you posted modified so that DateTimeStrings is not used

To do this, comment out the second line as follows:// #include <DateTimeStrings.h>

And comment out the two places in digitalClockDisplay() where the strings are used:

[glow]Another Update[/glow]I just tried the sketch you posted with 0011 and its been running ok for the last ten minutes hour. If you don't wan't to update to 0012 then don't worry, I can test using 0011

Hi piecurus, I wonder if you could do a test for me and try the folowing. Please replace DateTimeStrings.cpp in the library directory with the code below, delete the DatetimeStrings.o file, recompile and run the sketch to see if this fixes it.

// uncomment one of these month and day defines as appropriate for your application#define dt_LONG_MONTH_STRINGS true#define dt_LONG_DAY_STRINGS true//#define dt_SHORT_DAY_STRINGS //#define dt_SHORT_MONTH_STRINGS

extern "C" { // AVR LibC Includes #include <avr/pgmspace.h>}

#include "DateTimeStrings.h"#include <string.h>

// if you change the long strings below, make sure none are greater then the constant dt_MAX_STRING_LEN defined in DateTimeStrings.h// the short strings for each day or month must be exactly 3 characters

Only one more comment. I'm using a Mac OS Leopard. In the 0012 version, the example sketches have to be placed in a folder named "examples" inside the principal directory.For instance, the DateTime sketch has to be put inside the folder "/hardware/libraries/DateTime/examples/DateTime/". In this way, the examples can be opened from "Open -> Examples -> Library-DateTime".That's all!

I will try the new DateTimeStrings.cpp, but with the older version commented out as you suggested my sketch still freezes after running a short time and then jumps to some new random time. The other sketch you asked me to try runs for 24 hours without problems. I am using a Mac for development. This is all still on 0011

mem:Good news. I had done what you suggested and it still did not run on 0011. But I moved to 0012 and it just ran correctly overnight! I will investigate and see if I see anything further on 0011, but probably justmove to 0012 for this project. Thanks for your help.