38
\$\begingroup\$

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?

\$\endgroup\$
  • 2
    \$\begingroup\$ Could you tell us what you're trying to do and why the units have to be synchronized? May be, the specifics of your application can point a solution. As a general problem, this is not a very easy one, especially for small wireless devices. \$\endgroup\$ – Nick Alexeev Aug 1 '13 at 5:40
  • 2
    \$\begingroup\$ Its impossible to achieve synchronization relying on the Bluetooth. 15 ms jitter is just way too much to get 0.5 us synchronization. You need something with very low jitter and fixed latency that can be corrected for. It would be easier if you could get a single clock to both of them, and buffer the clock to balance the delays. \$\endgroup\$ – travisbartley Aug 1 '13 at 5:44
  • \$\begingroup\$ Sorry for delay. The project's goal is to remove wires from an existing design of hand-held digital measuring tools. The user's wanted a wireless design, as they were damaging the current wires. The units are measuring the propagation of waves in standing trees, which are fast enough to need 0.5us synchronization between both sensors. \$\endgroup\$ – Kevin Aug 5 '13 at 22:26
  • \$\begingroup\$ Cheap-o wireless: Infrared. One IR pulse could be enough to re-synchronize the clocks when they have drifted apart a little. \$\endgroup\$ – JimmyB Apr 21 '16 at 15:11
  • 1
    \$\begingroup\$ This paper proposes a Bluetooth 4.0 system with ~10uS synchronization, with experimental test. \$\endgroup\$ – user2943160 Jun 22 '16 at 15:38
24
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ I once worked on a project where we had to get this kind of accuracy on servers running in data centers across the globe. There the easiest way was to use GPS. It turned out not all machines/data centers could get access to GPS so our solution in the end was quite a challenge. Doing this with microcontrollers is going to be even tougher. \$\endgroup\$ – NomadAlien Aug 1 '13 at 9:02
  • 4
    \$\begingroup\$ +1 for "warrants re-evaluation of the whole system design". \$\endgroup\$ – user3624 Aug 2 '13 at 5:33
  • 2
    \$\begingroup\$ Depending on your budget, you can buy GPS units that output a programmable frequency (0-10 Mhz) that is phase-aligned to the GPS signal for ~$150 ea. Look at the uBlox LEA-6T. They claim 30 nS RMS error timepulse output, 99% < 60 nS. \$\endgroup\$ – Connor Wolf Oct 7 '13 at 5:11
10
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Could you be a little more explicit about how this would work? I'm having trouble understanding from the current explanation. \$\endgroup\$ – NickHalden Oct 7 '13 at 5:00
  • \$\begingroup\$ @NickHalden: OK, done. \$\endgroup\$ – Dave Tweed Oct 7 '13 at 11:39
  • \$\begingroup\$ Hmmm ok, doesn't this rely on the frequency of the cpu clock being constant between the two 1 second pulses though? For example, take a particularly awful crystal oscillator circuit where 99% of the pulses happen between 0.00 and 0.05 seconds, and then the final 1% happen between 0.05 and 1.00s. Wouldn't that pathologically constructed example screw this up or am I still missing something? \$\endgroup\$ – NickHalden Oct 8 '13 at 4:11
  • \$\begingroup\$ Yes, that's what "short-term stability" means. \$\endgroup\$ – Dave Tweed Oct 8 '13 at 11:25
  • \$\begingroup\$ Oh, yikes was that in there when I commented? Haha that's embarrassing. Anyway, thanks for the explanation +1 from me. \$\endgroup\$ – NickHalden Oct 8 '13 at 19:47
8
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ The precision of 1.5µs in the single hop scenario and the average precision of 0.5µs per hop in the multi-hop case were shown by providing experimental results. Nice. \$\endgroup\$ – Li-aung Yip Oct 7 '13 at 5:28
  • 1
    \$\begingroup\$ This also may be of interest: Timing-sync Protocol for Sensor Networks \$\endgroup\$ – Nick Alexeev Apr 25 '15 at 23:19
3
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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