Comparison of four real-time clocks

The Results

Because the DS1307 I2C address conflicts with that of the DS321, I had to run the DS1307 separately. First, I ran a test of the DS1307 for five days (429,179 seconds), comparing the DS1307 time with the Raspberry Pi time running the RTCEval.py software [1], and then again for 292,000 seconds; I used this second test to create Figure 4.

Figure 4: DS1307 ppm error.

The DS1307 was running 7 seconds fast by the end of the first test and 5 seconds fast by the end of the second test. That means the DS1307 device gains about a second a day. This comes out to about 15ppm. You calculate this by

((error in secs)/(total secs))*1,000,000

The data sheet shows about 23ppm, so the tests seem reasonable.

The other three RTCs were run for 3.4 million seconds to determine their error rates.

The graph in Figure 5 shows the total accumulated errors of each of the RTCs. The straight lines with no data are from when the mains power failed and rebooted the Raspberry Pi and from when I killed the RTCEval.py process running in the background by updating the Raspberry Pi and rebooting without thinking. The RTCEval.py software is designed to pick right up and continue testing and logging when it is restarted.

Figure 5: Total seconds error.

A couple of interesting things can be seen in the Figure 4 graph. The first is that the DS3231 is much more accurate than either of the other RTCs by a goodly amount. The second thing is that the lines are all amazingly straight (i.e., linear). This means that, under this test condition, the errors are accumulating at a constant amount.

The "zigging" of the graph is mostly caused by the fact that I only can gauge by full integer seconds (the resolution of all the RTCs is only 1 second so I round off the Raspberry Pi's time to integer seconds also in RTCEval.py). Another way of thinking about that is that the RTCs are all pretty good timekeepers in themselves. They are drifting consistently away from the Raspberry Pi time.

Next, I looked at the total parts per million (Figure 6). This is calculated by taking the total error count of seconds and dividing it by the total number of seconds. If the RTCs are stable, then this should converge to a flat line. That's pretty much true (as seen in Figure  4), but you can detect a little drift in the PCF8563 and in the MCP79400. The DS3231 is amazingly flat and accurate.

Figure 6: Total ppm error.

The final graph (Figure 7) shows the first 250,000 seconds (left off of Figure 4) and shows the way RTCEval.py measurement algorithm quickly converges to an excellent approximation of the parts per million that changes little in the next 3.2 million seconds.

Figure 7: Test convergence to final ppm errors.

How Were The Graphs Made?

These graphs were completely produced on the Raspberry Pi using Python, MySQL, and a fantastic graphing package called MatPlotLib. I have written a tutorial on how to do this on SwitchDoc [2].

Buy this article as PDF

Express-Checkout as PDF

Pages: 6

Price $2.95
(incl. VAT)

Buy Raspberry Pi Geek

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content