Time synchronization with BLE

Many technical applications require the time synchronization of various system components. At MEDtech, we have frequently encountered this topic. In this blog, I would first like to discuss time synchronization in general terms and then present a method for sending master timestamps using BLE advertising packets, which are then received and evaluated by slaves. This will specifically address the requirements placed on the (micro)controller and the RF unit used. This should then allow us to derive and explain the problems that arise.

Time synchronization: What is it?

The answer to this question will certainly be obvious to the (hopefully) many readers of my post. However, since experience shows that everyone has a slightly different ("individual") definition of time synchronization, I would like to write down my definition of the term, at least for the context of this article:

Time synchronization is the orientation of several system components to a common, system-wide clock signal.

The term "clock signal" is crucial here: a technically usable clock signal can be generated, for example, by the angular acceleration of the second hand of an analog wall clock. The prerequisite here is that the clock exhibits the typical "tick" behavior: the hand alternates between standstill and movement every second. A clock signal is therefore a periodic signal that changes over time. The clock duration corresponds to the period of the signal (in our case, 1 s).

Quartz instead of wall clocks!

In the world of microelectronics, however, a wall clock is obviously not used to generate a clock (that would be extremely cumbersome, simply due to space constraints). Here, we rely on small but very convenient little tools: so-called oscillators. These generate a periodically oscillating signal from an applied DC voltage. There are many different types of oscillators. A very common and precise type is the so-called crystal oscillator (more commonly referred to as quartz, sometimes abbreviated to XTAL). Their functionality is based on the piezoelectric properties of the crystal structure used. The accuracy here is typically in the range of 10-100 ppm (parts per million). RC oscillators are somewhat less precise: these use several RC elements fed back to an amplifier circuit to generate a 180° phase shift, thus creating an oscillating system. Other types of oscillators used in practice include resonant circuits consisting of capacitors and coils, ceramic resonators, and electromechanical oscillators (MEMS resonators). A major pitfall is that the accuracy of an oscillator is highly dependent on factors such as the parasitic capacitances created by the circuit board. Furthermore, the accuracy of most types is strongly dependent on temperature and age.

The varying accuracy creates a challenge for synchronization: if you want to synchronize the clock of a system component with a higher-level clock, it's not enough to simply start the two clocks at the same time. The clocks drift apart over time. Therefore, a continuous exchange (resynchronization) is necessary. This is intended to compensate for the so-called "clock drift."

BLE as a communication channel

Now the question arises: how can this exchange take place if the systems are physically separated? As the title of this article suggests, I would like to discuss the use of Bluetooth Low Energy at this point. At first glance, BLE doesn't seem particularly suitable for synchronization applications: for example, non-connection-oriented packets (so-called advertising packets) are sent virtually acyclically. A random time interval from the interval 0-10 ms is added to the packet cycle to prevent collisions with other packets. Latency also causes problems during synchronization: with BLE, payload data must traverse a huge protocol stack. At high data rates, competition with other data quickly arises, which may require buffering of the synchronization data. Nevertheless, in recent years, BLE has become one of the most widely used short-range wireless standards due to increased battery life requirements. This justifies the need to also be able to perform synchronization via BLE.

Synchronization with BLE

In the following, I would like to present a method that uses advertising channels to transmit synchronization packets from a master to one or more slaves. The accuracy achieved in my experiments was in the range of approximately 250µs, with the optimization focus on power savings. The publications served as the basis for my work. CheepSync and BlueSync.
I would first like to present the basic architecture in a block diagram:

Since Bluetooth stacks usually have to be considered encapsulated from the rest of the software, the magic happens at the application layer. Now the question arises: what do we even need to worry about here? I'd like to summarize the answer in a list.

1. Type and content of the synchronization package
2. Radio timing when receiving the synchronization packet
3. Processing the synchronization package
   • Identification of packages
   • Latency compensation
   • Plausibility check
   • RTC synchronization

In the following I would like to go into the individual points in more detail.

Type and content of the packages

