DS1302 Time Drift

205 views
Skip to first unread message

DEKi

unread,
Aug 28, 2012, 5:41:50 AM8/28/12
to rays...@googlegroups.com
I have a v1.3u that works just fine, but before I jump to the new v1.4u; has anyone experienced time drift due to the high frequency of the MC34063 inverter getting into the DS1307?  I love the DS1307 but had a past experience where noisy power caused my time to drift up to minutes per day. Proper grounding and shielding helped, but once I cleaned up the power the drift went back to spec.
David

DEKi

unread,
Sep 1, 2012, 12:22:59 PM9/1/12
to rays...@googlegroups.com, rays...@googlegroups.com
Ray
When I talked to Maxim Tech support, they referred me to their App Note #58. Which explaned a great deal. I changed my circuit board layout to shorten the crystal lead length and put ground pane around the pins. I also moved the 0.1uf bypass cap right under the DS1307. I still get some time drift, but it is with spec now.
David
 
 
 

On Thursday, August 30, 2012 7:31:51 AM UTC-7, Rayshobby wrote:
So far I haven't noticed any time drifting caused by MC34063. 

-Ray

garygid

unread,
Sep 25, 2012, 11:44:02 PM9/25/12
to
My just-built v1.4u board, with 1.8 firmware seems to gain about one minute per hour.

A reboot apparently reads the time from the Internet, which seems 

to reset the RTC to the correct time.

Any thoughts on what to do?

garygid

unread,
Sep 27, 2012, 10:05:04 AM9/27/12
to rays...@googlegroups.com, rays...@googlegroups.com
Since the mpu clock can be off by about a half second in each
minute, a correction each 15 minutes could cause a 7.5 second
jump in time.

If this occurs during a program, while handling a 5 second Station
Delay, is the time correction going to cause problems with the
interpretation of the Program?

Perhaps resetting the mpu clock every minute instead of once
each 15 minutes would be better, trying to keep the mpu clock
within about one second of the correct time.

Is there a fairly easy hardware fix to use a crystal for the mpu clock?

Not using a crystal in a timing-type application might be a mistake?

However, good work in getting the initial fix out quickly.

Why did this problem never show up in previous hardware versions?
Thanks, Gary

Ray

unread,
Sep 27, 2012, 10:16:08 AM9/27/12
to rays...@googlegroups.com
On Thursday, September 27, 2012 10:05:04 AM UTC-4, garygid wrote:
Since the mpu clock can be off by about a half second in each
minute, a correction each 15 minutes could cause a 7.5 second
jump in time.

If this occurs during a program, while handling a 5 second Station
Delay, is the time correction going to cause problems with the
interpretation of the Program?


I don't think so. When a station is scheduled, it will be assigned a start time and stop time. Start and stop times are all reset to 0 in the beginning. The inner loop does the following: 1) if a station is already turned on, it checks whether the current time has gone past the stop time, if so, turn it off and reset start/stop time; 2) if a station is not turned on yet, check if the current time falls between start and stop time, if so, turn the station on.

Let's say the current time jumps while the loop is running, it will certainly cause the actual running time to differ from the expected time, but I can't think of a situation where, say, the station will enter a zombie state where it cannot be turned off.
 
Perhaps resetting the mpu clock every minute instead of once
each 15 minutes would be better, trying to keep the mpu clock
within about one second of the correct time.


Sure, this is easy to change in the code.
 
Is there a fairly easy hardware fix to use a crystal for the mpu clock?


Sure, you can add a crystal or ceramic oscillator.
 
Not using a crystal in a timing-type application might be a mistake?


Could be. Keep in mind that the project is a work in progress and a learning process for myself. But so far I think the timing issues can be solved in software.
 
However, good work in getting the initial fix out quickly.

Why did this problem never show up in previous hardware versions?

Because previous versions had ceramic oscillator, which is more accurate than the internal clock.
 

Thanks, Gary



 
Reply all
Reply to author
Forward
0 new messages