TUNE your Ice Tube CRYSTAL: HARDWARE or J. Archie software

[russell 27]

32768 WAVE.PNG (6.62 KiB) Viewed 1726 times

If your clock's crystal frequency is accurate, so will be your clock. The load capacitors C8 and C9 are a little rough; clock to clock, all parts involved in the oscillator circuit have slightly different tolerences, including the crystal and micro controller. I tried some of the software deviation correction available, depending on type, it takes a little trial or time to get correction tuned in. JSGF's software is one of my favorites, as well as the manually set drift correction, my personal setting is a -23 drift correction, yours would likely differ. Unfortunately after power loss, drift correction is reset back to zero, and needs to be reset. After becoming familiar with all the features of John Archie's code, it's hard to go back. Although, I've not had success with the automatic time deviation correction, my clock gains about two seconds a day. So I decided to build my own external oscillator. The crystal is buffered or isolated, so it's resistant to external noise, and easy to connect a scope or frequency counter to the output and adjust the load capacitance to tune the crystal to exactly 32,768 hertz. For ease of tuning I used a trim capacitor, which helps get an exact value. A non-conductive screwdriver would be best. 32,768 hertz by the way, can be exactly divided by the micro controller to reset once every second, accurate resonance = accurate clock. If your crystal's frequency is off by just 1/2 hertz, say 32767.5, your clock would lose about 1.25 seconds a day. Off by 1 hertz, 32767 hertz, your clock would lose about 2.5 seconds per day. On the other hand, if frequency is off by only .1 hertz, it would take about 3.8 days to lose a second. Temperature effects deviation as well, but much less than frequency deviation. I didn't know how accurate my scope was, but I tuned to exactly 32.7680 Khz. For time reference I used my old Bulova wrist watch positioned right next to my ice tube, temperature deviation in the room was about 67 to 74 degrees Fahrenheit. Using John's firmware, I compiled config.h to use external oscillator. It took about five days to lose one second. Periodically I checked oscillator frequency with scope, and during the cooler room periods, read frequency was 32.7879, a .1 hz deviation, which would account for the time loss, and consistent with the temperature chart.

Deviation.gif (11.56 KiB) Viewed 1726 times

During this time I also unplugged the clocks power supply several times to check battery backup switching and measure frequency, all good. At this rate I would lose 6 seconds a month or about 1 minute 15 seconds a year. I consider this excellent accuracy without any correction. I understand adding this to the clock would take a little finessing the circuit board, but very possible. Another option, that should be just as viable is tuning the circuit board capacitors C8 and C9 directly. Unfortunately connecting a scope to the Xtal terminals directly to measure frequency, would just snub out the oscillator, or at the very least add unwanted capacitance. The crystal frequency needs to be sent to an external chip pin (buffered), and can be read accurately from there. If anyone knows how to do this, I very much appreciate the heads up on the how, I want to test this. Even a simple program that could be flashed into Atmega just to tune the load capacitors, clock firmware could then be reinstalled afterward.

32_768.png (6.23 KiB) Viewed 1726 times

If you have interest in a pre-built circuit, MAXIM offers the DS32kHz chip, you can check out the post on that Here:.

[phild13]

I just changed the values of C8 and C9 to 10pf on my original purchased Adafruit board and it keeps time very well with no other modifications. In fact it keeps time better than John's Rev D with drift correction. With Johns drift correction, the clock has to become off by at least 15 seconds then be reset as accurately as possible in order to work and have some accuracy. Currently the REvD clock gains about 5 seconds a week after the last firmware update I did, so I have about 2 more weeks to go before it is off enough to make a time reset accurately.

I have not worked on the design for awhile, but I was in the precess of making room on the main board to accommodate (or try to) the DS32kHz chip in surface mount.

I have not tried this but you could use the 328 as a buffer by setting the CKOUT fuse and connecting a scope to the CLKO (pin 14) pin. You should see a more or less square signal. You might need to define the pin for the CKOUT at least temporarily while making measurements.

