Issue of NUS example to set PHY, data length, and connection parameters

[seongmincho]

Hello!

I am programming BLE with the nRF52840-DK. [Toolchain Manager: v1.3.0, IDE: Visual Studio Code (VSCode), SDK: ncs v2.6.0, window11 pro]

I am using two nRF52840-DK devices to communicate via Bluetooth(NUS).

I am adding modifications to the NUS example to adjust PHY, data length, and connection parameters (connection interval, timeout, delay).

Since my search didn't resolve my questions, I decided to create a ticket. 

<my questions>

1. Can you explain the conditions and situations under which the Discovery completed callback in the struct bt_gatt_dm_cb (in 'gatt_dm.h') is triggered?

2. In my central debugging, the le_param_updated callback was triggered even though I didn't use 'bt_conn_le_param_update'. Additionally, I observed that the connection parameters were set to 'interval: 40, latency: 0, timeout: 42' despite setting them to 'BT_LE_CONN_PARAM(80, 80, 0, 400)'. I suspect this is due to 'connection interval negotiation'. Can you provide the cause and a solution for this issue?

[00:00:13.889,343] <inf> cho: CALLBACK - LE PHY updated: TX PHY LE 2M, RX PHY LE 2M
[00:00:14.289,794] <inf> cho: CALLBACK - Service discovery completed
[00:00:14.296,752] <inf> cho: discovery_complete - MTU exchange pending
[00:00:14.689,788] <inf> cho: CALLBACK - MTU exchange done
[00:00:17.889,770] <inf> cho: CALLBACK - Connection parameters updated. >> interval: 40, latency: 0, timeout: 42

 

[Susheel Nuguru]

Cho,

1. Can you explain the conditions and situations under which the Discovery completed callback in the struct bt_gatt_dm_cb (in 'gatt_dm.h') is triggered?

The Discovery completed callback in the struct bt_gatt_dm_cb is triggered when the discovery procedure has completed successfully. This callback function is part of the struct bt_gatt_dm_cb structure, which is used for tracking the result of a discovery.When you trigger the process of service discovert by calling the bt_gatt_dm_start() function. If the service discovery is performed and the service is found, the Discovery completed callback is triggered. After the service discovery is performed and if the service is found, you will receive the callback to the completed's callback.

2. In my central debugging, the le_param_updated callback was triggered even though I didn't use 'bt_conn_le_param_update'. Additionally, I observed that the connection parameters were set to 'interval: 40, latency: 0, timeout: 42' despite setting them to 'BT_LE_CONN_PARAM(80, 80, 0, 400)'. I suspect this is due to 'connection interval negotiation'. Can you provide the cause and a solution for this issue?

We might get a lot of answers if you capture the air sniffer logs of the whole update process in question and we could analyze packet by packet of what is happening between the central and peripheral. But we can try to have some theories below,

The le_param_updated callback is triggered when the connection parameters for a Bluetooth Low Energy (BLE) connection have been updated. This can happen automatically even if you didn't manually call bt_conn_le_param_update.

The automatic update could be due to the CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS in your prj. conf option in the Nordic SDK. When this option is enabled, the peripheral device will automatically request changes to the connection parameters to try to get the preferred values if the initial parameters given by the central don't match the peripheral's preferred parameters. This is why you see the le_param_updated callback being triggered.

As for the connection parameters being set to 'interval: 40, latency: 0, timeout: 42' despite setting them to 'BT_LE_CONN_PARAM(80, 80, 0, 400)', this could be due to the central device not accepting the requested parameters. The central device has the final say in the connection parameters, and it may not accept the requested parameters if they don't meet its own constraints or preferences.

To solve this issue, you can try the following:

1. Disable the automatic update of connection parameters by setting CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=n in your prj.conf file. This will prevent the peripheral from automatically requesting changes to the connection parameters.
2. Make sure the connection parameters you're requesting are within the acceptable range for the central device. Some devices may not accept certain values, such as a very short connection interval.
3. If you want to manually request a connection parameter update, you can use the bt_conn_le_param_update function. However, keep in mind that this is only a request, and the central device may still not accept the requested parameters.

[seongmincho]

Thanks to your advice

I was able to think about the issues from a broader perspective. I also studied carefully by looking at the GATT, Service, and Discovery parts of the code.

In the 'central - main.c' code, I did not define the desired conn_interval for the '.conn_param' variable in the 'struct bt_scan_init_param'. Then, I updated the desired conn interval in the connected callback( via bt_conn_le_param_update function), and the issue was resolved.

I have some questions.

1. I'm not sure why this resolved the issue. Does the .conn_param of struct bt_scan_init_param affect the bt_conn_le_param_update function?
2. I'm getting an error "[00:02:45.506,134] <err> bt_smp: pairing failed (peer reason 0x3)" between two nRF52840-DKs. However, there is no pairing issue between an nRF52840 and an nRF52840-DK. What can I do to resolve this issue? Can you help me?

[Susheel Nuguru]

seongmincho said:

I'm not sure why this resolved the issue. Does the .conn_param of struct bt_scan_init_param affect the bt_conn_le_param_update function?

Possibly, if the stack took the garbage uninitalized value to begin with then it could have some unpredictable side effects.

seongmincho said:

I'm getting an error "[00:02:45.506,134] <err> bt_smp: pairing failed (peer reason 0x3)" between two nRF52840-DKs. However, there is no pairing issue between an nRF52840 and an nRF52840-DK. What can I do to resolve this issue? Can you help me?

Again, you need to see the two air sniffer logs of

1) when the pairing works and
2) when the pairing doesn't work

and check what is happening in the the two devices with pairing issue. If you can attach the air sniffer log of both, then we can go through it together.

[seongmincho]

okay.. thank you for ur response. 

If I have some free time, I should study about sniffers.

[Susheel Nuguru]

Thanks, let us know if you need any other assistance regarding this topic after that.