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:

enter image description here

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.


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

enter image description here

  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – PeterJ
    Commented Sep 10, 2014 at 2:56
  • \$\begingroup\$ 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. \$\endgroup\$ Commented Sep 10, 2014 at 3:05
  • \$\begingroup\$ @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. \$\endgroup\$ Commented Sep 10, 2014 at 3:17
  • 1
    \$\begingroup\$ Disconnect the PC from the network so that NTP cannot resynchronise it. You will probably see a simple monotonic drift between the two oscillators. \$\endgroup\$
    – user16324
    Commented Sep 10, 2014 at 7:59
  • 1
    \$\begingroup\$ You might be a "time nut". This page (and the parent website) make good reading material: leapsecond.com/time-nuts.htm \$\endgroup\$ Commented Sep 19, 2014 at 18:44

3 Answers 3


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.

  • \$\begingroup\$ 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. \$\endgroup\$ Commented Sep 19, 2014 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.
  • \$\begingroup\$ 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. \$\endgroup\$ Commented Sep 10, 2014 at 7:35
  • \$\begingroup\$ 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. \$\endgroup\$ Commented Sep 10, 2014 at 7:41
  • \$\begingroup\$ 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. \$\endgroup\$
    – Lior Bilia
    Commented Sep 10, 2014 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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.