NCS Connection Event Trigger

Question

Hi,

I'm trying to implement timer synchronization on one central and multiple peripherals, I'm using nRF52840 and NCS v2.8.0. I've seen the example conn_time_sync which uses anchor point events for synchronization, but I need to sync 16MHz timers, and also measure the drift between the timers on each device caused by crystal inaccuracy, so sdc_hci_cmd_vs_conn_anchor_point_update_event_report_enable api doesn't help me because it only gives the timestamp of the system timer running on RTC.

Instead I've tried to use sdc_hci_cmd_vs_set_conn_event_trigger to achieve a similar result by capturing timer value on connection events using PPI, but after some testing I realized it's not triggering the events at the same time on central and peripheral. I used the connection event trigger to toggle GPIO and measured the timings with logic analyzer, seems like the peripheral event is triggered ~40us before the central event. This time is not consistent either, it varies between 41-45us:

Description of the api says: "When enabled, this feature will trigger a (D)PPI task at the start of radio events.", but it's unclear to me which events exactly.

1. Are these connection events triggered by a radio event (EVENTS_READY, EVENTS_ADDRESS, etc.), and which one exactly?

2. Why would the peripheral event be triggered before the central event?

3. How is the achor point timestamp capture implemented in sdc_hci_cmd_vs_conn_anchor_point_update_event_report_enable, is it possible to manually implement something similar to trigger event on both central and peripheral at the same time, and capture the 16MHz timer on each device?

tesc · Answer

Hi, 
 Are these connection events triggered by a radio event (EVENTS_READY, EVENTS_ADDRESS, etc.), and which one exactly? 
 For the central, the connection event is triggered by a timer, which prepares the radio for TX and eventually sends the first packet of the connection event. The radio event in this case, is the packet sending. 
 For the peripheral, it starts scanning (also controlled by a timer), in order to receive the first packet of the connection event. The radio event in this case, is the scanning. 
 Why would the peripheral event be triggered before the central event? 
 The clocks of the peripheral and the central are expected to drift relatively to each other. The maximum amount of drift depend on the accuracy (PPM rating) of both clocks, and the time since the last successful connection event. Because of this, the peripheral (which starts the connection event in RX) must start prior to the central (which starts the connection event in TX), with some margin. Therefore, the radio event on the peripheral (RX side) happens prior to the radio event on the central (TX side). 
 Please note that while the peripheral starts RX before the central starts TX, since the relative drift is unknown it is impossible to tell in advance just how large this offset is. It all depends on the actual drift of the clocks of the devices involved, at the given point in time. 
 How is the achor point timestamp capture implemented in sdc_hci_cmd_vs_conn_anchor_point_update_event_report_enable , is it possible to manually implement something similar to trigger event on both central and peripheral at the same time, and capture the 16MHz timer on each device? 
 The BLE Controller is delivered pre-compiled. The lowest level of the stack where you would be able to manually hook into the code is at the host level, but please note that any changes (however small) to the BLE host risks voiding the qualification (QDID / DN) of the stack. 
 I think the sample that you already mentioned ( Bluetooth: Connection time synchronization ) is the closest to what you ask for, of available samples. 
 You could however have a look at nRF5-ble-timesync-demo , which also do have an implementation included for nRF Connect SDK, despite the name indicating nRF5 SDK. Maybe that one will work for your use case. 
 Regards, Terje

NCS Connection Event Trigger

Top Replies