Poor clock accuracy of UNO

liudr:
Very impressive presentation! What data acquisition system did you use to produce this data?

Thanks 8) ...though it wasn't awfully sophisticated.

The Uno board's timers were programmed to trigger an interrupt every 16 million clock cycles, and the interrupt routine sends a "tick" byte over the serial port. In between ticks it also reports temperature info over the same port. A short Perl script running on a Win7 PC recorded timing info every time it caught a byte on the COM port. Perl's timing appears to be very precise, but it only sees new serial data at 10ms intervals and a quick web-search seemed to imply that this is a Windows limitation.

Another option was to send pulses to the line-in connection of the PC's sound card, but I don't know if the sound-card's sampling is synced with the real-time clock. Although now I think of it, I could use another Perl script running on the PC to generate accurate reference audio ticks and feed those into the second line-in channel.

For the plot I made a running average of the tick interval over 10 minutes: 10ms / 600s = 16.7ppm, which is why the data points line up at 16.7ppm intervals. A longer averaging period would cover too much temperature variation: the gaps between the lines would shrink, but the overall data scatter would grow.