Automatic disconnection by “BLE_HCI_CONN_INTERVAL_UNACCEPTABLE”

[takashina hiroki]

I have a question about “BLE_HCI_CONN_INTERVAL_UNACCEPTABLE”.

SDK: 15.3.0
Example: ble_app_multirole_lesc (source changed from sample)
Device: EYSHJNZWZ (nRF52832)

The device is operating as "Central".
After connecting with "Peripheral", "Peripheral" is disconnected after 4 minutes 30 seconds.
The disconnection factor is "BLE_HCI_CONN_INTERVAL_UNACCEPTABLE".
Please tell me about the cause of the disconnection.

[Susheel Nuguru]

This only happens when you get a BLE_CONN_PARAMS_EVT_FAILED which means that the connection param update procedure has failed. Your application must then retry the request with other parameter values. Here is a bit old thread but still with valid information on how the connection param update work on central and peripheral side..

[takashina hiroki]

Thank you for answering.
I will check it.

Please tell me one more thing.
Who sets 4 minutes and 30 seconds? ("Central" or "Peripheral")
And, Please tell me how to set it.

[Susheel Nuguru]

I am guessing that it is caused mostly by FIRST_CONN_PARAMS_UPDATE_DELAY which is used in ble_conn_params_init() if your app is initiating the connection parameter update procedure. If not, then it is just the delay used by your peer to initiate the connection parameter update procedure.

[takashina hiroki]

The setting of "ble_conn_params_init" is shown below.

#define C_BLE_CONN_PARAMS_FIRST_UPDATE_DELAY	APP_TIMER_TICKS(5000)					/*- 5s	: Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (in number of timer ticks).	*/
#define C_BLE_CONN_PARAMS_NEXT_UPDATE_DELAY		APP_TIMER_TICKS(30000)					/*- 30s	: Time between each call to sd_ble_gap_conn_param_update after the first (in number of timer ticks).	*/
#define C_BLE_CONN_PARAMS_MAX_UPDATE_COUNT		3										/*- 3	: Number of attempts before giving up the negotiation.					*/
#define C_BLE_CONN_PARAMS_DISCONNECT_ON_FAIL	trur									/*- ON	: Set to TRUE if a failed connection parameters update shall cause an automatic disconnection, set to FALSE otherwise. 		*/


ret_code_t				err_code;
ble_conn_params_init_t	cp_init;

memset(&cp_init, 0, sizeof(cp_init));
cp_init.p_conn_params					= NULL;										/*- [in] Pointer to the connection parameters desired by the application.	*/
cp_init.first_conn_params_update_delay	= C_BLE_CONN_PARAMS_FIRST_UPDATE_DELAY;		/*- [in] Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (in number of timer ticks). */
cp_init.next_conn_params_update_delay	= C_BLE_CONN_PARAMS_NEXT_UPDATE_DELAY;		/*- [in] Time between each call to sd_ble_gap_conn_param_update after the first (in number of timer ticks).	*/
cp_init.max_conn_params_update_count	= C_BLE_CONN_PARAMS_MAX_UPDATE_COUNT;		/*- [in] Number of attempts before giving up the negotiation.	*/
cp_init.start_on_notify_cccd_handle		= BLE_GATT_HANDLE_INVALID;					/*- [in] If procedure is to be started when notification is started, set this to the handle of the corresponding CCCD. 	*/
cp_init.disconnect_on_fail				= C_BLE_CONN_PARAMS_DISCONNECT_ON_FAIL;		/*- [in] Set to TRUE if a failed connection parameters update shall cause an automatic disconnection, set to FALSE otherwise. 	*/
cp_init.evt_handler						= NULL;										/*- [in] Event handler to be called for handling events in the Connection Parameters. 	*/
cp_init.error_handler					= NULL;										/*- [in] Function to be called in case of an error. 	*/
err_code = ble_conn_params_init(
									&cp_init										/*- [in] This contains information needed to initialize this module.	*/
);																					/*- Function for initializing the Connection Parameters module.			*/
r_APP_ERROR_CHECK(err_code);

"FIRST_CONN_PARAMS_UPDATE_DELAY" is set to 5s.
However, the cutting is done after 4 minutes and 30 seconds.
Why do you get disconnected after 4 minutes and 30 minutes?

[Susheel Nuguru]

takashina hiroki said:

Why do you get disconnected after 4 minutes and 30 minutes?

 We can get those answers by looking at the air sniffer log of those BLE packets. The communication between the two devices can reveal why the peer disconnected and when was the last BLE procedure initiated