Clock drift - is the precision of the crystal the only culprit?

Question

I've a wall clock (sorry, code's a mess, look for updateClockVars) which makes use of the Timezone library (and ultimately Time). Nothing fancy, call millis() every loop; turn to Hrs, Mins, Secs; display on LEDs.

The magnitude of the drift I am seeing on my 2 Arduino Pro Mini - compatible boards - up to ~8% lag, not a typo - blows my mind. Replacing the 16MHz quartz with one bought at a local retailer didn't help much (~33% improvement). Is something else at play here?

Answer 1

The problem is the interaction between the interrupt handler that updates the value for the millis() function and the neopixels show() function.

To maintain the counter for the millis() function a interrupt is triggered approximately every 1.024 ms.

When the show() function is called all interrupts are disabled to get the precise timing needed to send the data to the neopixels. For a 60 led strip this takes about 1800 microseconds (60 leds * 24 bits * 1.25 us per bit) so at least one interrupt is skipped each time you update the display.

This page has details about how the millis() function works.

Answer 2

TL;DR You're doing it wrong. Use RTC.

Ok, longer explaination is required here. millis() is not accurate and here is why.

First, grab official Arduino source code from their Github repo. The file Arduino-master/hardware/arduino/avr/cores/arduino/Arduino.h contains few interesting macros (I'm pasting grep output here):

Arduino.h:#define clockCyclesPerMicrosecond() ( F_CPU / 1000000L )
Arduino.h:#define clockCyclesToMicroseconds(a) ( (a) / clockCyclesPerMicrosecond() )
Arduino.h:#define microsecondsToClockCycles(a) ( (a) * clockCyclesPerMicrosecond() )

At 16MHz clockCyclesPerMicrosecond() will evaluate to 16. Keep this number in memory.

Those macros are used in Arduino-master/hardware/arduino/avr/cores/arduino/wiring.c:

// the prescaler is set so that timer0 ticks every 64 clock cycles, and the
// the overflow handler is called every 256 ticks.
#define MICROSECONDS_PER_TIMER0_OVERFLOW (clockCyclesToMicroseconds(64 * 256))

// the whole number of milliseconds per timer0 overflow
#define MILLIS_INC (MICROSECONDS_PER_TIMER0_OVERFLOW / 1000)

MICROSECONDS_PER_TIMER0_OVERFLOW macro is evaluated as (64 * 256)/16 - a dodgy looking 1024. Look how they round it down to calcuate MILLIS_INC.

Let's assume that you run your Arduino with ideal main clock signal. At 16MHz main clock, the timer frequency is 1.024kHz, not 1kHz. This results in 2.4% inaccuracy. You can get away with that in most cases, but not when you're building a clock.

This 2.4% error is best case. Your main oscillator is not 16MHz - it has it's own inaccuracy, that is unknown and it sums up.

You should use an external, accurate time reference provided by RTC module. When assembled properly, they guarante low time drift, temperature compensation and other goodies. Be smart - use RTC. :)

If you are scared of I2C RTC modules, you may find my tutorial and another tutorial on MCP7940N RTC module. Know-how is applicable with other RTCs as well.

Answer 3

Expanding on my previous comment...

As I said before, I suspect the NeoPixel library to be blocking interrupts for too long when you strip.show(). If a timer interrupt fires while interrupts are blocked... it's not a big deal: the interrupt request is put on hold and serviced as soon as interrupts are enabled again. If two timer interrupts fire while interrupts are blocked... you have a problem: the interrupt service routine will be called only once, and your clock will miss a tick.

Craig has worked out the timings in his answer: the timer interrupt fires every 1.024 ms, and NeoPixel blocks interrupts for 1.8 ms. So it is perfectly expected that, from time to time, you will have two timer interrupts within this 1.8 ms window.

Here is a quick hack that could solve your problem: if you strip.show() right after a timer interrupt is serviced, then only one more interrupt should fire during the subsequent 1.8 ms window, and you should be fine. So you could simply add this right before strip.show():

/* Wait for a timer interrupt to be serviced. */
uint32_t lastMillis = millis();
while (millis() == lastMillis) /* wait */;

A possibly better solution would be to avoid blocking interrupts for so long. NeoPixel blocks them in order to comply with the very tight timing requirements of the WS2812 LEDs. But it turns out the WS2812s are not nearly as picky about timings as their datasheet suggests. You can drive them in a more relaxed way, with interrupts enabled except for 1-bit durations, and they still work fine. For a detailed explanation and sample code, see NeoPixels Revealed: How to (not need to) generate precisely timed signals.

A third solution would be to follow the general advice given here and grab an RTC. However, although it certainly is a good and clean solution, I have to admit I completely agree with your comment “I still didn't catch WHY that is better – it's a quartz either way”.