Short Connection Default Interval not being set

[Sebastian Luntraru]

Hi everyone,

I’m working with Zephyr 3.2.3 in a Windows environment and trying to run the shorter connection intervals sample:
https://github.com/nrfconnect/sdk-nrf/tree/v3.2.3/samples/bluetooth/shorter_conn_intervals

What I’m trying to achieve:

I would like to use the default connection parameters defined in the sample without explicitly requesting a connection parameter update.

In particular, I’m referring to the default configuration in:
https://github.com/nrfconnect/sdk-nrf/blob/v3.2.3/samples/bluetooth/shorter_conn_intervals/src/main.c#L432

I tried to remove the connection parameter update logic from:
github.com/.../main.c

Expected behavior:

• The connection should use the default parameters (including the minimum interval).

Actual behavior:

• Even when relying on default settings, the connection does not use the expected interval unless I explicitly trigger a connection parameter update.

Question:
Is this expected behavior?
Is there a way to enforce the default minimum connection interval without calling a connection parameter update?

Thanks in advance!

[Edvin]

Hello,

Sorry for the late reply.

You need to enter the connection using the default legacy connection interval of 7.5ms - 4 seconds. So unfortunately, no, this is not possible.

Note that there is a proprietary mode called llpm (low latency packet mode). Using that, we have done some shortcuts, and it will enter the connection using a 1ms connection interval. This is partially proprietary, however, so this will not work with non-Nordic devices (or Nordic devices not compatilbe with LLPM).

Best regards,

Edvin

[Sebastian Luntraru]

Hello Edvin,

thank you for your reply.

I understand that LLPM allows shorter intervals, but I’m not interested in using proprietary solutions. I would prefer to stay within the standard BLE specification.

What I would like to better understand is the following point:

why does it make sense to call a “bt_conn_le_conn_rate_set_defaults” after a "bt_conn_le_conn_rate_request"?

sdk-zephyr/include/zephyr/bluetooth/conn.h at ncs-v3.2.3 · nrfconnect/sdk-zephyr · GitHub

 

 

Thanks in advance for your clarification.

Best regards,

[Edvin]

Hello,

The bt_conn_le_conn_rate_set_defaults() sets the preferred connection rate for all future connection, while the bt_conn_le_conn_rate_request() requests connection parameter updates for the current connection.

Best regards,

Edvin

[Sebastian Luntraru]

Hello Edvin,

thank you for the clarification.

I understand that bt_conn_le_conn_rate_set_defaults() applies to future connections, while bt_conn_le_conn_rate_request() is used to update the parameters of the current one.

However, I still have a doubt:

if I remove the call to bt_conn_le_conn_rate_request() from the example, how can I ensure that the default values set with bt_conn_le_conn_rate_set_defaults() are actually respected for a new connection?

In other words, what guarantees that the connection will start (or converge) to those default parameters without explicitly requesting an update?

In practice, I know that both my central and peripheral are based on the same platform (nRF54L15) and use the same project configuration, so I can assume that a short connection interval (e.g., 750 µs SCI) is supported on both sides.

For this reason, I would like to avoid the step where the devices negotiate or exchange supported connection intervals through a connection parameter update procedure. Instead, I would like the central to directly use the values set in the default parameters from the beginning of the connection.

How can I achieve this behavior from the central side, ensuring that the connection is established directly with those parameters, without requiring a connection update request?

Thanks again for your support.

Best regards,

Sebastian Luntraru

[Edvin]

It is not possible to avoid the update request. It is not allowed by the Bluetooth Specification, and hence not possible using the SoftDevice controller.

Best regards,

Edvin

[longo92]

Hi Edvin,

i am also interested in the matter (in use case enlighten by Sebastian):

- if do not call bt_conn_le_conn_rate_set_defaults() but only bt_conn_le_conn_rate_request(), what happens?

- In wich cases the central uses the parameters set in bt_conn_le_conn_rate_set_defaults()?

Thanks,

Alessandro