This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

s110 connection parameters negotiation

My peripheral device connects with central one very rarely. I decided that I don't want peripheral to negotiate connection parameters with central, just use settings imposed by central. I've used function from some example:

static void conn_params_init(void){
uint32_t               err_code;
ble_conn_params_init_t cp_init;

memset(&cp_init, 0, sizeof(cp_init));

cp_init.p_conn_params                  = NULL;
cp_init.first_conn_params_update_delay = FIRST_CONN_PARAMS_UPDATE_DELAY;
cp_init.next_conn_params_update_delay  = NEXT_CONN_PARAMS_UPDATE_DELAY;
cp_init.max_conn_params_update_count   = MAX_CONN_PARAMS_UPDATE_COUNT;
cp_init.start_on_notify_cccd_handle    = BLE_GATT_HANDLE_INVALID;
cp_init.disconnect_on_fail             = false;
cp_init.evt_handler                    = on_conn_params_evt;
cp_init.error_handler                  = conn_params_error_handler;

err_code = ble_conn_params_init(&cp_init);
APP_ERROR_CHECK(err_code);

}

I just commented it line with call of this function, and I don't receive BLE_GAP_EVT_CONN_PARAM_UPDATE events anymore. That would solve my problem, but after connecting and disconnecting (without any negotiations...) my device doesn't advertise anymore. I use timers to call advertising start/stop. No assert is shown on debug after that. Is it possible that interrupts stop working somehow?

Parents
  • This is the criteria that is used in ble_conn_params.c to decide if a connection parameter update request is started or not:

        // Check if interval is within the acceptable range.
        // NOTE: Using max_conn_interval in the received event data because this contains
        //       the client's connection interval.
        if (
            (p_conn_params->max_conn_interval >= m_preferred_conn_params.min_conn_interval)
            &&
            (p_conn_params->max_conn_interval <= m_preferred_conn_params.max_conn_interval)
           )
    

    Therefore, the best way to avoid starting a connection parameter update request is to define the minimum m_preferred_conn_params.min_conn_interval and maximum m_preferred_conn_params.max_conn_interval allowed by the BLE standard for your peripheral device, i.e.:

    #define MIN_CONN_INTERVAL               MSEC_TO_UNITS(7.5, UNIT_1_25_MS)
    #define MAX_CONN_INTERVAL               MSEC_TO_UNITS(4000, UNIT_1_25_MS)
    
Reply
  • This is the criteria that is used in ble_conn_params.c to decide if a connection parameter update request is started or not:

        // Check if interval is within the acceptable range.
        // NOTE: Using max_conn_interval in the received event data because this contains
        //       the client's connection interval.
        if (
            (p_conn_params->max_conn_interval >= m_preferred_conn_params.min_conn_interval)
            &&
            (p_conn_params->max_conn_interval <= m_preferred_conn_params.max_conn_interval)
           )
    

    Therefore, the best way to avoid starting a connection parameter update request is to define the minimum m_preferred_conn_params.min_conn_interval and maximum m_preferred_conn_params.max_conn_interval allowed by the BLE standard for your peripheral device, i.e.:

    #define MIN_CONN_INTERVAL               MSEC_TO_UNITS(7.5, UNIT_1_25_MS)
    #define MAX_CONN_INTERVAL               MSEC_TO_UNITS(4000, UNIT_1_25_MS)
    
Children
No Data
Related