next topic »

[on:]

Using a RTC (real time clock) that every once in a while returns an incorrect time.

It happens maybe once or twice a day, but when it happens it messes up my code  : (

Does anyone have any tips or tricks for this problem? Searching didn't bring up anything on this specific type of problem.

I will try to decrease the error entering my code with constrain() and >=. Trying to keep the time within proper limits based on current minute and hour. But that probably won't catch all possible errors.

I don't think averaging is a good solution. So I'm wondering if anyone has a better idea.

An example of the error would be the time samples returning like this:

(24hour clock)
14:01
14:02
2:28
14:03
14:04

The error could be the chip returning the date instead of the time, but that doesn't matter. I just want to correct the error in case of any incorrect return. (bad signal for example)


Thanks for any help  : )

[Reply #1 on:]

What RTC are you using?  There are quite a few out there.  How is it wired up?

If it is in fact returning the date instead of the hours and minutes, you should probably determine why that is happening.  What code you using to read it? 

[Reply #2 on:]

Having spent some time with a few different RTC's I'm going out on a limb to state that the problem is going to be with your wiring/programming...

If you post some details we can help pinpoint that problem maybe...


Cheers,

[Reply #3 on:]

I appreciate your attention to my problem  : )

But I'm really not concerned about why this is happening. I want to make the code strong enough to handle such a RTC error no matter what the reason.

Nearby motors, low clock battery, solar flares, etc. Anything could temporarily damage a result from the RTC. I want my code to be able to handle it.


To answer your questions I am using this RTC:
http://macetech.com/store/index.php?main_page=product_info&products_id=8

This is code to read the clock:
http://docs.macetech.com/doku.php/chronodot_v2.0

Wired over i2c.


So for my example problem:
14:01
14:02
2:28
14:03
14:04

I can use the constrain() function to make sure hours stay within 0-12 and minutes 0-60.

I think I would want to take 3 or 4 clock readings and toss out the odd hour and minute data. Odd in that time doesn't go backwards or skip over hours or minutes.

I'm looking for help with that please  : )

[Reply #4 on:]

But I'm really not concerned about why this is happening. I want to make the code strong enough to handle such a RTC error no matter what the reason.

Hmm, really.. I'd be concerned with the "why" instead of hacking your code in one place to cover up bugs in another. Like I said I've had projects running continuously for months and never seen what you're talking about.

At which point in your code are you seeing the bad data? How far back have you tried debugging? You don't post your actual code so it's impossible to comment specifically.

You mention solar flares etc, but you have what looks like the date. For some massive external force I'd expect complete rubbish.

I still call "software bug".


Cheers,

[Reply #5 on:]

Hmm, really.. I'd be concerned with the "why" instead of hacking your code in one place to cover up bugs in another. Like I said I've had projects running continuously for months and never seen what you're talking about.

I'm using the code I referenced:
http://docs.macetech.com/doku.php/chronodot_v2.0

I call that code to get the hours, minutes, and seconds from the RTC. That's the only interaction with the RTC.

Usually I get the correct time. But sometimes I will get a single wrong result.

Today I got 2:28:2 instead of the correct time after about 13 hours of no problems with the RTC. 2:28:2 looks a lot like today's date. I will of course be watching if any future errors match the current date.

I don't consider it a bug. I consider it an error. The battery could be running down (the RTC is usually running off its battery) and there is a strong motor nearby.

I think that is the reason. Unless the code I referenced is wrong. The signal may be getting occasionally mixed up going to or from the RTC.

So I am looking for help for correcting the occasional RTC error.

I can constrain the numbers, but I don't want to average these numbers to pull a single bad result. What is the best way to pull a single bad result out of clock like data?

What has been your experience with RTC data when the batteries begin to fail? Does wrong data occur? Or does the RTC give perfect time until the battery is dead?

Again, thank you for your attention to my problem.

[Reply #6 on:]

You have an expected pattern right? Looks like you're querying the RTC every minute? So you know what to expect and it should be pretty easy to determine if something is totally out of whack. Last time was 14:02, so the next should be 14:03 - but you get 2:28 - so you should re-query. If the RTC can be updated externally then you'd need to look out for things like DST time changes and other events (eg time changes to account for any drift).

I don't think you're going to find a simple solution as there are going to be a bunch of edge-cases to take into account.


Cheers,

[Reply #7 on:]

Perhaps you could compare the reterned result with the most recently returned result and see how much they differ by?

ie:
if t - (t-1) < 5 then
{
  //do stuff
}

You get the idea..  The comparison is obviously more complex.

[Reply #8 on:]

I guess there is missing data pulse over some serial bus  as 28 == 14 < 1  could be coincidence but ...

[Reply #9 on:]

I see no resistors on the board, are you using pull-up resistors on your i2c lines?
If so then what kind of values?
If not then you need some - probably between 4K7 and 10K or so depending on application

[Reply #10 on:]

Yes those pull-ups on SDA and SCL are _mandatory_ for I2C...  RTC chips are ultrareliable (the Maxim ones have been tested in billions of PCs over the years!)