First, something fundamental: the algorithm described here is based on the distribution of BLE advertising packets of the type ADV_IND_NONCONN (specified by the BLE substandard). These packets are receivable by all scanning-capable BLE nodes, but do not invite the user to establish a connection. Furthermore, these packets allow the transport of generic, application-specific information: namely, in AD mode, "Manufacturer Specific Data" (see PDF document AD typesThe disadvantage of advertising packets is that they are not protected: if a packet is lost or corrupted during transmission, there is no retransmission. However, faulty packets are detected and eliminated by the BLE stack using a checksum.
To run the algorithm correctly, we need at least three components. These are:

1. Unique identifier to distinguish from other packets (e.g. 16 bits)
2. RTC timestamp to which the slave(s) will synchronize (between 8 and 32 bits depending on the register size)
3. Packet number (for packet loss detection, a few bits with overflow handling)

The advertising type used allows a payload size of up to 31 bytes. Nevertheless, the packets should be as small as possible: Since advertising does not involve retransmission, packet loss is possible due to collisions with other packets and competition with other radio standards in the unlicensed ISM band. Small packet sizes reduce the transmission time of the packets and thus the likelihood of a collision.

Radio timing when receiving the synchronization packet

An important aspect of receiving packets is the timely activation of the receiver (called a scanner in BLE jargon). While it is conceivable and possible to perform continuous scanning, I personally would advise against this, as it unnecessarily increases power consumption. There are two overriding components to consider when it comes to timing:

• Cycle time of the synchronization packets (T_Sync)
• Random time specified by the BLE substandard for the cycle time of the BLE packets

It is also important to note that the scanning intervals are precisely regulated by the BLE specification: the receiver can be inactive for a period of T_major (Scan Duration) within a time window T_wdw (Scan Window) must be switched on. T_major be an integer multiple of 2.5 ms. The length of T_wdw must be an integer multiple of 10ms. If you're using a good BLE stack, this should be easily configurable via an SDK.
So far, so good! But how should the timing be designed? In practice, it has been found that the scanner for low loss needs to be switched on for at least T_major=100ms around the estimated time of reception. This means: if you want to receive packets at intervals of T_Sync=10s to each other, the receiver should be switched on during the interval between i * (10s +- 0.05s). Here, i represents the packet number since the start of synchronization. The following oscillogram illustrates this a bit better:

It's also important to note that the random time must be compensated for over the duration of the synchronization: the scan window, in which the scans are cyclically performed, must be loaded with the mean value of the random distribution (5 ms). The duration of the scan window is therefore: T_wdw = T_Sync + 5ms.

Processing the synchronization packets

ID

The first step of processing in the slave is identifying the synchronization packets. This must be done in the application layer, as the BLE stack typically passes the scanning results to the application layer as part of a callback. A filter system with increasingly finer filters can be used for identification:
Sieve 1: Filter by packet type (ADV_IND_NONCONN)
Sieve 2: Filter by AD mode (Manufacturer Specific Data)
Sieve 3: Filter by identifier (selected individually)
The number of eligible packets is thus reduced from top to bottom. This is especially important for quickly exiting the callback (especially in urban environments with many BLE nodes, more packets can then be received).

Latency compensation

In principle, latencies can be divided into deterministic ("synchronization-friendly") and non-deterministic ("less synchronization-friendly") latencies. Unfortunately, in our case, when transmitting packets with BLE, non-deterministic latencies also occur frequently. These arise, for example, from the CPU being occupied by other processes, which can delay the retrieval of received packets from the MAC layer. With the knowledge from [2] However, the non-deterministic delays on the master side can be almost completely eliminated: using an interrupt, which can be triggered using a low-latency Off-load peripheral interconnect signals After a packet is sent, the timestamp for the next packet is generated. The sent timestamps will then always be offset by one packet!

From the slave's perspective, however, interpreting the timestamp becomes a little more complicated: if the timestamp always has a packet offset, how do we determine the current timestamp when a packet is received? The answer doesn't come from a crystal ball, but rather, as is so often the case in the life of an engineer, from mathematics. With the help of a little RAM and simple algebra, we can calculate the offset of the master and slave clocks at the time of synchronization. All that is needed is to remember the slave timestamp when the last packet (i-1) is received. When the next packet (i) is received, the received master timestamp can then be assigned to the slave timestamp formed with packet (i-1). If the slave now adds up the counter ticks that were counted between the receipt of packet i-1 and packet i, we get a very accurate estimate of the master timestamp.

A disadvantage of this method, however, is the significant impact of packet loss: if a packet is lost, this also affects the preceding and subsequent packets in the slave. Two consecutive packets are always required to accurately estimate the master timestamp.

Plausibility check for outlier detection

I had greatly underestimated this component at the beginning of my work on this topic. I was used to working with deterministic systems from university. However, a synchronization system is not usually such a system. Unexpected delays (non-deterministic latencies) can occur at many points in the process, disrupting the transmission of synchronization packets and thus corrupting the timestamps. To "unmask" such corruptions, we used a median filter in this task. This checks the plausibility of the timestamps by comparing them with the median previously calculated from N correction values, where N is the length of the filter. During implementation, it is particularly important to ensure that the limit value, which determines the permissible tolerance to the median, is neither too large nor too small and allows for corrections in both directions. The functionality of the filter is best described using a graphic.

It is important during implementation that the correction value is always determined relative to the time since the last synchronization and stored in the filter. This is important because resynchronization may be skipped within an interval, for example, in the event of packet loss. Compensation with the current filter value is also discouraged, as this can affect system stability. Timestamps identified as erroneous should be discarded. Furthermore, the filter length should not be too small. A filter with a length of 7 delivers good results in our application.

RTC synchronization

At this point, I'd like to outline what the final step of the core process looks like. So far, we have:

• On the master timestamp created and sent
• Receive this with the slave
• Correction values formed from timestamp pairs
• The correction values are checked for plausibility

Now, the clock should be “adjusted.” Depending on the counter used and the application, this can take various forms. However, I would like to limit myself here to a case in which direct manipulation of the RTC register is possible (although this is not a given): let us assume that this can be done with a function void setTicks(uint32_t tickVal) is possible! A function uint32_t getTicks(void) should return the current RTC counter value. The stated goal at this point is to set the slave's RTC counter to the value of the master RTC. A code example will demonstrate the solution.

/*
 * from previous processing steps we got the correction value
 * saved in variable correctionValueTicks
 */

// get slave rtc time in ticks
uint32_t slaveTicks = getTicks();

// correct slave rtc time to master's rtc time
uint32_t masterTicks = slaveTicks + correctionValueTicks;

// set new rtc time
setTicks(masterTicks);

Resynchronization intervals

Before I present some of the results of our work, I would like to briefly address the last, important topic. The resynchronization interval strongly influences the accuracy and power consumption of the synchronization. If the resynchronization intervals are set too large, the accuracy will suffer due to clock drift. However, the slave's power consumption will decrease due to the fewer receive intervals. This is therefore a trade-off between accuracy and power consumption. So how do I determine the "right" value for the resynchronization? The answer to this question basically depends on the size of the RTC drift. With a good PCB design and the use of high-quality oscillators, the length of the resynchronization intervals can easily be set large without having to expect any major inconveniences. This, of course, also saves a lot of power! Conversely, the less accurate my clocks are "by nature," the more often they need to be adjusted. In our application, we use very inaccurate clocks (RC oscillators, not quartz ones). We have to send new packets every 10 seconds (see graphic) to maintain the desired accuracy.

And why do we send three sync packets? The answer is simple: if a packet is lost due to interference in the channel, there is still a "reserve" packet. However, the algorithm only needs one packet pair for synchronization over the 10-second interval. The superfluous packet can then be discarded.

Results

Finally, we would like to turn our attention to the results of this work: in the practical test, an average accuracy of approximately 25.2 µs was achieved over the test duration of 8 hours, with the resulting distribution range being approximately 460 µs. The samples are generated by an RTC interrupt on the master and slave, respectively, whose RTCs were synchronized using the algorithm described here. In the interrupt routine, a pin is toggled on both controllers. Using a third controller, the separation between the edges can be determined.

And what else is important?

It should be noted that the synchronization accuracy can never be more precise than the RTC resolution. If the RTC resolution is 30.5 µs (RTC frequency 32.768 kHz), the synchronization accuracy using this method will always be worse than this value.

Still questions?

Are you designing a product that requires synchronization or do you need help implementing your BLE features? Thanks to many successful projects in this area, we at MEDtech have a wealth of BLE expertise. So feel free to contact us!