nrf51822蓝牙笔记之连接参数更新

        The Peripheral Preferred Connection Parameters (ppcp) contains e.g. the MIN_CONN_INTERVAL and MAX_CONN_INTERVAL values which is set into the GAP service with call to functionsd_ble_gap_ppcp_set(). If you read that with sd_ble_gap_ppcp_get() you will only get the same preferred peripheral values again, but not the actual connection parameters chosen by the central.（实际的连接参数由主设备决定）。

       If you use the Master Control Panel to connect to the device and discover services, you will see the values that you set with sd_ble_gap_ppcp_set() in a characteristic with name SlavePreferredConnectionParameters

Try e.g. the ble_app_template example. Start the application in the debugger and set a breakpoint as shown below

     Then if you connect with the Master Control Panel, discover services and enable services, then you will see five seconds later that execution stops at the breakpoint. If you then watch "m_current_connection_params" variable, then you can see that both min and max values are 0x0190（这个就是主设备提供的）, which is 400 decimal which is equal to 500ms since the connection interval is represented in 1.25ms steps（400*1.25=500MS）. 

(由此可知这设备在从设备所给的范围内协商了一个500ms作为连接事件的周期)

In the ble_app_template example MIN_CONN_INTERVAL = 500ms and MAX_CONN_INTERVAL = 1000ms, so in this case, Master Control Panel has chosen 500ms connection interval.

Initially, the central will connect to the peripheral with connection paremters that the central decides what is. After the connection is established, the Peripheral can send connection parameter update request to the central and the central most likely responds with a connection parameter update. However, by Bluetooth spec, the central is not obligated to responde to the connection parameter update request, it may just ignore it. The received update from the central is not certain to be what the peripheral requested. If the peripheral can not accept the connection parameter update from the central it can choose to disconnect from the central.

The three following connection parameters are sent to the central for negotiation:

#define MIN_CONN_INTERVAL                    MSEC_TO_UNITS(500, UNIT_1_25_MS)          

/**< Minimum acceptable connection interval (0.5 seconds). */

#define MAX_CONN_INTERVAL                    MSEC_TO_UNITS(1000, UNIT_1_25_MS)         

/**< Maximum acceptable connection interval (1 second). */

#define SLAVE_LATENCY                        0                                     

/**< Slave latency. */

#define CONN_SUP_TIMEOUT                     MSEC_TO_UNITS(4000, UNIT_10_MS)           

/**< Connection supervisory timeout (4 seconds). */

The connection interval has minimum and maximum value so that the central will have some flexibility in deciding the connection interval.

If the peripheral receives connection parameter update from the central which is unacceptable it can choose to send another connection parameter update request to the central in order to make the connecton parameter negotiation be successful. How many connection parameter update requests are sent is determined by the MAX_CONN_PARAMS_UPDATE_COUNT constant in i.e. the ble_app_hrs example in the SDK. The FIRST_CONN_PARAMS_UPDATE_DELAY determines how long time should pass from start of notification until sending the first connection parameter update request, and the NEXT_CONN_PARAMS_UPDATE_DELAY determines how long after the first request the following connection parameter update requests should be sent.

In the ble_app_hrs the connection parameter update request is initiated by starting an application timer with id: m_sensor_contact_timer_id. The timer is initialized in conn_params_init() call in the main function and it is started in the connect hook it seems.

在规定的更新时间内成功协商成功就更新成功，如果失败则会断开连接，