Behavior of sd_ble_gap_conn_param_update

[Sawada]

Peripheral: nrf52832

Central: nrf52840

The communication speed after executing sd_ble_gap_conn_param_update is different in the following two cases.

case 1:

When the BLE_GAP_EVT_CONNECTED event occurs,

Call sd_ble_gap_conn_param_update to update the communication parameter to the value of B.

case 2:

When the BLE_GAP_EVT_CONNECTED event occurs,

Call sd_ble_gap_conn_param_update to update the communication parameter to the value of A.

When BLE_GATTS_EVT_WRITE event occurs after BLE communication is established,

call sd_ble_gap_conn_param_update to update the communication parameters to the value of B.

A Parameter

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(50, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(65, UNIT_1_25_MS)
#define SLAVE_LATENCY 3
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(4000, UNIT_10_MS)

B Parameter

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(15, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(15, UNIT_1_25_MS)
#define SLAVE_LATENCY 0
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(10000, UNIT_10_MS)

Expect Behavior

Case 1 and case 2 have the same communication speed.

Actual Behavior

Case 1 has a much faster communication speed.

Is sd_ble_gap_conn_param_update used incorrectly?
Both update to the value of parameter B, but I don't know the reason for the difference in speed.

[Edvin]

Based on your case history, I guess that you are using SDK15.3.0, is that correct?

In SDK15.3.0, the min and max connection interval settings of the central is found in sdk_config.h. Search for "NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL" and "NRF_BLE_SCAN_MAX_CONNECTION_INTERVAL".

Make sure that both A and B are within the min and max of the central. 

Then you must wait for the BLE_GAP_EVT_CONN_PARAM_UPDATE for the new connection parameters to take effect. 

If that still doesn't seem to work, is it possible to do a sniffer trace using nRF Sniffer?

[Sawada]

>>Based on your case history, I guess that you are using SDK15.3.0, is that correct?
>>Make sure that both A and B are within the min and max of the central.
Yes, using Central is SDK15.3.0.

Each parameter had the following values:
#define NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL 7.5
#define NRF_BLE_SCAN_MAX_CONNECTION_INTERVAL 30

A Parameter is out of range.
B Parameter is in range.

Changed to the following values.
#define NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL 15
#define NRF_BLE_SCAN_MAX_CONNECTION_INTERVAL 65

However, even with this change, the communication parameters changed after the NEXT_CONN_PARAMS_UPDATE_DELAY time.

>>Then you must wait for the BLE_GAP_EVT_CONN_PARAM_UPDATE for the new connection parameters to take effect.
Waiting to receive BLE_GAP_EVT_CONN_PARAM_UPDATE
Param update will not be performed again until this event arrives.
However, the communication parameters are updated after the NEXT_CONN_PARAMS_UPDATE_DELAY time has elapsed.

>>If that still doesn't seem to work, is it possible to do a sniffer trace using nRF Sniffer?
Can I provide a sniffer log file obtained with WireShark?

[Sawada]

static void gap_params_init(void)
{

…

gap_conn_params.min_conn_interval = FAST_MIN_CONN_INTERVAL;
gap_conn_params.max_conn_interval = MAX_CONN_INTERVAL;
gap_conn_params.slave_latency = SLAVE_LATENCY;
gap_conn_params.conn_sup_timeout = CONN_SUP_TIMEOUT;

err_code = sd_ble_gap_ppcp_set(&gap_conn_params);
APP_ERROR_CHECK(err_code);

}

The value set here was A Parameter.

When B parameter was checked with the function of is_conn_params_ok (), it became NG and the timer started.

Including the parameters A and B in the value set by gap_params_init () no longer causes problems.