[time-nuts] How to properly characterize 32kHz oscillators manually and with a microcontroller?

[Nick Sayer]

I went through this exercise some time ago with my Crazy Clock.

The Crazy Clock is itself an ATTiny45 clocked with a 32 kHz crystal. I desired to determine the accuracy of the oscillator. I wound up making a purpose-built frequency counter.

First, the device under test gets special firmware that copies the system clock to a pin. The best I could do there is set up a timer to toggle an output on overflow and have it overflow constantly. The result is 16.384 kHz nominal.

The counter is a “backpack” on a 2x16 LCD display (I make a lot of those). The controller is an ATTiny84. 6 of its pins go to the LCD (some shared with the programming interface). The system clock is derived from an external input, which for me is supplied by a GPSDO. The board has a self-biased inverter and DC blocking cap on the input.

The crazy clock interface is a 1.8v LDO to supply power and an input line that goes to the 16.384 kHz output from the DUT. That sample line goes to the ICP pin on the controller.

In the firmware, the timer that has the input capture ability is set to free-run at the system clock frequency. The ICP interrupt reports back the timer delta from the last interrupt. Nominally, you’d expect 16,384 counts. I calculate the delta and accumulate that for 10 seconds before reporting the result on the LCD.

The LCD shows the actual delta, what that means in ppm and the two byte calibration value I write into the DUT’s EEPROM. The DUT’s *normal* flash code has the ability to trim the system clock by the factor stored in the EERPOM (signed value in 100 ppb units).

I never made this whole thing public, because it seemed to me at the time to be a very specialized item useful to nobody else. But I can cobble together my schematics and firmware. The way I wrote the code, it ought to be easy to have it work for other frequencies (both reference and DUT).

> On Jun 27, 2016, at 8:22 AM, Pete Stephenson <pete at heypete.com> wrote:
> 
> Hi all,
> 
> I have a few Maxim DS3231 temperature-compensated real-time clock
> chips I use for various embedded hobby projects. They're specced to
> have an accuracy +/-2ppm between 0 Celsius and 40 Celsius. One is from
> a standard, reputable vendor, while a few are from somewhat more
> dubious internet sellers. While all the chips work and seem to
> maintain reasonable time over a period of a few weeks, it's possible
> that some don't meet spec and I'd like to test them and make sure they
> do what they're supposed to.
> 
> Here's what I've been doing manually, and what I hope to accomplish
> using a microcontroller. Any tips are very welcome.
> 
> ===== Manual Approach =====
> 
> I've manually tested a few of the chips using a digital storage
> oscilloscope and a Trimble Thunderbolt's PPS output. Here's how I've
> set things up:
> 
> 1. Enable the 32kHz output on the DS3231 and wire it appropriately.
> (The 32kHz output shows up on the oscilloscope.)
> 
> 2. Set the oscilloscope to trigger on the Thunderbolt's PPS output. As
> expected, the DS3231's 32kHz output drifts slowly relative to the PPS,
> so the pulse train seems to move slowly to the left or right
> (depending on the chip) on the scope.
> 
> 3. Wait until the rising edge of one of the 32kHz pulses is (visually)
> lined up with an arbitrary line on the scope's graticule, then start a
> timer.
> 
> 4. Wait until the rising edge of the next pulse drifts to the same
> line on the graticule -- that is, it has drifted by one cycle -- and
> then stop the timer.
> 
> If I'm particularly motivated, I'll watch the scope for longer and
> count the time it takes for the clock to drift two or three cycles.
> 
> As an example, one of the clocks drifts by one cycle in 120 seconds.
> 
> I then calculate the stability as follows:
> 
> Stability = (1 cycle / 120 seconds) / (32768 Hz)
> = (1 cycle / 120 seconds) / (1 second / 32768 cycles)
> = 2.54*10^(-7)
> = 0.254 ppm.
> 
> Is this right so far? If so, that clock seems to be well-outperforming
> the specs.
> 
> I've tested a few chips at a few different temperatures (e.g in the
> freezer, in direct sunlight, etc.) and they seem to drift faster for a
> minute until the chip measures and corrects for the temperature
> change, at which case the drift returns to the normal value.
> 
> ===== Automated Approach =====
> 
> The manual approach is handy, but only measures short-term drift and
> is subject to errors. I'd like to automate the measurements using a
> microcontroller (I'm familiar with AVRs, mainly the ATmega328 and
> ATtiny85 using the Arduino IDE, for what it's worth).
> 
> My plan was to have the microcontroller count the number of cycles of
> the 32kHz clock over a period of time, say 1000 seconds. If all was
> perfect, it'd count exactly 32768000 cycles during this time.
> 
> I'm a little concerned about the speed at which the pulses need to be
> counted. The 32kHz pulses come in every ~30.5 microseconds, and
> handling an interrupt on an ATmega328 running at 16MHz takes about
> 5.125 microseconds[1] plus whatever's done in the interrupt routine
> (e.g. incrementing the PPS counter). Would it make sense to use
> interrupts for both the PPS counter and the 32kHz counter? Even if the
> CPU is doing something, it knows an interrupt is pending so it
> wouldn't miss any counts (assuming it could handle the interrupt
> before the next one comes in). Alternatively, I could use a tight loop
> to see if the pin for the 32kHz signal goes high and just use
> interrupts for the PPS pulse. Time-sensitive code on microcontrollers
> straddles the edge of my knowledge, so any advice would be
> appreciated.
> 
> Seem reasonable? Any tips on doing this better?
> 
> Cheers!
> -Pete
> 
> [1] http://www.gammon.com.au/interrupts
> -- 
> Pete Stephenson
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.