Connection Parameter Negotiation Using Tolerance Settings - Best Practices

RE: Connection Parameter Negotiation Using Tolerance Settings - Best Practices

Edvin — Mon, 27 Oct 2025 13:21:02 GMT

Happy to help!

Let me know if you run into any other, related issues.

Best regards,

Edvin

RE: Connection Parameter Negotiation Using Tolerance Settings - Best Practices

Robert Edmonston — Wed, 22 Oct 2025 19:05:05 GMT

Thanks Edvin, this is helpful. I removed the on_conn_params_evt handler and now the peripheral stays connected even if the conn parameter update negotiations fail.

RE: Connection Parameter Negotiation Using Tolerance Settings - Best Practices

Edvin — Wed, 22 Oct 2025 12:47:48 GMT

Hello,

You can use your preferred connection parameters as guiding lines for your central. If you want your peripheral to have a certain set of parameters, then you should set a range which you accept. If a central enters connection with any of the parameters outside this range, it will try to negotiate the parameters MAX_CONN_PARAMS_UPDATE_COUNT (=3 by default) times. First one after 5 seconds, and the other two after 30 seconds each, I believe. These are also defined by some #defines in the application.

If you, however, want your device to stay connected regardless of connection parameters, you should indeed set disconnect_on_fail = false. This should just ignore the 3rd fail, and remain connected using whatever connection parameters it currently has.

If you are saying that the device disconnects even if disconnect_on_fail is set to false, then that sounds like a bug. What SDK version are you using?

At least in SDK 17.1.0, in ble_conn_params.c, line 207 it says:

static void update_timeout_handler(void * p_context)
{
    uint32_t                     conn_handle = (uint32_t)p_context;
    ble_conn_params_instance_t * p_instance  = instance_get(conn_handle);

    if (p_instance != NULL)
    {
        // Check if we have reached the maximum number of attempts
        if (p_instance->update_count < m_conn_params_config.max_conn_params_update_count)
        {
            bool update_sent = send_update_request(conn_handle, &p_instance->preferred_conn_params);
            if (update_sent)
            {
                p_instance->update_count++;
            }
        }
        else
        {
            p_instance->update_count = 0;

            // Negotiation failed, disconnect automatically if this has been configured
            if (m_conn_params_config.disconnect_on_fail)
            {
                ret_code_t err_code;

                err_code = sd_ble_gap_disconnect(conn_handle, BLE_HCI_CONN_INTERVAL_UNACCEPTABLE);
                if ((err_code != NRF_SUCCESS) && (err_code != NRF_ERROR_INVALID_STATE)) // NRF_ERROR_INVALID_STATE means disconnect is already in progress.
                {
                    send_error_evt(err_code);
                }
            }

            // Notify the application that the procedure has failed
            if (m_conn_params_config.evt_handler != NULL)
            {
                ble_conn_params_evt_t evt;

                evt.evt_type = BLE_CONN_PARAMS_EVT_FAILED;
                evt.conn_handle = conn_handle;
                m_conn_params_config.evt_handler(&evt);
            }
        }
    }
}

[quote user="Robert Edmonston"]

static void on_conn_params_evt(ble_conn_params_evt_t * p_evt)

{

uint32_t err_code;

if (p_evt->evt_type == BLE_CONN_PARAMS_EVT_FAILED)

{

err_code = sd_ble_gap_disconnect(m_conn_handle, BLE_HCI_CONN_INTERVAL_UNACCEPTABLE);

[/quote]

I do see this in some of the samples. This one is probably in main.c, as it is in the ble_app_uart example. But as you can see from it's description:

 * @note All this function does is to disconnect. This could have been done by simply setting
 *       the disconnect_on_fail config parameter, but instead we use the event handler
 *       mechanism to demonstrate its use.

So just remove this disconnect call, and it should work as you'd expect.

Best regards,

Edvin

RE: Connection Parameter Negotiation Using Tolerance Settings - Best Practices

Robert Edmonston — Wed, 22 Oct 2025 00:23:05 GMT

Just after posting I noticed something that may be why I'm seeing a disconnect on fail even though disconnect_on_fail is set to false.

Do I need to modify this function in ble_handler.c to prevent the negotiation failures from causing a disconnect?

/**@brief Function for handling an event from the Connection Parameters Module.

* @details This function will be called for all events in the Connection Parameters Module

* which are passed to the application.

* @note All this function does is to disconnect. This could have been done by simply setting

* the disconnect_on_fail config parameter, but instead we use the event handler

* mechanism to demonstrate its use.

* @param[in] p_evt Event received from the Connection Parameters Module.

static void on_conn_params_evt(ble_conn_params_evt_t * p_evt)

{

uint32_t err_code;

if (p_evt->evt_type == BLE_CONN_PARAMS_EVT_FAILED)

{

err_code = sd_ble_gap_disconnect(m_conn_handle, BLE_HCI_CONN_INTERVAL_UNACCEPTABLE);

if (err_code != NRF_ERROR_INVALID_STATE)

{

MM_VERIFY(err_code == NRF_SUCCESS, ERR_BLE_FAILED);

}