Clock Drifts – Oscillator Tolerances in Embedded Systems

When sampling data from multiple physically disconnected devices, their internal clocks inevitably drift apart – much like two wristwatches that gradually lose synchronization. This drift creates timing mismatches that complicate the alignment of recorded measurements across devices (learn more in the first part our series on Clock Drifts and Synchronization).

In this post, we’ll put some numbers on that drift. We will look at the typical tolerances of microcontroller clock sources and calculate how far two independent devices can drift apart over a one-minute interval.

Hardware timer sources: RC- vs. crystal oscillators

For our wireless sensor network maphera^®, we use  the BL654 module from Ezurio, which packages Nordic Semiconductor’s nRF52840 SoC. On this Bluetooth module, hardware timers run off the high-frequency clock (HFCLK), which you can source from either:

• HFINT – based on an internal RC oscillator (resistor capacitor relaxation oscillator). Convenient because it’s on-chip, but relatively loose: its tolerance is typically ±1.5 % (see nRF52840 datasheet, section 5.4.4.1).
• HFXO – an external crystal oscillator. More accurate by design: the BL654’s 32 MHz crystal guarantees ±10 ppm.

These two options translate to different drift behaviors, even across supposedly identical boards.

Source: Nordic Semiconductor, nRF52840 Product Specification v1.11, Figure 22: Clock Control

Percent vs. ppm: What does tolerance actually mean?

The tolerance found in datasheets for oscillators is often specified in parts per million (ppm) or percentage. Both emphasize different orders of magnitude but can be used interchangeably: 1 ppm = 1/1e6 = 0.0001 %.

So when a datasheet lists:

• 1.5 % tolerance = 0.015 = 15,000 ppm, or
• 10 ppm tolerance

… it’s telling you how much the actual frequency $f_{act}$ of the oscillator can deviate from its nominal frequency $f_{nom}$ :

By looking at the tolerance, you get a measure of how “off” your clock can be—essential when you’re syncing multiple devices.

From tolerance to drifts

Each clock can deviate from its nominal frequency by up to its specified tolerance. In the worst case, two independent devices drift in opposite directions, so their relative error $\epsilon_r$ is twice the tolerance:

That translates directly into a maximum time delta after any elapsed time $t$:

Comparing HFINT and HFXO: Tolerance and worst-case drift

Using these few equations, we can estimate how much two independent devices – one running at the positive tolerance limit, the other at the negative – can drift apart. This will give us an overview of how HFINT and HFXO compare against each other with respect to their expected deviations. The table below summarizes nominal frequency, tolerance, and the worst-case drift per second and per minute.

The table shows that the external crystal oscillator (HFXO) on the BL654 module is orders of magnitude more stable than the on-chip RC oscillator (HFINT). This stability is crucial for BLE and other time-critical wireless protocols. Nevertheless, even a 10 ppm crystal will accumulate over a millisecond of drift each minute if left unsynchronized.

It’s important to remember that tolerance isn’t the only factor when choosing an oscillator. Temperature, aging and other environmental influences can widen the tolerance range. Additionall numbers like current consumption and startup time need to be look at as well to see the full picture.

Summary

Selecting the right HFCLK source is crucial for precise timing in embedded systems. The oscillator tolerance provides boundaries for the expected drift. An external crystal oscillator delivers far better stability than an on-chip RC source. However, even the more accurate crystal accumulates drift over time – so without proper synchronization, data inconsistencies will still occur.

Next, we will share measurement data from our wireless sensor network to compare these numbers against real-world performance. See you in the next post!