Connection parameter update handling

RE: Connection parameter update handling

Carles — Mon, 28 Jul 2014 14:22:27 GMT

Very well, happy to hear that. Just wanted you to know that this cannot be caused by intense radio activity, and instead only depends on the actual state of the previous conn param update procedure.

RE: Connection parameter update handling

John — Mon, 28 Jul 2014 12:29:47 GMT

Hi Carles,

Thanks for the response and good question. I cannot say I am sure that the connection parameter update procedure isn't being triggered while a previous one is outstanding. I am using the ble_conn_params.c file provided as part of the SDK. I just skimmed through the code and it does appear there potentially are ways to restart the m_conn_params_timer_id timer when a previous connection parameters update procedure is running.

I did change the code to not assert on the NRF_BUSY return code and it seems to do no harm. It has been running on many devices in our QA department with no problems.

RE: Connection parameter update handling

Carles — Mon, 28 Jul 2014 11:41:52 GMT

Hi John,

sd_ble_gap_conn_param_update() will only return NRF_ERROR_BUSY if a previous connection parameter update procedure is still ongoing. Air traffic should have nothing to do with it.

Are you sure you are waiting for a BLE_GAP_EVT_CONN_PARAM_UPDATE before you retry initiating the procedure?

You can see a chart of the procedure here: devzone.nordicsemi.com/.../a00817.html

Carles