Accurate time synchronization across devices

[24thFrame]

Hi, I'm currently evaluating using a nRF52810 based module to synchronize time between a number (2-20) of the same devices. I currently have a working prototype using an ESP32 but the power consumption is too high for my needs, so I am considering this module instead. The device sends a square wave signal out via a GPIO pin at a certain rate (the signal out contains the time for an external device to read).

I have a few questions:

1. If I use an external TXOX 32.768 kHz with +-3PPM accuracy, will I be able to accurately keep time on the device within the crystal's stated accuracy, or is there a limit to the accuracy of an external clock source?

2. There is 1 host device with the "master clock" and 1+ clients. I am currently synchronizing time by sending a request from the client device to the host device (ping) and getting a response with the time (pong) and measuring the latency both ways, averaging it, and then adding that to the time sent by the host. I am doing this currently via the ESP32's 2.4GHz wireless protocol (and not Bluetooth). Is this approach still viable within ~2ms accuracy through BLE on the nRF52810?

3. The current method works for up to 20 devices on the same channel, but I'm aware that BLE has limitations on the number of concurrent connections. To get around this limitation, I'm thinking that I could stagger the synchronizations so that the host only allows a certain number of "sync requests" at one time. If a client attempts to connect to a host that already has the maximum number of connections, it would have to retry at a later time. Does this approach make sense, or is there a better way to handle a large number of devices communicating with each other like this?

[Edvin]

Hello,

1.

The accuracy will be given by the external XTAL if you use an external XTAL. 

2.

This wouldn't work with BLE because the devices only communicate on certain timeslots, every connection interval. If you want this accurate timing you would need something extra. One alternative is to use a proprietary protocol (SDK\examples\proprietary_rf) in a timeslot next to BLE, or to do some fancy logic stuff with BLE. 

The challenge with BLE is not only that you can only talk on the connection interval timeout, but that if a packet isn't ACKed, then the transmitter has to send the identical packet the next connection interval. With the softdevice there is no way of seeing if the received has been retransmitted or not, so you can't know whether it was actually sent this connection interval, or if it is from a previous.

3. The softdevice supports up to 20 connections, but depending on the memory usage and radio usage of the application it may be less. It is possible to cycle through connections. In fact, if you already have the maximum number of connections, you will not be able to advertise, so you can't connect to the peripheral at that point in time, because you can't see the advertisements that you want to connect to. 

That being said, it is a reasonable approach. But in that case, the peripheral should maybe actively disconnect from some devices once it reaches 15-16 devices, if you expect there to always be 20 centrals in the area. Just to reduce the time the new centrals have to wait.

Another approach is to look into using one of the Mesh technologies. Bluetooth Mesh, ZigBee or OpenThread, for example. But you would need your "centrals" to also support this protocol of course.

Best regards,

Edvin

[24thFrame]

Hi Edvin,

Thanks so much for the quick and thorough response!

For #2, that makes sense. I've found this guide based on your suggestion that looks like it covers what you mentioned.

For #3, that's good to know!

Thanks again!