I have at last got my RTC board running using the Time.h and DS1307RTC.h libraries.

The TimeRTCLogger example appears to be almost right for the project I am playing with , which is a sign showing the days since the last event, date of previous event, and previous longest days between events.

I know the DS1307 will keep the time for years, but I have a couple of questions

Firstly, I can only see the Syncing the time from the RTC during Set up ?is it keeping time with its now() call ?

Secondly , if this project is unplugged at some time, presumably the prevEventTime will be lost when the micro boots up again.Could I store prevEventTime as eeprom_write_byte and eeprom_read_byte ?

If so would it be in the same address - ie overwrite the previous one?

I only expect an event every few weeks, so the 10,000 write cycles will be fine - ( I am 63 years old )BTW The events are nothing to do with romance !

/* * TimeRTCLogger.pde * example code illustrating adding and subtracting Time. * * this sketch logs pin state change events * the time of the event and time since the previous event is calculated and sent to the serial port. */

Thanks PaulSo I could perhaps save the current time and current date as two bytes in eeprom, after any event, and reconstitute it back into the same format as prevEventTime in setup ?Can I read eeprom in setup?

OR perhaps save the now() whenever an event occurs. ( in seconds since Jan1 1970 ) , but divided by 60*60*24 when an event occurs which will give me the number of complete days in one byte, and save that to eeprom as dayselapsed

Then when booting up after a power interruption , I could just work in days ?? but now I am moving away from a sketch that is actually working......

I can usually McGuiver a way to make a sketch work , but this seemingly simple project has me going round in circles ( I am obviously in new ground with the RTC and eeprom - and cannot understand some of the dozens of examples I have looked at )

As I see it, if I could simply store the current time "now() " in eeprom whenever there is an event, if the power goes off for a few days , at setup I can read the old current time from eeprom, to calculate the previous date, and the days since event.

( I would also need to store the previous best, but that is just a byte ( 0-99 days ) and I can do that I think ! )

I have tried dividing the seconds into days and masking off the higher and lower bytes to store in this form, but I loose the hours and could end up with the wrong day count

Might I be better off storing the date of the previous event as separate bytes for YY MM DD, and use a look up table for the months to calculate the days since last event ?

I have spent 43 of the last 48 hours trying to get this right and it is driving me nuts! I stupidly made a promise I could get it done by the weekend - it looked so easy :-)

Has anyone seen a working sketch that they can point me to? or give some advice..

Thanks Rob, I wondered about that, is that the RC register they talk about in the datasheet?

I can store the previous best number ( 0-99) preferably in 2 bytes ( so I can just use each one - tens and units - easily for the display.) Although I still have to compare it to the current elapsed days to see which is the "best"

The date can be yyyy mm dd or seconds since 1970 . so I don't know the best way to try to store it.

If I store it in seconds since 1/1/1970 I can easily divide down the difference between latest and stored seconds to get elapsed days, but I still will need to display the previous date after a power down.....?

In your void setup, read the current time, read the stored time, do the math to see elapsed, store the new current time in the RAM.In your void loop, store the time in RAM after every read, then your downed time won't be more than 1 pass thru loop off.

Did you see the RTC_I2C_test.pde (something like that, you can browse my posts in member section)that I posted for halejandro and Magician?Has simple wire.h commands to write the registers, get the time.I think I only wrote to 1 RAM address, process is simple to write/read a larger amount tho.Let me know if you can't find it.

// Reset the register pointer // because the DS1307 sequences through all the addresses ? Wire.beginTransmission(RTC_address); // this would be 0x68 , the address for all DS1307s ? Wire.send(0x00); // starts the sequence back at 00 ( seconds and CH ) ? Wire.endTransmission();

Did you change Serial1 to just Serial?Guess I'm gonna have to rewrite that test to work over the IDE Serial Monitor also.I was using the ATMega1284 Serial1 port because I was downloadigng sketches over the USB to test, and it let me check out more of the card.

Section 2 question - imports the data from registers 0-7, assigns to the variables shown. Data may have to be maniputed to do math on them as generally the high nibble represents one thing and the low nibble something else.So for example if the seconds came back as 0x57, you would doSeconds_time = (highByte(seconds)*10 + lowByte(seconds)); to get the function of ((seconds >>4)*10) + (0x0F && seconds) (to yield 5*10 7)

3rd section - yes, point to start battery of RAM

4th section - not sure what you are saving, thought you needed time as you were determing time elapsed since some event. Got 56 bytes, save away.

Got it updated to work with IDE serial monitor. Biggest change was making Serial1 Serial,receiving 4 bytes instead of 2, testing for ASCII characters in the IF and Swith:case, and putting the 2nd pair of ASCII bytes together to make a real byte to send to the DS1307.

Nothing complicated.I also added some prints so one could see what the commands turned into, and changed some prints to println to look a little cleaner.Let me know that you can follow this.Data rate is 57600, make sure you set serial monitor to match.

That looks great, don't now how you are going to get time for fencing now your a moderator !

I will try that sketch out when I have had my morning coffee.

The extra byte I need to save is historically the best number of days between events, which could have been 5 events ago, but its simply compared to the latest one at an event time, and the largest is then stored as the best.