[russell 27]

Hey Phil

I built John's clock on his latest board version, 10 pf there(recommended C8,C9) runs fast for me, about 2 1/2 seconds a day. John has been very generous, helping me fine tune some of the software things I wanted on my clock, but for some reason no matter how much I reset, my clock gains time. Actually I have three clocks going right now. ADAFRUIT, XMAS clock, and my own prototype, which is all wired together on three small proto boards. If you saw it you might wonder how it's working; actually it awakens me everyday. I'm using John's software. The really great thing about this clock is I can easily change software or hardware for all my trials. I changed the Push/Pull filament MOSFETs to (2) IRF540 N channel and (2) IRF9520 P channel. Virtually no voltage drop through these, no need for the 317 regulator. These wouldn't fit very well on the ADAFRUIT board, but easy to implement on mine. Since hardware is my thing, I just wanted to build my own oscillator, Actually it's a PIERCE Oscillator and will be easy to implement on my board. I'd say the same type of setup is inside the DS32kHz chip, with temp correction. I thought some would have an interest in accurizing their clock crystal, but would not necessarily want to add circuitry. I tried the CKLO buffer deal, but I may just not have had it right. Atmel has an application note AVR4100 dedicated to this subject , and some sample code. If you have interest in taking a look, maybe you could set me straight on implementation.

AVR4100.zip

(611.62 KiB) Downloaded 114 times

Thanks

[phild13]

Yea, the clock runs very fast on Johns hardware even using 10pf caps. At least it does initially, then when set like he describes will run a bit slow.

On the current Adafruit boards, changing the caps from 20pf to 10pf will make the clock more accurate and as the Adafruit design does not use the Temperature compensation of Johns firmware, then Johns firmware will work just fine and be as accurate as the Adafruit firmware.

I don't have a scope so I can't check stuff out. I'm not sure the firmware you linked to has the 328p in it so it may not work. If it does, you will need to find in the code which pin it is on.

[russell 27]

Thanks for the heads up there. My Xmas clock acted the same way. I thought maybe I had something set up wrong.

[jarchie]

If you're using the xmas firmware for this work, the automatic drift correction is probably a hindrance. The automatic drift correction algorithm determines if the clock is running fast or slow when the user changes the time. The idea is that, when used normally, the clock will eventually correct for any systematic time drift and eventually will even adapt to changes in crystal frequency due to aging. But without an accurate time reference, the only way for the clock to determine time drift automatically is to wait until the user resets the time forward or back. Unfortunately, the process takes time and may be bothersome for those who want their clocks to have excellent accuracy right off the bat. But the advantage is that the clock user need not fine-tune a drift correction constant or even know anything about the drift correction method.

Phil is also correct in posting that the clock must drift (and be corrected) by at least 15 seconds before xmas will estimate how fast or slow the clock is running. The 15-second rule seems peculiar, but is necessary for robustness: if a user accidentally enters the set-time menu, one way to exit is to just hit "set" three times. That would cause the clock to determine (incorrectly) that it is running fast by a second (or however long it takes to hit "set" three times). The exact value (15 seconds) may be modified in the code by editing the TIME_MIN_DRIFT_TIME macro in time.h.

On a new branch, I've added new compile time options to customize the drift correction behavior. Although that code has not yet been well-tested, I hope it will be helpful here.

EDIT: The new compile-time options seem safe and useful enough that I merged them into the main xmas-icetube branch. The new options allow a user (1) to disable automatic drift correction for testing and debugging purposes, (2) to preload the amount of drift correction the clock needs for accurate timekeeping (but still allow the clock to refine that value automatically), or (3) to specify a constant amount of drift correction that the clock will always use.

[russell 27]

