Slow Clock

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

Comments

  • 16 Comments sorted by Date Added Votes
  • 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
  • Is there anyone who can shine some light on the problem?

    Sincerely,

    Discovery
  • tomcrawfordtomcrawford Posts: 920
    edited September 30 Vote Up0Vote Down
    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.

    Re-inventing the wheel is not a waste of time if, when you are done, you understand why it is round.
  • 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
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • 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 ?

  • 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
  • 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.
    Re-inventing the wheel is not a waste of time if, when you are done, you understand why it is round.
  • 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.
  • 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
  • "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.
  • 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
  • Re-inventing the wheel is not a waste of time if, when you are done, you understand why it is round.
  • Thank you...I will purchase the DS3234 and run the code.

    Sincerely,

    Discovery
  • 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.
    KjellO
    LA3USA
  • 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
  • It works.

    Adjusting the seconds just after midnight works perfectly.

    Thanks for the suggestion.

    Sincerely,

    Discovery
Sign In or Register to comment.