Barebone Digital Clock Rev2

Hey guys...

Here's a follow-up for the digital clock project I have posted about a year ago. I have not considered the drift of the RTC module! I have found the drift to be plus 1 RTC minute for every 21 days passed, that's huge. This is already after re-orienting the xtal oscillator in the DS1307 break-out module to be as close to the chip as possible, which was suggested together with other considerations, in the maxim app note.

Options Considered:

1. Optimizing RTC: look for best xtal, matching capacitances, etc, etc <-- IMPOSSIBLE

2. Add manual decrement button for the minutes value <-- This means changes in hardware. The easy way out!!

3. Auto-calibration by the host microcontroller

The Algorithm:

What I need is a software-based auto calibration routine. After some trials (and actually finding the time to do it!), I came up with this... Save the cal factor 21 (days per minute) and the day the last cal was done into a convenient non-volatile location. Every time the clock is powered up (in my case that is every morning 7:05 a.m., except weekends and holidays ;) , the mcu reads these values and compare with current RTC date if multiples of 21 days has already passed. If yes, decrement minute value by the corresponding count then save current day back to the the 'lastCalDay' location. Do the same check on the next power up...

The Implementation:

For the cal location, DS1307 has a 'general-purpose battery-backed ram with unlimited writes'. We will need two 8-bit bytes each for the calFactor and lastCalDay. For counting days difference, we will convert the RTC date (month and day numbers) to a single whole number starting from a reference date. For this we can use first day of the current year as the reference, day number 1. This means the maximum number of days between cal should not exceed 365. Using day number is convenient for getting the difference and also for saving the date to ram. Just add provision for new years when days count goes back from 365 to 1. Once days difference is determined we can then decrement the corresponding number of minutes. For code simplicity, I chose to skip cal if the resulting minute difference will roll back the hours digit. Please refer to the attachmed for complete code implementation.

The Results:

Results of my validation showed correct operation as designed. Of course, the code and indeed the algorithm can still be optimized for accuracy and elegance but for now this one works for my purpose just fine!

Please let me know if you need more details should you wish to make this project as well... Suggestions are also welcome.

Thanks. Enjoy!