Highly accurate synchronized clock distribution for BLE mesh network

[rhardik]

Is your feature request related to a problem? Please describe.

Problem: The direction-finding technique is known as Time of Arrival (ToA), which is the travel time of a radio signal from a single transmitter to a remote single receiver. But problem is that each device has to carry a highly accurate synchronized clock

Describe the solution you'd like

Highly accurate synchronized clock distribution implementation for BLE 5.1 direction finding feature.

[aescolar]

CC @jhedberg @trond-snekvik

[trond-snekvik]

Thanks for submitting.
Clock synchronization has been a hot topic for Bluetooth Mesh, but mostly for the light synchronization use case. #7331 (possible duplicate?) requests something along the same lines, but with more relaxed requirements.

We are planning on adding some clock synchronization mechanism in the future, but the targeted use case would have much more relaxed requirements than this.

Doing the level of time synchronization required for a distributed ToA system (I believe this is what you're requesting? ie triangulating positions based on differences in time between rx on different mesh nodes?) is not feasible with the Bluetooth Mesh, I believe. Even getting stable time synchronization below 10 milliseconds is very hard in Bluetooth Mesh for two reasons:

1. The controller does not offer fine time control, and mesh packets even have an intentional 10ms randomized offset in the specification. It's possible to work around this by recording the TX timestamp, and broadcasting it in a separate followup packet, but Zephyr doesn't really provide this time granularity in its Bluetooth Controller.
2. All devices experience clock drift in their crystal oscillators. The Bluetooth specification permits up to 500 parts per million drift (500us per second). Considering that two clocks may drift 500 us in separate directions (relative to some imaginary real time), two devices might end up drifting apart by up to 1ms per second. This drift is a mixture of the physical properties of each oscillator as well as environmental factors, such as temperature, load and supply voltage, which fluctuates over time. To combat this, we need to perform frequent synchronization to reset the drift. We can employ a regulator or some other clever algorithms to adjust for measured drift, but this only helps us part of the way.

I tried some back of the envelope calculations to see what it would take to solve this with naive Mesh based time synchronization:

According to Wikipedia, light moves at 299700 km/s through air. To be able to measure position with ToA with an accuracy of 1 meter, we need clock synchronization with an accuracy of 1/(299700 * 1000) seconds = 3.34 ns. If we made all the mesh devices ourselves, and chose really good crystals that drift at just 1 us/second (500 times better than the minimum requirement), we'll still need to synchronize our clocks every 1.7 ms (3.34ns / (1000 + 1000) ns/s = 0.0017 s) to maintain a 1 meter accuracy between two devices.

So say that we're able to run with these nice crystals, and the radio timestamp accuracy problem is taken care of, we're still spending most of the time synchronizing nodes, as a single mesh packet takes about 300us of radio time to transmit (on a single channel, the mesh really uses 3). We can improve this by quite a lot with better algorithms, but I think there are a little too many factors to consider for this to be a feasible approach.

Although it has its flaws, I'd recommend looking into averaged RSSI based positioning instead. With 5-10 mesh devices deployed in some grid, it should be possible to estimate positions down to about a meter or less. It'll never be as accurate as ToA, but at least it's implementable in the application with the current APIs.

Another approach could be to do direction finding in each mesh node, and triangulating based on angle of arrival. I'd consider this a better option than distributed ToA as well.

[jfischer-no]

Not sure why the requester mixed it up with Bluetooth, typically transceiver like DW1000 has timestamp support for RX/TX events, and for some scenarios like TDoA the anchor nodes need to be time synchronized.

[rhardik]

Thanks for the detailed clarification.

Clock synchronization has been a hot topic for Bluetooth Mesh, but mostly for the light synchronization use case.

Yes we are looking for this as well.
So will refer to #7331