RTC Issue

Status
Not open for further replies.
C

craiglindley

Well-known member
OK, so I'm building a clock using the Teensy 3.1. This should be easy right ? Don't know if it is important or not but I'm running my clock in 12 hour format. So

1. I gather user input for the time and date and call setTime(hr, min, sec, day, mon, year) adjusting for 12 to 24 hour differences.

2. I read back the RTC and format a string for displaying time and date using the function below:

Code: 
// Format the time and date into buffer in the form:
// hh:min AM/PM Mon Jan 31 2014
void formatTimeDate() {

    boolean isAm = isAM();

    time_t t = now();        // Get now time
    int hr = hourFormat12();
    int mi = minute(t);
    int dy = day(t);
    int weekDay = weekday(t);
    int mo = month(t);
    int yr = year(t);

    sprintf(timeDateBuffer, "%d:%02d %s %s %s %d %d", 
    hr, mi, isAm ? "AM" : "PM", dayNameArray[weekDay],  monthNameArray[mo], dy, yr);
    
    Serial.println(timeDateBuffer);
}

3. Things work well for about 5 minutes. That is, I read back the time and date correctly

4. Then I see this:

Code: 
10:32 AM Mon May 19 2014
10:33 AM Mon May 19 2014
10:33 AM Mon May 19 2014
10:33 AM Mon May 19 2014
10:34 AM Mon May 19 2014
10:34 AM Mon May 19 2014
10:34 AM Mon May 19 2014
10:34 AM Mon May 19 2014
12:16 AM Mon May 19 2014
12:16 AM Mon May 19 2014
12:16 AM Mon May 19 2014

For some reason after 5 minutes the time mysteriously changes from 10:34 to 12:16 and my program is doing nothing excepting displaying the time.

I have a feeling this has something to do with syncing system time to RTC time but I don't know what.

Any hints would be appreciated

Thanks
 
Just to be sure we've covered the obvious things. Have you soldered a 32.768kHz crystal to the board so that the RTC keeps time, and do you have a 3V coin cell battery connecting Vbattery and Ground on the back of the Teensy?
 
Yes the crystal is connected and as you can see from the note above I keep polling for the time (using the Time library functions) and it keeps changing which I assume means the RTC chip is running.

I don't have a battery connected right now but I thought as long as the Teensy has power, the RTC would also. I realize I will need to add the battery when I'm finished with development. Is this an incorrect assumption?
 
Things are becoming clearer after looking at the Time library code. Yes 300 seconds is the default resync time so that explains why my time changes after 5 minutes. What I cannot find looking through the code is how the RTC hardware is actually set as a result of the call to setTime(......). It seem the Time library is actually keeping the system time and the system time is synced to the RTC every resync interval. If the RTC hardware is never actually set by setTime that would explain my problem. Can someone tell me how setting of the RTC hardware is performed?

Thanks
 
OK I've figured it out. There is no coupling between setTime(......) and the RTC. The setTime(....) function sets the system time which is retrieved whenever the time functions hour(), minute(), etc are called. Unfortunately when the resync operation is performed it will clobber the system time with whatever time the RTC has. Hence my problem. The fix is as follows:

// Set the time and date into the Time library
setTime(cHour, cMin, 0, cDate, cMon, cYear);

// Set the system time into the RTC
Teensy3Clock.set(now());

I truly think this is broken. The setTime function should push whatever time/date specified in the setTime call through to the RTC.

My opinion.
 
The coin cell battery is only needed for the RTC if no other power source is available.

I've had an application that kept time for many months without seeing this bug. Maybe we're using different time functions or there was a regression?

One behavior you might find surprising: the RTC is updated whenever you upload new firmware to the Teensy. It uses the compile time on the theory that the starting time will be very roughly correct and this is better than resetting to some arbitrary time like midnight of Jan 1, 1970.

There was a long thread about how to achieve accurate time keeping. I don't know what your expectations are but I was a little surprised when I learned that microprocessor clocks would need to be adjusted many times a year to keep time to within a minute. (NNTP and GPS are both spectacular for providing accurate time.)
 
Well, you probably need to think about correcting the RTC based on the temperature like the chronodot claims to: https://www.adafruit.com/product/255, which uses the DS3231 temperature corrected RTC internally. I suspect the RTC within the Arm processors is not that precise even if you use a precise crystal. But even so, clocks generally need to be coordinated (ala, nntp, or via the clock provided by GPS units).
 
@craiglindley No this is correct. What happens if you want to setTime and not using the RTC. Or if you want to have a system time independent to the RTC? You want to keep the System time decoupled from the RTC for that reason.
 
I agree but if you didn't have a RTC you wouldn't register a sync provider function and system time would be completely decoupled. If a system like mine is setup with a RTC I would expect calling setTime(...) would set the RTC.
 
MichaelMeissner said:
I suspect the RTC within the Arm processors is not that precise even if you use a precise crystal.
Click to expand...

All depends on how much time (har har) and money you want to put into correcting the RTC. I did some tests that suggest a CFS-206 crystal-based RTC on the Teensy can achieve +/- 0.5-1PPM accuracy, i..e better than the DS3231 specs out of the box. Difference being that the DS3231 is a production part with a wide temperature range and lots of testing, and my sample size is 1. ;)

'All' you need to do is characterize the crystal across a wide range of temperatures, determine the shape, intersects of its error vs. temp parabola, then use a good on-board sensor to determine the temperature of the crystal at regular intervals and muck with the correction factors to ensure accurate RTC operation. I'll get around to testing a rig in the near future and see how well it holds time vs. the GPS constellation.

I wrote a small program that basically calculates all the parameters over a 100-trial run (as the teensy slowly warms from being inside a dry ice bath) and then writes the factors to EEPROM for later retrieval. All you need is a GPS receiver or other accurate PPS signal to help the Teensy determine its crystal and RTC crystal error vs. the PPS signal.

I need to run more tests that this holds for every CFS-206 I bought, but this is the approach I want to take, i.e. using a accurate on-board temperature sensor to adjust the RTC correction factors every minute if necessary to run faster or slower as needed. For those who are interested in some data I published earlier on this forum, see here.
 
Last edited:
And for the curious, here are some anecdotal results for frequency measurements of various crystals (teensy, maple, DUE ...), oscillators, and TCXOs, using an NTP server or GPS chip.
https://github.com/manitou48/crystals
The test results are in crystals.txt on that github site. As noted frequency can vary with crystal, age, voltage, load capacitance, and temperature.
 
Status
Not open for further replies.
Back
Top