How to send LL_CONNECTION_PARAM_REQ from slave

Question

Hi, 
 I want to change the GAP params such as connInterval, slaveLatency, and have some questions:
 
 1.can I call sd_ble_gap_conn_param_update directly or need to send LL_CONNECTION_PARAM_REQ first and wait for the BLE_GAP_EVT_CONN_PARAM_UPDATE event?
a. If need to send LL_CONNECTION_PARAM_REQ, is there any API for calling?
b. If could call sd_ble_gap_conn_param_update directly, when to call?Any time?
2.What need to handle after sd_ble_gap_conn_param_update sent? I guess it will trigger the BLE_GAP_EVT_CONN_PARAM_UPDATE event in ble_conn_params_on_ble_evt, so... 
 Thanks.

Stefan Birnir Sverrisson · Accepted Answer

Hi Jimlin 
 If you run e.g. the ble_app_hrs in the nRF51 SDK and connect with the Master Control Panel (MCP) you can see in the log window of the MCP that there is received Connection Parameter Update Request from the nRF51822 device some seconds after your select the device, perform Service Discovery and Enable services. If you open the source code for the ble_app_hrs you should be able to see how the connection parameter update procedure is performed. 
 To explain a little how the procedure is constructed in the ble_app_hrs example:
There are two constants in the example that define the delay from enabling services until connection parameter update request is sent. These are the FIRST_CONN_PARAMS_UPDATE_DELAY which defines the first delay after enabling services and the NEXT_CONN_PARAMS_UPDATE_DELAY which defines the delay until the next connection parameter update request if parameter negotiation is not successful in the first round. 
 In short, the procedure is like this in the ble_app_hrs example: 
 [list=1]
In the init procedure in main, conn_param_init is called. 
 When services are enabled, CCCD is written on the device and the conn_params_negotiation function in ble_conn_params.c is called, which starts application timer with m_conn_params_timer_id. 
 When this application timer expires, sd_ble_gap_conn_param_update is called to send connection parameter update request to the central device. This request will only suggest to the central device the connection parameters the peripheral prefers. The central should send back new connection parameters for the connection but they may be different from the preferred connection parameters of the peripheral. 
 The central device will then send a connection parameter update request back which will trigger connection parameter negotiation on the nRF51822 side in the ble_conn_params.c -> on_conn_params_update callback (called from ble_conn_params_on_ble_evt in main). The connection parameters sent from the central are evaluated and it is checked if the connection interval is within the MIN_CONN_INTERVAL and MAX_CONN_INTERVAL. If the connection interval is not within MIN_CONN_INTERVAL and MAX_CONN_INTERVAL then the peripheral will send Connection Parameter Update Request again to the central, and repeat that MAX_CONN_PARAMS_UPDATE_COUNT number of times.
[/list] 
 You can call the sd_ble_gap_conn_param_update function at any time after you are connected to the central. However, service discovery is usually performed by the central after connection is established, which includes several packet transmissions back and forth. If you send the sd_ble_gap_conn_param_update with large connection interval before service discovery is performed, the service discovery procedure could be very time consuming. How time consuming will depend on the size of your BLE profile of course, i.e. how many services and characteristics it contains.