I know this question is directed at Russell, but I can't resist commenting.PhilD13 wrote:Maybe a surface mount could be squeezed on the bottom? Provided something can be found to squeeze in, would that work to fine tune the clock if the other cap is left at 10pf?
The crystal load already is already asymmetric, even though the ATmega328p datasheet recommends a symmetric load. XTAL1 has a pin capacitance of 18 pF; XTAL2, 8 pF. XTAL1 is the input to the inverting amplifier; XTAL2, the output. I'm no expert on oscillator circuits, but I think that using more capacitance on XTAL1 (crystal output, inverter input) means that the output of the crystal on XTAL1 is dampened a bit by the additional capacitance, and using less capacitance on XTAL2 (crystal input, inverter output) means that the microcontroller's inverting amplifier uses less current to drive the crystal. Making the crystal load more symmetric might be a good idea. Maybe try a a 1-10 pF varcap on XTAL1 and a 15 pF cap on XTAL2?
I give this advice for people who would like the drift correction to kick in as soon as possible. I suspect most users won't want to go through the trouble. They'll just wait until their clock has drifted for a few minutes, correct the time like they normally would, and probably never notice that their clock somehow became more accurate. If those users set the time exactly, the drift correction will be similarly exact. If those users set the time within a minute or so, the drift correction might not be perfectly exact, but it should still be an improvement.PhilD13 wrote:You generally say that your firmware initially needs to be kick started in order to begin to work for drift correction and this is done by the user making a manual correction after a period of time of about a week or two or after greater than a 15 second difference is noted.
If crystal speed is being measured, how would the clock determine the length of an hour without using the crystal? Are you thinking of temporally attaching an external time reference such as the PPS output of a GPS module?PhilD13 wrote:Is it possible to kick start the drift correction automatically by something along the lines of the following?
You've probably already seen this option, but there is way to kickstart the drift correction immediately if you already know--or are willing to measure--how fast or slow the clock runs. Defining the AUTODRIFT_PRELOAD macro in config.h preloads the specified drift correction value as the first element in the 7-element EEPROM array that holds the automatically calculated drift correction values; that makes it equivalent to going through the first let-the-clock-drift-by-at-least-15-seconds-and-correct-the-time cycle.
The situation is a bit worse than that because there is up to a second of rounding error as well, so given the human error, I'd place accuracy at about two seconds of total time-setting error. But that really isn't so bad. Let me describe a plausible use scenario:PhilD13 wrote:This is probably more accurate than someone manually making a time correction. I can only get two clocks to within about a quarter to half second of each other and the time base when manually setting them or initially correcting time.
A typical Adafruit clock (unmodified, except for installing an ATmega328p and xmas firmware) might drift by 20 seconds in a week, so a user anxious to enable drift correction might set the time after a week. Two seconds of time-setting error means that the automatically calculated drift correction factor will have an accuracy of 2 seconds / (7 days * 24 hours/day * 60 minutes/hour * 60 seconds/minute) = 3.15 ppm. So with temperature-related error, the user might expect an accuracy within 5 ppm.
It will take a month or two for the clock to drift by more than fifteen seconds, so the next automatically calculated drift correction factor will have an accuracy of 2 seconds / (30 days * 24 hours/day * 60 minutes/hour * 60 seconds/minute) = 0.74 ppm. Factor in temperature variation, and the error of the automatically calculated drift correction might be more like 3ppm.
Two automatically calculated drift correction values are now stored in the 7-element EEPROM array for drift correction values. The clock is supposed to use the median value, but since there are only two values, there is no single median. Instead of averaging the two values, the clock again uses the first estimate. (I think... actually I don't remember which one is used, but it doesn't really matter.)
After another month and another time correction, another 3 ppm drift correction value is added to the 7-element array. At this point, the median drift correction value in EEPROM will be accurate to about 3 ppm. It will take a couple months for the clock to drift by another 15 seconds, and the accuracy of the next automatically calculated drift correction factor will be even better. At that point, the drift correction has pretty much converged in terms of accuracy.
Eventually, the 7-element array of drift correction factors will be full, and the oldest value--typically the least accurate--will be overwritten. The fact that old values eventually get overwritten helps the automatic drift correction adapt to gradual crystal aging.
I know Russell and Phil have already seen this information, but the gory details of the automatic drift correction algorithm are described elsewhere. The implementation itself is spread across several functions in time.c: time_init, time_autodrift, time_settime, time_newdrift, and time_loaddriftmedian. The time_autodrift function is the one that is called once per second to perform 1/128 second adjustments as needed.