# Interpreting Crystal Deviations

I am investigating the accuracy of a crystal mounted on a MCU. The API provided by the MCU manufacturer has a TimeGet48 function that returns a 48-bit number indicating microseconds elapsed.

What I did is to configure the MCU to output its internal clock every 10 seconds via UART.

'19:15:18.830 Time: 0000, 947edfeb',
'19:15:28.829 Time: 0000, 95177715',
'19:15:38.829 Time: 0000, 95b00e3f',
'19:15:48.828 Time: 0000, 9648a569',


Above is a portion of the log. Each line of log consists of PC's clock time, high 16 bits of the 48-bit timer, then low 32 bits of the 48-bit timer. I plotted t_crystal - t_pc vs. t_pc below:

This plot shows the time deviation over a period of about 14 hours. I was expecting monotonous increase or decrease but this figure really makes me wonder how this is possible.

I am thinking of the following factors:

1. PC clock (I use Windows 7) might not be accurate. Probably PC will sync to a global time server once every few hours. However, when I investigate this in Task Scheduler. My time synchronization was set to 1AM every Sunday of every week. This log was captured on Tuesday so PC time would not change due to synchronization.
2. PC clock and crystal time were both subject to truncation or rounding obviously.
3. Temperature changes due to aircon. I logged these data over night (6pm to 8am next day). Aircon in my office shuts down after 6pm and turns on at 8am.

These factors would definitely impact the crystal deviations. However, none of these makes the zigzag-shaped fluctuation sensible.

[Update]

I tried Brian Drummond's suggestion and let it run for 4 hours and it indeed worked. Here is new figure.

• I was doing something recently with Windows 7 and default settings as above where I needed to set my PC clock a few hours in advance. While I didn't take much notice of how often exactly over the course of a day several times it reverted back to the correct time. Maybe you could do something similar and set the clock to tomorrow and see if your system is doing that as well. Might have been different in my case because I was setting the time so far off perhaps security related services triggered a sync, maybe try something smaller as a 2nd step. – PeterJ Sep 10 '14 at 2:56
• Nice suggestion. I set my PC clock 1 hour faster and am logging the time every 5 seconds to see how soon Windows will set it back. – foresightyj Sep 10 '14 at 3:05
• @PeterJ Windows set it back in about 7 minutes, which is rather quick. Even if Windows syncs time periodically, the figure still doesn't make sense. I am thinking about what factor is causing the alternating positive/negative slopes. – foresightyj Sep 10 '14 at 3:17
• Disconnect the PC from the network so that NTP cannot resynchronise it. You will probably see a simple monotonic drift between the two oscillators. – Brian Drummond Sep 10 '14 at 7:59
• You might be a "time nut". This page (and the parent website) make good reading material: leapsecond.com/time-nuts.htm – pericynthion Sep 19 '14 at 18:44

The issue does appear to be NTP resynchronising the PC clock, rather than any error in the crystal oscillator itself.

Disconnecting NTP shows a different interesting pattern : apparently random deviations within a band about 15ms wide, which itself drifts slowly over time.

The default PC "system time" clock ticks at about 55Hz or about 18ms period : this is almost certainly the cause of the wide band. If you zoom in on the "thick line" in the earlier measurement I would expect to see the same sort of pattern.

So the true deviation would be the gradient of that band : around 0.005 seconds in about 3 hours (10000 seconds) or 1 second in 200*10000 seconds or 0.5ppm.

As a typical crystal spec is around 20ppm and temperature dependent, this is a good result, better than can be relied on in the long term.

A good followup experiment would be to change the temperature of the MCU + crystal (hang it outside the window or under a desk lamp!) and observe if (and how) the gradient changes under those circumstances.

• I accept your reply as the final answer. Thanks! The result was really good as I tested in an air-conned room so the temperature was nearly constant. Under worse temperature environment it would probably drift more. – foresightyj Sep 19 '14 at 10:07
1. PC clock is not accurate - NTP (as used by high level OS) can have several error sources, none of them under your control. You need a better reference clock which you have control over. A GPS disciplined timing server is a relatively cheap solution, there are even open source NTP and PPTP embedded servers with a GPS module.
• I know PC clock is inaccurate but I don't have more accurate time sources at hand. What I intend to do is get a rough idea of how accurate the MCU crystal is relative to a PC clock. If PC synchronizes to a NTP server constantly, I will expect a discontinuity at the point of synchronization but never will there be intervals where the deviation increases monotonically and after a while it became decreasing monotonically. – foresightyj Sep 10 '14 at 7:35
• I am thinking of a possible cause but I cannot be certain. Probably it is the PC that is causing this funny behavior. It can be that the PC's activity varied even though I left it idle the whole night. If PC's activity is varying, the CPU will probably have different temperature, thus causing the PC's clock to drift up and down. – foresightyj Sep 10 '14 at 7:41
• Network congestion, latency, router problems, switch problems, both at your place and at the server's end,and finally, temperature changes are just few of the factors that can affect such measurements. You can eliminate all the network related issues with a local time reference. – Lior Bilia Sep 10 '14 at 11:12

I suspect you're seeing the granularity of the rate-tuning in your PC's clock.

Basically, each time it checks NTP, you get a fast (but not instant) slew back to approximately zero deviation, and then it adds/subtracts 1 from the value that tunes the clock drift.

What I think then happens is your system is oscillating between a drift-compensation value of n and n+1, where the correct value might be n+0.5. I bet the tuning register is maybe 8 or 16 bits, and there is just not enough precision there to set the tuning exactly correctly, so you get dither around the desired value.