Slow Clock

Discovery

A member of the Forum was kind enough to send me the attached code for reading the time from a DS1302 clock chip. I am using the code in a real time application program and I noticed that, after a few days, events were happening later in time. After a week the clock was 45 seconds slow. I changed the DS1302 with three other chips and noticed the same effect was present. I changed the crystal with three other crystals and the clock time was slow by the same amount. The time is read in a fast loop continually. The hours, minutes, and seconds are compared to start values in the loop. When a match occurs, outputs are set or cleared.

I changed the PAUSE instruction from PAUSE 1 to PAUSE 10 and noticed the clock ran slightly faster. Is there a fix to this code?

Sincerely,

Discovery

Discovery

Here is the code.

Sincerely,

Discovery

'{$STAMP BS2}
'{$PBASIC 2.5}
'Read Clock Program---2014/10/1----
'Adjust Pin 13, 14, 15 for different PC boards
'Regenerated Code
'----Revision History----
'----IO Definition----
Clock PIN 13 'DS1302.7
DataIO PIN 14 'DS1302.6
CS1302 PIN 15 'DS1302.5

'----Constants----
RdSecs CON $81
RdMins CON $83
RdHrs CON $85
CWPr CON $8E
WPr1 CON $80
WPr0 CON $00
WrBurst CON $BE
RdBurst CON $BF
Hr24 CON 0

'----Variables----
H VAR Byte
M VAR Byte
S VAR Byte
index VAR Byte
reg VAR Byte
ioByte VAR Byte
secs VAR Byte
secs01 VAR secs.LOWNIB
secs10 VAR secs.HIGHNIB
mins VAR Byte
mins01 VAR mins.LOWNIB
mins10 VAR mins.HIGHNIB
hrs VAR Byte
hrs01 VAR hrs.LOWNIB
hrs10 VAR hrs.HIGHNIB
date VAR Byte
month VAR Byte
day VAR Nib
year VAR Byte
work VAR Byte


'----Initialization----
Init:
reg = CWPr
ioByte = WPr0
GOSUB RTC_Out

'----Program Code----
Start:
DO
GOSUB Get_Time
H = 10 * hrs10 + hrs01
M = 10 * mins10 + mins01
S = 10 * secs10 + secs01
IF H = 23 AND M = 59 AND S = 59 THEN PAUSE 2000

DEBUG DEC2 hrs10,DEC2 hrs01,CR

LOOP

'----Subroutines----

RTC_Out:
HIGH CS1302
SHIFTOUT DataIO, Clock, LSBFIRST, [reg, ioByte]
LOW CS1302
RETURN

Discovery

Is there anyone who can shine some light on the problem?

Sincerely,

Discovery

tomcrawford

The oscillator/countdown chain is independent of the read-out circuitry, at least to a first approximation. That is, reading the registers more or less continuously shouldn't have any effect on the accuracy of the clock. That said, I suppose if you have really poor power to the 1302, reading the registers might disturb the oscillator.

I don't see the PAUSE 1 (10) in the code that you mentioned.

I would do two three four things:

1. Make certain the power to the DS1302 is really robust and well-bypassed.
2. Try reading the registers every, say 500 milliseconds or so and see if that helps.
3. Make sure the crystal layout is cool. Have a look at Figures 2 and 3 in the data sheet.
4. Make sure you are using the correct crystal.

msrobots

My experience with the 1302 is mixed, but what really important is, is that the crystal has to be wired as short as possible.

Best results is by cutting them short and connect them directly to the pins, soldered into the same hole or plugged directly with the DS1302 into a socket.

And yes, it needs very stable power.

Mike

jmg

Discovery wrote: »

.... After a week the clock was 45 seconds slow.
.... The time is read in a fast loop continually.
... I changed the PAUSE instruction from PAUSE 1 to PAUSE 10 and noticed the clock ran slightly faster.

You need to quantify 'slightly faster' and I'd suggest vary the read loop maybe down as slow as 10 seconds and record how the time varies with read-rate.

I recall seeing various web reports about reading RTCs disturbing the counting.

Did you try a built-module using the 1302, as a second opinion test ?

