SparkFun's Real Time clock Module

Forum 2005-2010 (read only) Hardware Interfacing
1

Hello all.

I know there are a few threads about this component, but I'm having some weirdness that I haven't seen mentioned elsewhere.

I'm using the Sparkfun Real Time Clock Module with an older (pre-NG) Arduino.

With Wire.h, I'm able to communicate with the clock, set the time and read it, but after a few hours, the clock seems to go all crackers on me.

Typically what I have observed is this : after running well for a few hours, at the change of a new hour (has happened at 12h, 14h, and 6h), the clock will jump to 2h, for no apparent reason.

I'm using code I found in the playground ( at Arduino Playground - UsbMemory, relevant bit is near the bottom of the page):

#include <Wire.h>

int second = 0;     
int minute = 0;
int hour =0;
int day_of_week=0;
int day = 0;
int month = 0;
int year = 0;

void setup()
{  

  Wire.begin();
  Serial.begin(9600);
  delay(100); 
}


void loop()
{
  // reset register pointer
  Wire.beginTransmission(0x68);
  Wire.send(0);
  Wire.endTransmission();

  // request 7 bytes from ds1307
  Wire.requestFrom(104, 7);    
  second = Wire.receive();      
  minute = Wire.receive();      
  hour = Wire.receive();        
  day_of_week=Wire.receive();   
  day = Wire.receive();         
  month = Wire.receive();      
  year = Wire.receive();  

  // Convert all the BCD values that might have "tens" to decimal
  int hours=hour/16* 10 + hour % 16;
  int minutes=minute/16 * 10 + minute % 16;
  int days=day/16 * 10 + day % 16;
  int months=month/16 * 10 + month % 16;

  Serial.print( hour );
  Serial.print(":");
  Serial.print( minutes );
  Serial.println();
  //no need to rush
  delay(1000);

}

I'm using pull-up resistors in there, the circuit is built as it ought be, yet the clock (actually 2 different ones) consistently gives me this problem.

Any ideas what is going on? Is it a code issue? A problem with using this older board? An issue with the clock modules (somehow I think that is unlikely)?

I have posted a similar topic at sparkfun in case it's a clock issue, but i have a feeling it's either in my code, or because of the older board. I'll be testing out an NG this afternoon (no fancy Decimilia for me yet!), but curious if anyone has any insight into this.

2

I've got a similar module with similar problems.

When I set the time, it sets a time but not the time I was expecting.
I assume its just because I'm reading or writing it incorrectly. Your probably doing the same.

Double check the data sheet throughly.

3

Yeah, I know I'm setting the right time initially, as it runs correctly for a few hours before acting all funny. Crossing my fingers right now, since I've left it going all day, maybe it actually stayed consistent this time.

(edit)
you were right, i wasn't setting the time correctly (as I earlier attested, oops). the following code allowed me to set it correctly (almost 24 hours of the right time now)

sorry for the noise.

#include <Wire.h>

void setup()

{
 Wire.begin(); 
 Serial.begin(9600);

 Wire.beginTransmission(0x68);
 Wire.send(0);
 Wire.send(0x00);          
 Wire.send(0x10);         
 Wire.send(0x80 | 0x02);    
 Wire.endTransmission();

}
4

btw:
i think it is possible to do exact timing with just an arduino. I believe the 16Mhz crystal should run stable enough and one would just have to calibrate it once to get the "real" speed of it.

at least it could be much more precise than it is now. Don't know exactly what dedicated clock chips do extra for temperature/voltage change compensation though, still i doubt these things are needed for most arduino clocks.

did anyone try that yet? does anyone know the specs/tolerance for the standard crystal?

best, kuk

5

You could make a Arduino clock but its far easier to grab a dirt cheap chip and make it do all the hard work.
They include calendar stuff as well remember.

Also millis() and similar functions arent 100% accurate.
It would be a pain in the butt to count instructions to figure out its margin of error and correct it (without introducing more error).

6

They include calendar stuff as well remember.

ah, i see. thank you.

Also millis() and similar functions arent 100% accurate.
It would be a pain in the butt to count instructions to figure out its margin of error and correct it (without introducing more error).

why would you want to count instructions? don't timers run independently? i thought something like build a clock, let it run for a few days, get the offset and correct the hard coded crystal speed from 16.000.000 to maybe 15.999.997. but anyway, i didn't think of other reasons to use a dedicated chip.

7

Yeah, I know I'm setting the right time initially, as it runs correctly for a few hours before acting all funny. Crossing my fingers right now, since I've left it going all day, maybe it actually stayed consistent this time.

(edit)
you were right, i wasn't setting the time correctly (as I earlier attested, oops). the following code allowed me to set it correctly (almost 24 hours of the right time now)

sorry for the noise.

#include <Wire.h>

void setup()

{
Wire.begin();
Serial.begin(9600);

Wire.beginTransmission(0x68);
Wire.send(0);
Wire.send(0x00);          
Wire.send(0x10);        
Wire.send(0x80 | 0x02);    
Wire.endTransmission();

}

Have you got a photo / diagram of your setup? I'd love to see it if you do.

Alex

8

why would you want to count instructions? don't timers run independently? i thought something like build a clock, let it run for a few days, get the offset and correct the hard coded crystal speed from 16.000.000 to maybe 15.999.997. but anyway, i didn't think of other reasons to use a dedicated chip.

The timers are accurate but the code which reads them and processes the data isnt.
Every instruction dealing with the time data adds a fraction of a second error to the number and it quickly acclimates.

There was another thread somewhere observing this effect just over a few hours.