As we had previously discussed, I had trouble tuning in my Xmas software with auto drift correction, It's what led to the external oscillator addition. Setting config .h to use external crystal worked great, I've lost a total of two seconds, by my rough trial, I would imagine auto drift has never been initiated. What you are probably talking about though is a crystal test with your code. I never posted because I wasn't sure if anyone was interested. Setting Low Fuse to A5 will enable pin 14 as a direct Oscillator output of 32,768 Hz, no division or prescaler. I erased program flash so there was no possibility of interference. This works very well. But BEWARE, Attiny_USB isp programmer would not readily communicate after changing to this fuse setting. SOLUTION EDIT: By defining BIT clock in avrdude to -B 128, fuses are easily flashed again using the watch crystal frequency. Sending buffered crystal frequency via clock out fuse works well and I recommend this method over the software test program. My other uProg programmer and FUSE BIT doctor I posted, could easily change fuses back. Another method I used was the above AVR 4100 TEST program that I tweaked and compiled, this sends direct oscillator value, divided by two, to pin 17. So tuned frequency would be 16,384 Hz, this also worked well. All that's needed is to flash in the test .hex, no need to change fuses. I directly tested your Xmas clock here, what I found was quite interesting. With the installed 10 Pf crystal load capacitors, measured frequency with both methods was within .1 hertz. Under running conditions my clock continued to gain about 2.5 seconds per day. With a .1 Hz deviation I would not expect to see this result. Definitely interested in looking at your new code, but as a hardware man, I like going right to the source.

Anyone interested in the TEST PROGRAM, it's set up for the 328p, by changing the MCU in Make file to Atmega 168, should work just the same for standard ICE TUBE, may work as is.

oscillator_test.zip

(7.79 KiB) Downloaded 87 times

[jarchie]

Setting config .h to use external crystal worked great, I've lost a total of two seconds, by my rough trial, I would imagine auto drift has never been initiated.

Setting the external clock in config.h, in theory, should have no effect on the drift correction code. Initially, there should be no drift correction enabled; the clock time must drift by at least 15 seconds and then be corrected before xmas starts to compensate timekeeping for drift.

What you are probably talking about though is a crystal test with your code.

I'm not sure what you mean by a crystal test, but the new additions to the xmas code provide a way to completely disable drift correction. Since drift correction has the capacity to make the clock run faster or slower as needed to correct for time drift, disabling drift correction seems useful for testing any hardware modification that changes the crystal oscillation speed.

[russell 27]

Well you have me confused now. My external crystal oscillator and in circuit crystal are tuned almost exactly the same. The external crystal keeps great time, the in circuit crystal gains 2.5 seconds a day. The only real difference is the code, I suppose possibly, the in circuit crystal may not be quite as stable over the long haul, as the external oscillator circuit. (Even the MAXIM chip specs a one year deviation of +/- one minute for the 0 to +40 degree Celsius compensated chip, four minutes for the other versions.) But it doesn't really explain that kind of deviation correction; Unless the way your code learns, it cannot go back(reset) without an eeprom reflash. Your deviation correction is adding excessive time to a count that should take about three and a half days to lose one second, without correction. Every time I reset, clock continues to gain 2.5 seconds a day. Thanks for including the option to manually adjust or disable the deviation. Is three seconds about the max deviation correction?

If you're using the xmas firmware for this work, the automatic drift correction is probably a hindrance.

Both of the oscillator test methods are set up in such a way that your deviation correction would not be applicable.

[jarchie]

Unless the way your code learns, it cannot go back(reset) without an eeprom reflash.

That would explain the difference. The automatically learned drift correction data is stored in EEPROM. So unless you reprogram the EEPROM, any old drift correction data will be restored and applied. The reason for storing these data in EEPROM is that the automatic learning process takes weeks or months, so I would not want the clock to forget the learned drift correction when the battery dies and the power goes out.

Both of the oscillator test methods are set up in such a way that your deviation correction would not be applicable.

Ah, good.

Is three seconds about the max deviation correction?

