Poor performance of nRF5-ble-timesync-demo when using GATT

[gschwaer]

Project (NCS v2.7.0):

We are working on an application that requires time synchronized sampling of sensor data from 4 nRF52840 devices. The sensor data is then streamed to a single smartphone. To synchronize the device clocks, we are using the nRF5-ble-timesync-demo (more or less as is), but without registering a trigger. Instead we periodically query the global time (ts_timestamp_get_ticks_u64()), which we use to setup a sampling schedule. In parallel we have a GATT service (BT_GATT_SERVICE_DEFINE(...)) that sends the data to the smartphone via notifications.

Issue:

As long as the smartphone is not connected, the time sync works fine. But as soon as the smartphone connects, the receiver devices don't receive much (if any) time synchronization packets and the clock synchronization drifts apart.

Is there any way we can improve the time synchronization performance?

[tesc]

Hi,

The timing of a BLE connection is synced with the central clock. Since your application is the peripheral in the smartphone-device connection, it means the connection parameters do not align perfectly to the local clock. Further, the connection parameters themselves are also decided by the central. For smartphones there typically are a few presets to choose from for connection parameters.

Depending on the frequency of your time synchronization, the synchronization events may happen in synchronization with the connection interval with the smartphone, drifting in and out of overlapping with the connection events of the BLE connection. Or, also depending on the timing, synchronization events periodically overlap with BLE connection events for other timing related reasons.

We have extensive documentation for timing-activities and priorities, or in other words what happens in the case of collision between different radio uses. In general BLE connections get highest priority. BLE scanners and advertisers are a bit further down on the list, while MPSL Timeslot events with normal priority comes last. MPSL Timeslot events with high priority are prioritized slightly higher, but still below many of the time critical BLE events. For the complete picture, see the full Scheduling chapter of our SoftDevice Controller documentation.

The way forward depends a bit on the implementation. In what way do you see the synchronization between your device and the sensors drift apart?

Regards,
Terje