nrf51822蓝牙笔记之连接参数更新
2016-09-01 13:07
253 查看
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
![](https://devzone.nordicsemi.com/attachment/da2602ae040e13f68599877af790c71c)
Try e.g. the ble_app_template example. Start the application in the debugger and set a breakpoint as shown below
![](https://devzone.nordicsemi.com/attachment/80ecf7e86ea9bc31d39a97706a6f577d)
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:
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.
在规定的更新时间内成功协商成功就更新成功,如果失败则会断开连接,
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.
在规定的更新时间内成功协商成功就更新成功,如果失败则会断开连接,
相关文章推荐
- 低功耗蓝牙BLE之连接事件、连接参数和更新方法
- 关于低功耗蓝牙的连接参数更新
- 低功耗蓝牙BLE之连接事件、连接参数和更新方法
- 蓝牙连接【CONNECTION MODES,PROCEDURES】【从机请求更新连接参数】【断开连接原因HCI ERROR】【CONNECTION REQUEST】【连接过程】【跳频公式及过程】
- 低功耗蓝牙BLE之连接事件、连接参数和更新方法(包括时序控制等)
- 低功耗蓝牙设备DA1458x芯片开发之更新连接参数
- 低功耗蓝牙BLE之连接事件、连接参数和更新方法
- 低功耗蓝牙BLE之连接事件、连接参数和更新方法
- 低功耗蓝牙BLE之连接事件、连接参数和更新方法
- 低功耗蓝牙BLE之连接事件、连接参数和更新方法
- 蓝牙ble连接参数更新和低功耗原理
- 低功耗蓝牙BLE之连接事件、连接参数和更新方法
- 低功耗蓝牙BLE之连接事件、连接参数和更新方法
- 低功耗蓝牙BLE之连接事件、连接参数和更新方法
- 关于低功耗蓝牙的连接参数更新
- android 蓝牙ble app开发(二) -- 关键概念,连接参数,连接请求
- 修改蓝牙连接参数
- Java_jdbc 基础笔记之四 数据库连接 (通用更新方法)
- DB2学习笔记 --- python连接db2的connection方法参数
- cc2640官方demo更新连接参数service-CCservice