NCS Connection Event Trigger

RE: NCS Connection Event Trigger

tesc — Thu, 23 Jan 2025 12:55:59 GMT

Hi again,

I was just made aware of the Bluetooth: Connection time synchronization sample, which provides microsecond-accurate synchronization. It has been available since nRF Connect SDK v2.8.0. You could look into that one.

Regards,
Terje

RE: NCS Connection Event Trigger

tesc — Wed, 22 Jan 2025 14:36:32 GMT

Hi,

From what I can tell, it was deprecated and moved due to similar functionality existing elsewhere in the SDK. You can have a look at the Bluetooth: Event Trigger sample for reference on how event triggers work in nRF Connect SDK 2.9.0 and later.

Regards,
Terje

RE: NCS Connection Event Trigger

Sefer — Thu, 09 Jan 2025 03:06:59 GMT

Hi Terje, any idea why the sdc_hci_cmd_vs_set_conn_event_trigger was removed in SDK v2.9.0? I finally got the clock synchronization working by utilizing these connection events to trigger my own PPI groups, but it's not available in the latest SDK 2.9.0, which we also need for the new "Scanning while connecting" feature.

RE: NCS Connection Event Trigger

Sefer — Thu, 19 Dec 2024 16:44:01 GMT

Thanks Terje for the detailed explanation, I suspected that was the case with events in sdc_hci_cmd_vs_set_conn_event_trigger, so it's not suitable for synchronizing device's clocks.

-Sefer

RE: NCS Connection Event Trigger

tesc — Thu, 19 Dec 2024 16:04:34 GMT

Hi,

[quote user=""]Are these connection events triggered by a radio event (EVENTS_READY, EVENTS_ADDRESS, etc.), and which one exactly? [/quote]

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.

[quote user=""]Why would the peripheral event be triggered before the central event?[/quote]

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.

[quote user=""]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?[/quote]

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