How to calibrate a DS1307

My DS1307 is running fast: +10 seconds per day @ 19°C. I'm using the library DS1307RTC.

When I call getCalibration() from the library, I get a value of -19.

I presume I have to make this value more negative to slow down the clock, but how much? What does a value like -19 correspond to? Seconds in 24 hours?

Is the accuracy going to change significantly at all when I will be operating the clock between 8° and 12°?

The answer is probably, and what you propose is a complete waste of time. About $3 will get you a DS3231 which is far more accurate.

1 Like

You mean that trying to change the calibration will do no good? The problem is, the RTC chip is part of a bigger datalogging board with SD and sensors on it, so I'd rather work on it to improve it if I can.


see if this helps.
RV mineirin

Thanks, but the project cannot depend on the internet. It is a datalogger meant to run on it's own for a few months, far away form any other tech gadget.

The DS1307 drift rate will depend rather strongly on temperature, so any calibration you do will be temperature dependent.

The reason that the DS3231 works so well is that it measures the temperature, and uses switched capacitors to compensate.

I can live with that. I can even observe my clock under actual use conditions and calibrate from there. But one question remains: how does getCalabration() work? How much is -19?

I don't know, but if I wanted to know, my approach would read the library docs and the source code for the calibration routine.

Are you sure getCalibration &c. does what you think and is applicable to the DS1307?

I know the DS323? has a register you can use to fine tune performance, I am unaware of such a capability in its older cousin DS1307.

What does the data sheet say?


Me too, but the datasheet says nil and I can't make sense of the 2 functions:

void DS1307RTC::setCalibration(char calValue)
  unsigned char calReg = abs(calValue) & 0x1f;
  if (calValue >= 0) calReg |= 0x20; // S bit is positive to speed up the clock
#if ARDUINO >= 100  
  Wire.write((uint8_t)0x07); // Point to calibration register
  Wire.send(0x07); // Point to calibration register

char DS1307RTC::getCalibration()
#if ARDUINO >= 100  

  Wire.requestFrom(DS1307_CTRL_ID, 1);
#if ARDUINO >= 100
  unsigned char calReg =;
  unsigned char calReg = Wire.receive();
  char out = calReg & 0x1f;
  if (!(calReg & 0x20)) out = -out; // S bit clear means a negative value
  return out;

For example, I tried


and then

RTC.getCalibration(); // gives -18

I tried some random values and this is what I get:

set to    getting
  7          -3
 -8           0
-30         -18
-50         -18
-40           0
-10          -2

Nothing, so you are probably right and getCalibration() is just returning garbage. Otherwise, I couldn't explain the results from my test table.

The routine returns the contents of the calibration register. The device data sheet explains the function of that register. Change the contents, it if you like.

Look at the data sheet.

Register at address 0x7 has nothing to do with calibration.

I have no idea why there are the functions you found.


If it does, it is without using the word calibration.


Really you on a Hinding to nothing the D1307 is not a very stable clock . The 3231 is compatible with the 1307 software .

Have a look and see if they are pin compatible ???


Are you using Arduino (AVR) or ESP6266/32 (Espressif), or does not matter?

RV mineirin

You are right. I was thinking of the DS3231, which does have such a register (at 10h).

Ah well, there's something for you to ponder on while under the shower. I have never understood why nobody has gotten round to producing a datalogging shield with a DS3231 on it, but years ago I concluded that the DS1307 is actually just fine for the job, and it is only a matter of taking a realistic attitude.

So you might ask yourself if you really do need accurate time? You may well find that all you really need to know is if this event occurred after that one. Every datalogger I have made incorporates an RTC, the later ones having a DS3231, but i eventually concluded a record number would be quite satisfactory and the only real use of the clock output was to start a new data file at midnight, using the date as a fileneame, and a few seconds each way would make no difference.

If you decide that the actual time really is important, it might be time to homebrew your own logging shields using the DS3231. If you go this way, note that the only DS3231 modules I have seen are quite bulky, due to the battery holder, and any shield stacked over it needs to have long pins. Dataloggers typically require a Mega, which means an RTC may be conveniently mounted on a small board over pins 20,21, thereby avoiding any problems with pin spacing.

Inaccurate clocks have always bothered me. One or two seconds drift per day I can live with; 10 seconds I find unacceptable, whatever the application. For my datalogging application, I need to know at what time of day I'm recording certain parameters, so yes, I do need a RTC after all. An error of a few minutes should be OK, but a clock that's 10 seconds fast gains more than a minute per week. After a few months of unattended operation, like in my plans, that adds up to an annoying error.

On the other hand, I just found out that if I set the "calibration" to 7, I get a value of -3 and, with that value, the accuracy improves to become +3 seconds per day or so, so we are closer to my acceptable tolerance. I hope I'm not fooling myself...

You probably are, but, since you have one to hand, you might as well try it. If you keep the temperature around it constant, you may find it quite satisfactory or the time to stop bashing your head against the wall will become apparent soon enough. I have been on this forum for over ten years but I must admit I have never heard of anybody actually using calibration on a DS1307. There could be good reason for this. I might also remind you that, no matter where on earth you put this gear, the distance from GPS satellites will be much the same, so maybe a solution lies there.