How to synchronize two microcontrollers to micro-second accuracy?

Question

I need to synchronize two micro-controllers so that they can measure the speed of propagating waves. The time delay measurements need have microsecond accuracy (error less that 1/2 of a microsecond).

I have two micro-controllers (ATmega328) which use a 12MHz crystal.

They are both equipped with Bluetooth transceivers. The Bluetooth transceivers send and receive packets with a jitter of ~15 millisecond.

I hope to synchronize the micro-controllers using the Bluetooth transceivers, or some other creative method.

I have tried synchronizing them by touching them together, but I need them to stay synchronized for about 10 minutes, and their clocks drifted too fast. Maybe if it was possible to accurately predict the clock drift, this method would work.

How should I go about achieving this synchronization?

Answer 1

I don't mean to rain on your wireless parade. You've ran into a tough but unexpected requirement. Something like that warrants re-evaluation of the whole system design.

1st thing that comes to mind is to clock both units off one oscillator. You have Bluetooth communication, which hints that the range is on the order of 10m. You could connect your units with RG174 coax cable or an optical fiber, which would carry the clock.

2nd, there are precision oscillators. In order of increasing precision and cost.

• TCXO (temperature compensated crystal oscillator). 1 to 3 ppm drift, typically.
• OCXO (oven controlled crystal oscillator). Drift on the order of 0.02ppm. Some OCXO have drift down to 0.0001 ppm.
• Atomic clock (Rubidium standard, for example). I'm mentioning atomic clock mostly to give a frame of reference. More on that here.

3rd, precision oscillator trained with GPS. Every GPS satellite has several atomic clocks on board. Usually, there are plenty of GPS satellites in view. GPS is used for precision timing a lot (less known usage compared to sat nav). Most GPS receivers have a 1PPS output (one pulse per second), which provides timing accurate to 50ns.
To have a 0.5μs drift over 600s (10min), your clock (the 12MHz clock in your present design) should have drift less than 0.0008ppm. But if you can correct the timing error every so often from an low drift external source, the requirement for the drift in the clock can be more relaxed. If you can correct every second, then your clock could have a 0.5ppm drift.

Answer 2

GPS modules with 1pps outputs are readily available and inexpensive.

It isn't really necessary to discipline the CPU's oscillator to the GPS (e.g., with a PLL). As long as you can "timestamp" external events relative to the CPU clock, it's relatively straightforward to interpolate the time of your wave transmit and receive events between any two PPS events.

You can often use the combination of a hardware timer on the microcontroller, along with a software counter for its overflow events, to create a CPU cycle counter of arbitrary width. It can be tricky to deal correctly with rollover events, both of the hardware counter and the software counter, but in the end, you can have, say, a 32-bit counter that counts at the rate of the CPU clock (giving high resolution) and rolls over with a period longer than the intervals you're trying to measure (e.g., 429 seconds @ 10 MHz).

You can use this counter to timestamp different external events. If one of those events is 1-pps pulses from a GPS receiver, then the basic long-term accuracy of the CPU clock becomes a don't-care. The only thing that matters is its short-term stability. You can save GPS timestamps in a FIFO buffer, and compare the timestamps of other events to the values in that buffer. Since you know the GPS pulses are exactly one second apart, you can find the exact time of any other event by interpolating.

Suppose \$GPS_n\$ and \$GPS_{n+1}\$ are the CPU-clock timestamps for two successive GPS pulses. You also know the actual (atomic clock) times associated with each of those pulses (from the GPS messages), \$Time_n\$ and \$Time_{n+1}\$. If \$Ext\$ is the CPU-clock timestamp for some external event you want to measure that falls between \$GPS_n\$ and \$GPS_{n+1}\$, its exact time is:

$$Time_n + \frac{Ext - GPS_n}{GPS_{n+1} - GPS_n}$$

Finally, if you have this setup running on two separate systems, each with its own GPS receiver, you can compare the times calculated for various events on the two systems with high precision (typically on the order of ±100 ns), even if the CPU clocks of the two systems are not synchronized.

Answer 3

I have implemented a wireless clock synchronization for microcontrollers before, but only with millisecond accuracy, which was good enough for the application. From my reading, this paper explains microsecond synchronization quite well: http://www.math.u-szeged.hu/tagok/mmaroti/okt/2010t/ftsp.pdf

Essentially, if you have knowledge of the transmission event and the arrival event of a radio packet on the transmitter and receiver respectively, you have a common observable event (assuming you ignore the propagation time of the radio wave) between the 2 systems that can be used as a reference. The other neat feature mentioned in the paper is clock-skew estimation using linear regression.

Answer 4

Check out the Bluetooth Clock Synchronization Protocol (CSP) which is an optional part of the Health Device Profile (HDP) The sections in that document that are relevant to CSP are 2.1 & 8.

I haven't yet had a chance to try it myself but, as far as I can tell, BlueZ (the official Linux Bluetooth protocol stack) just added support for the HDP, including support for CSP. So even though it doesn't sound like you'll be running on a platform that supports the BlueZ stack, but maybe the code will at least provide a good reference implementation.

Answer 5

Wireless is pretty bad for synchronizing two MCUs with a 1 µs accuracy. It is also prone to errors and interference.You might say that wireless communication is just a fallacy for realtime computing. For synchronizing two MCUs, you would need a high speed serial bus such as timers running on both MCUs and each MCU doing a handshake with the other every 1 µs. A high serial bus is all you need. SPI is suitable. You didn't specify which ATMEGA328 MCU you have. I'm assuming its something as this:

https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7810-Automotive-Microcontrollers-ATmega328P_Datasheet.pdf

Consider this: if you have an interrupt on each MCU every 1 Micro second for the synchronization, CPU load on both MCUs would be high. What are the requirements of the other application on each MCU? For radio detecting and processing, usually ASICs are used are they are much faster than MCUs.

Answer 6

Looking back on this problem, I'm pretty sure if the probability distributions associated with the packet jitter and drift can be roughly described, then Kalman filters or hidden markov models can be used to solve this problem.