Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ble_conn_params.c questions

Hello, 

I have some questions about ble_conn_params.c in SDK14.2

Question : 

  1. a. Why do you need to handle four ble conditions?

      b. Shouldn't just send connect parameters request at the beginning of the connection?

    

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{	  
	uint16_t                     conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
    ble_conn_params_instance_t * p_instance  = instance_get(conn_handle);
	ret_code_t                   err_code ;

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_CONNECTED:
            on_connect(p_ble_evt);
            break;

        case BLE_GAP_EVT_DISCONNECTED:
            on_disconnect(p_ble_evt);
            break;

        case BLE_GATTS_EVT_WRITE:
            on_write(p_ble_evt);
            break;

        case BLE_GAP_EVT_CONN_PARAM_UPDATE:
            on_conn_params_update(p_ble_evt);
            break;

        default:
            // No implementation needed.
            break;
    }
}

  2. a.Once the connection parameters are acceptable to my peripheral, why do I need to enter conn_params_negotiation again( call from ble_evt_handler)?

      b. So does the connection parameters will continuous change ? 

     my log (gls example).

    

    I added NRF_LOG_INFO in conn_params_negotiation.

    

static void conn_params_negotiation(uint16_t conn_handle, ble_conn_params_instance_t * p_instance)
        {
    // Start negotiation if the received connection parameters are not acceptable
    if (!p_instance->params_ok)
            {
        ret_code_t err_code;
        uint32_t   timeout_ticks;

        if (p_instance->update_count == 0)
        {
                // First connection parameter update
                timeout_ticks = m_conn_params_config.first_conn_params_update_delay;
            }
            else
            {
                timeout_ticks = m_conn_params_config.next_conn_params_update_delay;
            }

        err_code = app_timer_start(p_instance->timer_id, timeout_ticks, (void *)(uint32_t)conn_handle);
        if (err_code != NRF_SUCCESS)
            {
            send_error_evt(err_code);
            }
        }
    else
    {
        p_instance->update_count = 0;

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

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

  3.Why needs a timer to trigger connect parameters update request ? Could I send first  request  immediately when I get ble connect event ?

  • 1) a) You seem to just have started with Bluetooth. Please go through our Softdevice documentation to understand Nordic's implementation of BLE stack. In short, our stack gives notifications to application through SWI interrupt events and application handle those events it think are relevant to it. 

     b) Yes you can, but in the above mentioned code snippet, this device is answering to the connection parameter update request from the peer device.  You need to look at these message sequence chart to understand the flow.

     

    2 a) You don't need to. But some peers would request different connection parameters based on the existing quality or your device can initiate it for some other reason.

    b) depends on peer and your device, this is not mandatory

    3) We give some time for the peer to finish its service discovery and other procedures to complete before triggering a connection params update. So to wait, we need a timer.

Related