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

gschwaer — Thu, 24 Jul 2025 12:50:01 GMT

In the end we reimplemented the time sync based on MPSL from scratch instead of using nRF5-ble-timesync-demo. It took a few weeks, but we got it working very well in the end, but unfortunately I cannot share the code.

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

tesc — Tue, 19 Nov 2024 13:28:48 GMT

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