It would help to start at a known correct frequency, but the 1302 seems to lack any means to output a divided test signal.
Can you choose a better RTC ?

Discovery

Yes, the pause instruction is in the Get_Time subroutine that did not copy over. I did not catch that oversight. I used a pause value of 1 and 10 with the result that after 7 days the clock lost 45 seconds with the PAUSE of 1 but improved for the same period to a loss of 30 seconds with a PAUSE of 10.

Get_Time:
HIGH CS1302
SHIFTOUT DataIO, Clock, LSBFIRST, [RdBurst]
PAUSE 10
SHIFTIN DataIO, Clock, LSBPRE, [secs, mins, hrs, date, month, day, year]
LOW CS1302
RETURN

The circuit is on a breadboard with flying leads.

Power is supplied from a UPS to a 12 VDC power supply then regulated to 9 VDC on the breadboard, filtered, and cap by-passed before input to the BS2. The 5 VDC generated by the BS2 is used to power the DS1302.

Based on your comments...it appears that the best solution is to make a printed circuit board, use a 9 VDC regulator for the BS2, use a 5 VDC regulator for the DS1302, and by-pass the DS1302 power pins with several disk caps.

Sincerely,

Discovery

tomcrawford

Take a look at DS3234. You can get one a breakout board to fiddle with. It has the crystal built-in so you don't have to worry about any of that stuff.

I have one that gains about 4-5 seconds per year, since 2015.

Tracy Allen

Really do take to heart msrobots' advice about the crystal and the short attachment leads.

The DS1302 needs a crystal with 6pF load capacitance. However, the most common 32kHz xtals have 12.5pF, so even if you tried 3 different crystals, you have to be sure they are 6pF. It will run with 12.5pF, but it will be slow. To avoid additional circuit capacitance, glue the xtal to the top of the DS1302 package, and bend up the X1 and X2 leads away from the circuit board and solder them directly to the xtal leads. If you make a PCB, keep the circuit traces as short as possible. Also keep all digital lines far away, because the crystal leads are very sensitive to noise pickup.

Discovery

Thank you.

First, I will try the PCB and measure the time...if that does not produce acceptable results I will get a DS3234 because a 4 to 5 second per year error is what I would accept.

Sincerely,

Discovery

Tracy Allen

"First, I will try the PCB ¡and the 6pF crystal! and measure the time..."

If you're in the market for different RTC chips, improved accuracy and added features, take a look at the parametric search...
https://para.maximintegrated.com/en/search.mvp?fam=rtc
Other companies like Intersil also make super-accurate RTCs.

Discovery

Tomcrawford,
I looked at the DS3234. It appears to be just the RTC I would like. Do you have a BS2 program that will interface to that RTC and can I get a copy?

Discovery

tomcrawford

Here is BS1 code for the DS3234. forums.parallax.com/discussion/166340/bs-1-meets-ds3234-rtc#latest

and prop spin code: forums.parallax.com/discussion/154394/dallas-maxim-ds3234-based-clock-with-propellor#latest

Discovery

Thank you...I will purchase the DS3234 and run the code.

Sincerely,

Discovery

Moskog

I used to have a similar problem with DS1302 attached to a BS2 project. Except my clock was getting to fast, even though with the recommended crystal and the crystal itself bended over and soldered to the RTC. Had to manually adjust the time every second month or so.
Now this project is based on the Propeller but I'm still using the DS1302. The Propeller allows me to use a GPS-receiver to get correct time at three o'clock every night and then adjust the RTC if necessary. Here is an example code for reading a GPS module with BS2: https://www.parallax.com/downloads/vpn1513-gps-module-example-code

My friend LA6WNA found a very smart and simpel way to avoid this problem in his projects. I think it was based on adding/substracting one or two seconds every night on the RTC, this way he got an acceptable accuracy. If he is around he could probably tell you more about it.

Discovery

Moskog,
From what you describe...it appears that the crystal is the source of the problem. Who knows where crystals supplied from Digikey were manufactured.

Adjusting the seconds appears to me to be a sensible approach. Very good suggestion.

Sincerely,

Discovery

Discovery

It works.

Adjusting the seconds just after midnight works perfectly.

Thanks for the suggestion.

Sincerely,

Discovery