DS1302 Time Drift

Showing 1-8 of 8 messages
DS1302 Time Drift DEKi 8/28/12 2:41 AM
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
Re: DS1302 Time Drift Rayshobby 8/30/12 7:31 AM
So far I haven't noticed any time drifting caused by MC34063. 

-Ray


On Tuesday, August 28, 2012 5:41:50 AM UTC-4, DEKi wrote:
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
Re: DS1302 Time Drift DEKi 9/1/12 9:22 AM
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
Re: DS1302 Time Drift Rayshobby 9/1/12 10:01 AM
Hi David,

Thanks for the info. I've taken a look at App Note #58. I am aware that the crystal and capacitor should be as close as possible to the chip. These have been considered when I designed the PCB. I didn't know about the tip of placing ground place around the crystal. It's good to know for future designs.

-Ray
Re: DS1302 Time Drift garygid 9/25/12 2:30 PM
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?

Re: DS1302 Time Drift Rayshobby 9/26/12 7:57 AM
This is not a problem with the RTC, see my reply to the previous post.
Re: DS1302 Time Drift garygid 9/27/12 7:05 AM
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

Re: DS1302 Time Drift Ray 9/27/12 7:16 AM
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