Questions about Connection Event Length and Notification on Peripheral Devices

[adamsperry]

According to this post it seems clear that a peripheral device cannot set the connection event length in a given connection (and only has mild influence on the connection interval through the connection parameter update procedure request). However, according to this other post it seems clear that there are settings related to connection event length that are important to still be setting on a peripheral device. I have a few questions.

Am I correct that there is no way to influence the connection event length from a peripheral device? If so, what settings do I need to make sure I'm adjusting on a peripheral device using the nRF5 SDK to allow for the central to use the maximum possible connection event length? The only connection event length settings I am aware of are NRF_SDH_BLE_GAP_EVENT_LENGTH and turning on connection event length extension via sd_ble_opt_set(). Are there more settings and should I be setting both of these even on a peripheral device? What is the exact effect of each of these settings on a peripheral device (as opposed to the effect they have on a central device)?

If the central device only has a single connection to my peripheral, can I reasonably expect that the central will use 100% of the connection interval (assuming my peripheral has data to send)? Specifically, I am using an Ubuntu PC (with BlueZ and Qt Bluetooth API) as the central which has only one connection to my peripheral and has an nRF52840 Dongle programmed with the latest Zephyr HCI-USB BLE controller (the PC has no other BLE adapter).

Lastly, this post came close to an answer to a question I have about how connection event length and connection intervals interact with notifications, but it is still unclear to me. If my peripheral is currently engaged in a connection event (let's say that there are several packets queued to send to the master for this event) and I queue a notification using sd_ble_gatts_hvx() during the ongoing connection event but well before the connection event is over, will this newly queued notification be sent in the currently ongoing connection event (assuming there is still time available in the connection event length)? Or will it be queued for the next connection event?

Thank you in advance for any help and clarity you are able to offer.

[Sigurd]

Hi,

Am I correct that there is no way to influence the connection event length from a peripheral device?

You cannot configure the "connect event length" the central uses from a peripheral device. But you can request a different connection interval, and that might have some indirect effects on the "connect event length" the central uses.

Are there more settings and should I be setting both of these even on a peripheral device

If you only have a 1-to-1 connection, i.e., your peripheral is a peripheral-only, and only connected to 1 central, then yes, set these configs in order to maximum the throughput potential.

If the central device only has a single connection to my peripheral, can I reasonably expect that the central will use 100% of the connection interval (assuming my peripheral has data to send)?

 If the central is not doing scanning at the same time, then yes, I would expect that it would allocate most of the time between connection intervals to send/receive data to/from your peripheral. But there is a lot of variation between centrals, e.g. some phones might limit the amount of packets sent each connection event.

If my peripheral is currently engaged in a connection event (let's say that there are several packets queued to send to the master for this event) and I queue a notification using sd_ble_gatts_hvx() during the ongoing connection event but well before the connection event is over, will this newly queued notification be sent in the currently ongoing connection event (assuming there is still time available in the connection event length)?

 You should be able to send these packets in the currently ongoing connection event.

If you want to do some testing here, I recommend using the nRF Sniffer to see what happens on-air: https://www.nordicsemi.com/Software-and-tools/Development-Tools/nRF-Sniffer-for-Bluetooth-LE