|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.
|Re: DS1302 Time Drift||DEKi||9/1/12 9:22 AM|
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.
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.
|Re: DS1302 Time Drift||garygid||9/25/12 8:44 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||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
Perhaps resetting the mpu clock every minute instead of once
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?
|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
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.
Sure, this is easy to change in the code.
Sure, you can add a crystal or ceramic oscillator.
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.
Because previous versions had ceramic oscillator, which is more accurate than the internal clock.