Time synchronization between smartfone and BLE Mesh <= 10ms

[hubert_melchert]

I'm evaluating a possibility to use BLE Mesh for my project. Multiple devices in BLE Mesh network have to synchronise with the Android/iOS application's timestamp with +-10ms precision.

I'm thinking about Time Server model but I don't really understand how precise can it be. Other aproach I believe could work is some sort of NTP where nodes will request time from application several times, calculate time of transmission in both ways and use as offset for timestamp. I've seen similar topics mentioned several times at this forum and internet generally but haven't found a conclusion. I don't need very precise synchronisation (<1ms) so maybe I could avoid getting into some low level tricks. I did one project so far with BLE but none with BLE Mesh. Is it possible to achieve +- 10ms accuracy?

[Hung Bui]

Hi Hubert, 

The Time Server model wouldn't be able to meet your requirement. If you take a look at the documentation here, you can find that by each hop the uncertainty has an increase of CONFIG_BT_MESH_TIME_MESH_HOP_UNCERTAINTY which by default 30ms. 
So if you broadcast a packet that contain the time to sync and it take 3 hops to get to the destination, the time uncertainty (inaccuracy/tolerance) is 90ms.

This comes from the fact that mesh use ADV bearer to communicate and there is a 10ms random delay on each of the advertising packet. So you can't really get to +-10ms accuracy with normal mesh communication. 

In addition on the phone it can also be a challenge to know when exactly your BLE packet being sent out from the phone down to +-10ms. 

You may want to think about other solution for example using proprietary protocol (ESB for example) to do time sync. This protocol can run at the same time as Bluetooth mesh. But quite often such protocol doesn't support mesh. 

Synchronization in a mesh network is not a straight forward task. Could you let me know more about the application ? Is it a large network that requires multiple hops ? 

[hubert_melchert]

Hi,

We are designing a new version of our devices that need to be controlled with a smartphone. Our devices are sending a short data packet after user event/interaction. We need to measure time with +-10ms precision between those events happening on multiple devices. Mesh was our idea of extending the range for our devices but now we don't think it would be convenient for the user to setup extra devices in between other devices just to create a mesh. We just need another radio dedicated for longer ranges (100m distances, in building especially).

Given our time schedule we would like to use regular BLE without Mesh to connect 3-5 devices to iOS/Android smartphone. We can accept range limit for this version of the product and use dedicated radio with custom hub for future versions.

But the requirement for synchronization stays the same, I just hope it will be much easier to do without Mesh. Am I right? What is the simplest aproach for this? We will use NRF52 modules

[Hung Bui]

Hi Hubert, 

I assume you want all of your device to be synced with the smart phone, correct ? Are they all connect to the phone all the time ? or most of the time it's not connected and the phone only connect to them when it needs ? 

Accurate timesync is not a feature that BLE support. The main problem is on how you can deal with clock drifting over time and how BLE as a reliable protocol (in general) can handle time sync. When there is a packet drop BLE will retransmit the package and it's transparent to the application. Meaning the application doesn't know when the package is initially sent by the peer device. 

The trick here is to use the Connected event as the anchor for time sync. The reason we should use this connected event is that it doesn't have retransmission. So two peers of will have this connected event relatively at a relatively same time (with low accuracy depends on how deterministic the latency is). 

So let's say the phone has an event at time T. Then it connect to device number 1 and get the connected event at T+30ms for example. On the device, it would start the timer at the time it get the Connected event/callback. Then the phone can send a BLE packet (this packet doesn't need to sync) to the device number 1 that it has 30ms offset. Device 1 will start adding 30ms offset to it Timer. 
Then phone connects to device number 2  at T+130ms for example, and then send the 130ms offset to device number 2. 
Now they should be synced, and if the phone want both devices to turn on an LED at the same time at T+1000ms for example. It can send a normal BLE packet to device 1 and device 2 telling them to turn on at T+1000. The device 1 and device 2 would use its timer and its offset to be able to calculate when is T+1000. 

The clock on the 2 devices will drift because of tolerance, so the phone will have to occasionally disconnect and connect to the device to sync again. You would need to do calculation to see how long it would take for the drift to be >10ms. For example a 20ppm Xtal will have the drift of 10ms in 500s. 

You can do experimental to know what would be the offset on both the phone and the device because the connect event is not 100% simultaneously and it's not 100% deterministic.

You can take a look at this similar ticket:  BLE Time Synchronization between devices 

[hubert_melchert]

I assume you want all of your device to be synced with the smart phone, correct ?

Yes, correct.

Are they all connect to the phone all the time ?

Yes, that is my assumption for now

Today I investigated Thread just a little and it seems like a better solution for time synchronized network but extra router to connect with phone is a huge downside

[Hung Bui]

Hi Hubert, 

Please be aware that either Thread or BLE Mesh both requires you to have relay nodes which are the nodes that do scanning all the time. Most likely you will need them to connect to main power instead of battery. 

hubert_melchert said:

but extra router to connect with phone is a huge downside

You can actually think of doing Thread and BLE at the same time so that the phone can talk to a nRF5 as a gateway to Thread.