No, but good guess. If the clock automatically "learns" that the drift is above ~17 seconds a day, the clock will assume that the user incorrectly set the time and ignore that information. (Like the 15-second rule, this is another rule necessary for robustness.) But the clock will trust the drift correction information loaded from EEPROM, so if you don't program the EEPROM when flashing new program code, the drift correction can, in theory, make the clock run faster or slower by a maximum of ~11 minutes per day! But that 11 minute figure is the worst-case scenario for an improperly programmed chip where the data stored in EEPROM is junk.

[russell 27]

If I do go the software route, I do appreciate the manual setting now, I don't like the auto correction.

[jarchie]

If I do go the software route, I do appreciate the manual setting now, I don't like the auto correction.

In that case, I'm glad I incorporated these changes into the master branch.

[russell 27]

So am I. I thought I'd put it to the test. My Xmas clock in circuit crystal deviation is only a .1 Hz deviation (32767.9 Hz) with the 10 Pico farad capacitors. 8 pf or so would probably tune exact. The point of this topic was to tune so no software deviation was needed, but since you took the time, which I appreciate, I wanted to see if I could correct the rather small deviation with the code. Even without correction it would take a year to lose ~ 1 minute 36 seconds. Basically it takes 32,768 reset counts for a -1 hertz deviation to show up as a one second loss, about 9.1 hours. I figured with a .1 hz deviation it would take 3.8 days to lose a second. By using the example calculations you gave in config.h, I came up with:

.2632 daily second loss X 128 correction refresh = 33.6896 -----> 86400 seconds a day/ 33.6896 = 2565

Code: Select all

#define AUTODRIFT_CONSTANT 2565

I don't know if you had this small of a deviation in mind for correction, but the way I understand, every 2565 seconds or (42.75 minutes) time will be corrected + 1/128 second. I like it. See what happens.

Excerpt from config.h:

If one already knows how fast or slow the clock runs without drift correction, one might wish to preload this information so that the clock will keep accurate time immediately after flashing. The desired drift correction is defined by a single number. The magnitude (absolute value) defines how often a 1/128 second correction must be made. If the clock is slow, time must be adjusted *forward*, so the sign should be *positive*. If the clock is fast, time must be adjusted *back*, so the sign should be *negative*. A drift correction value of zero indicates that no drift correction should be performed. For example, assume a clock runs slow by 3 seconds per day, typical of an unmodified Adafruit Ice Tube Clock. To compensate, the clock must make 3 * 128 = 384 corrections per day, since each correction is 1/128 second. Those corrections must be made over one day or 24 * 60 * 60 = 86400 seconds. Therefore, the clock should corrections at intervals of 86400 / 384 = 255 seconds. Because the clock runs slow, the drift correction value should be positive 255.

Defining a drift correction value with AUTODRIFT_PRELOAD enables drift correction by the specified amount immediately after programming. But the clock will still determine if it is running fast or slow with the user changes the time. This behavior will allow the clock to automatically refine the preloaded drift correction value and adapt to changes crystal frequency over time.

Defining a drift correction value with AUTODRIFT_CONSTANT also enables drift correction immediately after programming, but the clock will always use the specified drift correction value. The clock will not automatically determine if it is running fast or slow when the user changes the time.

Defining the AUTODRIFT_CONSTANT macro as zero will completely disable automatic drift correction.

Thanks John

[jarchie]

Those calculations look right to me. The drift correction value is stored as an int16_t, so it can be any value between -32768 and 32767; you're well within the allowed range.

[russell 27]

After some time, the original #define AUTODRIFT_CONSTANT 2565 I used, was a bit light on correction. I went to a 2100 seconds for AUTODRIFT_CONSTANT, which equates to a +1/128 second correction every 35 minutes. I don't understand your code as you do, but the MAX #define TIME_MAX_DRIFT_TIME in time.h file is 1200 seconds (20 minutes). My MAX is a bit larger. Would this keep the auto drift from defining itself properly in my clock.