I’m happy to report that the culprit has been identified: it’s the oscillating circuit.
I measured the oscillator frequency using the following methodology:
- Arduino running the simple Blink program (http://arduino.cc/en/Tutorial/Blink), with 500 ms on, 500 ms off.
- Oscilloscope + frequency counter with: probe 1 on Arduino pin 13, ie the 1 Hz signal to the LED; probe 2 on Atmega pin 9, ie the internal oscillating amplifier output to the crystal.
- All frequency and period measurements averaged over 3 minutes.
- First series of measurements with probe 1 connected only. The oscillator runs at its normal frequency, frequency_unloaded, unknown. We measure the period of output 13, period_unloaded.
- Second series of measurement with probe 1 + probe 2 connected. The oscillator is loaded with the capacitive charge of probe 2 (15 pF) ; we measure its new frequency, frequency_loaded as well as the new period of output 13, period_loaded.
Here are the results:
Period_unloaded = 1,003,595 µs
Period_loaded = 1,00,1726µs frequency_loaded = 15,942,950 Hz
From which we derive frequency_unloaded = 15,973,908 Hz
Compared to the nominal 16 Mhz figure that’s a 1600 ppm error.
Conclusion: as stated earlier interruptions may «collide» with non-interruptible code, in my case this would result in variations of the measured period from measurement to measurement, small variations however.
What we have here is a lousy oscillator. This can be blamed on any combination of crystal accuracy, badly chosen capacitive load, oscillator layout on the PC board etc.
Ah, yes, but it’s «zero carbon footprint», who can beat that ?