Problem with setting RTC time permanantly.

Projects Programming
1

Hi, I am using the softrtc example below along with a DS1307 breakout board

// Date and time functions using just software, based on millis() & timer

#include <Wire.h>
#include "RTClib.h"

RTC_Millis RTC;

void setup () {
    Serial.begin(57600);
    // following line sets the RTC to the date & time this sketch was compiled
    RTC.begin(DateTime(__DATE__, __TIME__));
}

void loop () {
    DateTime now = RTC.now();
    
    Serial.print(now.year(), DEC);
    Serial.print('/');
    Serial.print(now.month(), DEC);
    Serial.print('/');
    Serial.print(now.day(), DEC);
    Serial.print(' ');
    Serial.print(now.hour(), DEC);
    Serial.print(':');
    Serial.print(now.minute(), DEC);
    Serial.print(':');
    Serial.print(now.second(), DEC);
    Serial.println();
    
    Serial.print(" seconds since 1970: ");
    Serial.println(now.unixtime());
    
    // calculate a date which is 7 days and 30 seconds into the future
    DateTime future (now.unixtime() + 7 * 86400L + 30);
    
    Serial.print(" now + 7d + 30s: ");
    Serial.print(future.year(), DEC);
    Serial.print('/');
    Serial.print(future.month(), DEC);
    Serial.print('/');
    Serial.print(future.day(), DEC);
    Serial.print(' ');
    Serial.print(future.hour(), DEC);
    Serial.print(':');
    Serial.print(future.minute(), DEC);
    Serial.print(':');
    Serial.print(future.second(), DEC);
    Serial.println();
    
    Serial.println();
    delay(3000);
}

It works and my output on the serial monitor is correct

2012/7/25 22:42:39
seconds since 1970: 1343256159
now + 7d + 30s: 2012/8/1 22:43:9

2012/7/25 22:42:42
seconds since 1970: 1343256162
now + 7d + 30s: 2012/8/1 22:43:12

2012/7/25 22:42:45
seconds since 1970: 1343256165
now + 7d + 30s: 2012/8/1 22:43:15

However when I comment out the following line:

RTC.begin(DateTime(DATE, TIME));

I expect the readings to carry on as they were before with the same date and time as my PC but I am getting

2106/2/6 6:28:19
seconds since 1970: 3
now + 7d + 30s: 2106/2/13 6:28:49

2106/2/6 6:28:22
seconds since 1970: 6
now + 7d + 30s: 2106/2/13 6:28:52

2106/2/6 6:28:25
seconds since 1970: 9
now + 7d + 30s: 2106/2/13 6:28:55

which shows that the date and time set in the initial sketch is not being retained for some reason.

Any ideas on what is happening here?

2

I would imagine that without RTC.begin() in there it's not initialising the RTC properly.

Try just removing the contents of the () and using RTC.begin() by itself.

3

it looks like the command rtc.begin
initializes the time routines,
so without it the functions in the routine are still available (its just c++ functions), but they are not properly set.

i wonder how do you set the time to the arduino, is it a shield, or is it essentially serial reading from a pc program that provides time on your computer by a serial write ?

4

Ok changed the initial code to

// Date and time functions using a DS1307 RTC connected via I2C and Wire lib

#include <Wire.h>
#include "RTClib.h"

RTC_DS1307 RTC;

void setup () {
    Serial.begin(57600);
    Wire.begin();
    RTC.begin();

  while (! RTC.isrunning()) {
    Serial.println("RTC is NOT running!");
    // following line sets the RTC to the date & time this sketch was compiled
    RTC.adjust(DateTime(__DATE__, __TIME__));
  }
}

Output:

RTC is NOT running!
RTC is NOT running!
RTC is NOT running!

This shows that the RTC is begin() command is not working properly or I have connected the breakout board incorrectly, will look if I have connected the pins correctly.

5

I use the JeeLabs library for my DS1307 RTC.

In their example code RTC.begin and the time / date setting are separate. I have found that due to the time take to compile and upload the RTC will be some seconds behind the pc clock.

   RTC.begin();


  if (! RTC.isrunning()) {
    Serial.println("RTC is NOT running!");
    // following line sets the RTC to the date & time this sketch was compiled
    RTC.adjust(DateTime(__DATE__, __TIME__));
6

Working now, was just the pins. I have that same problem with it being behind the clock, did you manage to find a solution?

7

They aren't that accurate so it won't make much different after a week. I have one sat in a box just so I can see how far the time drifts over a period of time.

8

dannable:
They aren't that accurate so it won't make much different after a week. I have one sat in a box just so I can see how far the time drifts over a period of time.

If you set up your crystal properly, then it's accurate. If not, not. - a clock is only as accurate as its tick.

You have to ensure that the load capacitance exactly matches the crystal, and take into account your board layout and trace lenth/routing. If your crystal is running at exactly 32768Hz, then it will keep perfect time.

9

Well I imagine, if you want to keep 'perfect' time, you need to either have a radio receiver to get and parse WWV (or similar) signals, or you have some sort of networking, and use NTP or similar protocols to sync your clocks. Of course leap seconds add to the fun.

10

The tolerance on the DS1307 isn't that good, but perhaps I should have said that the majority - the inexpensive ones from China - aren't that accurate?

But they are cheap. And as long as you appreciate the trade off there shouldn't be a problem? If you require something more accurate you need to look at other devices.

11

On a completely different tack, that has set me thinking - setting the time from the GPS signal! Sorry, rambling again!

12

dannable:
On a completely different tack, that has set me thinking - setting the time from the GPS signal! Sorry, rambling again!

Yes, I forgot about the GPS signal needing to send accurate time. Of course it depends on whether you are in a location you can get the GPS signal. But I could imagine using it to correct the RTC whenever you see the birds.

13

In the code that sets the time you will notice DATE and TIME. These are known as preprocessor directives. What happens (in brief) is that the first thing that happens when you start to compile and download your sketch is that these two items are replaced by the current date and time according to your pc. The problem is that then the sketch is compiled and squirted down to the processor, all of which takes time. Hence the RTC ends up several seconds behind the pc.

To get round this you can specify the time you want to set the RTC to:

RTC.adjust(DateTime(DATE, "13:00:00"));

If you remove the test to check if the RTC is running and upload the sketch then as soon as you run the Serial Monitor it will set the time to that specified. So using the example above, about thirty seconds before one o'clock I would upload the sketch and then, a couple of seconds before time, start up the Serial Monitor. Don't run the Serial Monitor again otherwise you will reset the time again!

With a little trial and error you should be able to time it just right!

David.