前言
本文主要讲述广播、连接过程、连接参数、连接/断开的原因、协议事件及案例分析等方面知识。
主要分为以下几个部分：
- BLE广播基础，广播是BLE连接前的必要步骤
- 连接的基本流程，主要讲述主从设备连接的流程交互是怎样的
- BLE连接参数以及作用概述
- BLE连接相关的一些重点专业词语解释，包括监听、窗口、Anchor Point、T_IFS
- 连接与断开的事件、原因、协议解析
- 讲述BLE连接与断开的相关问题案例
- 思考与拓展、疑惑解答
- 参考站点
BLE广播基础回顾
连接基本流程讲述
BLL连接参数
参数 单位 典型范围 导致断连的临界条件 失效原理
min_conn_interval 1.25ms 7.5ms ~ 4s ≤12ms（芯片无法及时处理高频事件） 过小的间隔导致频繁中断，CPU负载过高，无法完成协议栈任务
max_conn_interval 1.25ms 7.5ms ~ 4s ≥2s（数据堆积导致缓冲区溢出） 过大的间隔导致数据积压，芯片内存或处理能力不足
conn_sup_timeout 10ms 100ms ~ 32s ≤6*T_conn（超时阈值不足） 监督超时过短，瞬时负载高峰导致响应超时
latency 次数 0 ~ 499 ≥（CPU处理时间/T_conn） 允许跳过的连接事件超过芯片实际处理能力，积累未处理数据
主从协商采用一个固定的interval，但必须在min和max的范围之内。另外可以在通信中，实时更新并协商新的参数，以便适应不同环境。
BLE为什么叫低功耗 因为是窗口定期监听
时间基点
从机窗口监听 窗口大小
min_conn_interval (最小连接间隔)
含义： 定义了两个连续的连接事件之间允许的最短时间。单位是 1.25ms。
例如：min_conn_interval = 8 表示最短间隔是 8 * 1.25ms = 10ms。
作用：
决定了连接能达到的最高通信频率（间隔越小，通信越频繁）。
影响功耗（间隔越小，设备唤醒越频繁，功耗越高）。
影响数据传输延迟下限（数据最快能在多短时间内被发送或接收）。
范围： 6 (7.5ms) 到 3200 (4000ms / 4s)。必须是整数。
max_conn_interval (最大连接间隔)
含义： 定义了两个连续的连接事件之间允许的最长时间。单位是 1.25ms。
例如：max_conn_interval = 20 表示最长间隔是 20 * 1.25ms = 25ms。
作用：
决定了连接能达到的最低通信频率（间隔越大，通信越不频繁）。
显著影响功耗（间隔越大，设备睡眠时间越长，功耗越低）。
影响数据传输延迟上限（数据最慢会在多长时间内被发送或接收）。
范围： 6 (7.5ms) 到 3200 (4000ms / 4s)。必须是整数，且 max_conn_interval >= min_conn_interval。
conn_sup_timeout (连接监督超时 / Connection Supervision Timeout)
含义： 定义了一个设备在认为连接丢失之前，可以连续错过多少个连接事件。单位是 10ms。
例如：conn_sup_timeout = 10 表示超时时间是 10 * 10ms = 100ms。
作用：
连接健壮性的关键参数。 它决定了连接对短暂干扰（如射频干扰、设备短暂移出范围）的容忍度。
超时值必须足够大，以允许在最大连接间隔和预期环境干扰下，设备有机会重新建立通信。如果超时时间内没有任何成功的连接事件发生，连接将被断开。
间接影响功耗（超时值大，设备在信号弱时会尝试更久才断开，可能消耗更多电量寻找信号）。
范围： 10 (100ms) 到 3200 (32s)。必须是整数。
计算公式 (关键联系)：
conn_sup_timeout 必须大于 (1 + slave_latency) * max_conn_interval * 3
其中 max_conn_interval 的单位是 ms (即 max_conn_interval * 1.25)，slave_latency 是下面要介绍的第4个参数。
这个公式确保了即使发生最大允许的连续错过事件（1 + slave_latency个），并且考虑了时钟漂移等容差（乘以3），连接也不会被错误地断开。实际应用中，通常设置 conn_sup_timeout 为计算值的 1.5 到 2 倍以上以增加鲁棒性。
slave_latency (从机延迟 / Slave Latency)
含义： 允许从设备跳过指定数量的连续连接事件，而无需唤醒监听主设备的数据包。单位是“跳过的连接事件个数”。
例如：slave_latency = 3 表示从设备最多可以连续跳过 3 个连接事件。
作用：
显著降低从设备功耗的关键参数。 如果从设备没有数据要发送，它可以跳过这些连接事件，进入深度睡眠状态，大大节省电量。
增加数据传输延迟。 如果主设备在从设备跳过的那个连接事件中发送了数据，从设备需要等到它下一次参与的连接事件才能收到。反之亦然，如果从设备有数据要发，也只能在它参与的连接事件中发送。
范围： 0 到 499。
有效连接间隔： 当 slave_latency > 0 时，从设备实际感知到的连接间隔变为 (1 + slave_latency) * conn_interval。主设备仍然按照 conn_interval 发送数据包，但从设备只会在 (1 + slave_latency) 个事件中醒来一次检查是否有数据。
约束：
(1 + slave_latency) * max_conn_interval 必须小于 conn_sup_timeout (参见上面的公式)，否则连接会被过早断开。
联系与区别总结：
参数 主要影响对象 核心作用 单位 关键关系/约束
min_conn_interval 通信频率上限 最小延迟、最高吞吐量、高功耗 1.25ms <= max_conn_interval
max_conn_interval 通信频率下限 最大延迟、最低吞吐量、低功耗 1.25ms >= min_conn_interval; conn_sup_timeout > (1+slave_latency)max_conn_int3
conn_sup_timeout 连接稳定性/健壮性 容忍丢包/干扰的能力 10ms 必须 > (1 + slave_latency) * max_conn_interval * 3 (考虑单位换算)
slave_latency 从设备功耗/延迟 允许从设备睡眠，大幅降低从机功耗 事件个数 (1 + slave_latency) * max_conn_interval * 3 < conn_sup_timeout
它们如何协同工作：
建立连接： 主从设备协商或由主机指定一组连接参数 (min_conn_int, max_conn_int, slave_latency, conn_sup_timeout)。实际使用的 conn_interval 会在 min_conn_int 和 max_conn_int 之间（通常由主机决定或协商）。
连接事件： 主设备在每个 conn_interval 时间点发起连接事件，发送一个数据包（可能包含数据或空包）。
从设备响应：
如果 slave_latency = 0，从设备必须在每个连接事件醒来监听并回复（即使发送空包）。
如果 slave_latency > 0 (例如 = 3)，从设备可以跳过最多 3 个连续连接事件。它只在第4个事件醒来监听并回复。这期间它可以深度睡眠。
连接监控：
每次成功完成一个连接事件（主从成功交换数据包，即使数据为空），连接监督计时器会重置。
如果连续 (1 + slave_latency) 个连接事件都失败（例如主设备发包了但从设备没醒/没回复，或者主设备没发包），那么 conn_sup_timeout 计时器就开始倒计时。
如果在 conn_sup_timeout 时间内，没有任何连接事件成功完成，连接就会被认为丢失并断开。
这就是为什么 conn_sup_timeout 必须足够大以容纳 (1 + slave_latency) 个可能的失败事件（乘以 3 的容差因子）。
如何选择这些参数？
功耗敏感型从设备（如传感器）： 倾向于设置较大的 max_conn_interval 和 非零的 slave_latency（在满足应用延迟要求的前提下），并相应增大 conn_sup_timeout。min_conn_interval 可以设置得小一些，以便在有数据需要快速传输时能协商到较小的间隔。
低延迟应用（如遥控器、音频）： 倾向于设置较小的 min_conn_interval 和 max_conn_interval（甚至相同），并将 slave_latency 设为 0。conn_sup_timeout 需要根据连接间隔设置足够大以保证稳定性。
稳定性要求高（环境干扰大）： 需要设置足够大的 conn_sup_timeout，确保它能容忍预期的最大干扰时间。同时可能需要避免过大的 slave_latency 或过大的 max_conn_interval，因为它们会增加 conn_sup_timeout 的要求值。
主设备（如手机、网关）： 通常对功耗不那么敏感，主要关注连接的稳定性和从设备的需求。它会根据从设备的请求（在连接请求或参数更新请求中）或自身的策略来设置这些参数。
总之，这四个参数是一个紧密耦合的整体。调整任何一个都可能影响连接的功耗、延迟和稳定性。设计时需要根据应用的具体需求（功耗优先、延迟优先还是稳定性优先）进行仔细权衡和计算（特别是 conn_sup_timeout 的约束公式）。
BLE 连接参数协商更新
更新的目的：
优化功耗： 当没有数据传输时（例如，传感器处于待机状态），从设备可以请求更大的max_conn_interval和/或非零的slave_latency来降低功耗。当需要传输数据时，再切换到更小的间隔和零延迟。
提高吞吐量/降低延迟： 当需要大量或快速传输数据（如固件升级、音频流、游戏手柄控制）时，主设备可以发起更新，使用更小的min_conn_interval/max_conn_interval和slave_latency = 0。
适应环境变化： 如果检测到连接不稳定（频繁丢包），可以适当增大conn_sup_timeout以增强鲁棒性（但需注意约束公式 conn_sup_timeout > (1 + slave_latency) * max_conn_interval * 3 必须始终满足）。
平衡多连接： 主设备连接多个从设备时，可能需要动态调整各个连接的参数来平衡总带宽和各个从设备的性能需求。
BLE的连接参数不是一成不变的，它们可以在连接保持的状态下实时、动态地更新。这种能力是BLE灵活适应不同应用需求（功耗 vs 性能 vs 稳定性）的关键机制。更新通常由主设备发起或由从设备请求（主设备批准），通过链路层(LL)或L2CAP层的特定命令完成，并在约定的未来Instant生效。
不同项目应用的连接参数
鼠标
对于不同项目中的应用，要能够做到合适的设计 可以实时更新连接参数 兼顾功耗与实时性
BLE 鼠标/键盘：空闲时使用较大间隔和延迟省电。当用户开始移动鼠标或敲击键盘时，设备检测到动作，主动请求或触发主设备更新到更小的间隔和零延迟，实现低延迟操作。
智能手表/手环： 大部分时间使用较大的连接间隔（如100ms）和非零延迟（如slave_latency=9）来省电。当用户抬起手腕查看屏幕时，应用通知主设备（手机）发起更新，切换到较小的间隔（如15ms）和零延迟，以便快速同步通知、天气等信息。用户放下手腕后，再切换回省电模式。
断开原因-标准协议
0x08
0x22
可能的原因
时序不稳、硬中断影响、其它的原因、低功耗sniff、
案例分析
超时断连
timeout
slave
BLE的连接参数是什么意思
No Response From Peripheral
Central 中心设备
Peripheral 外设
在BLE中，通常有两种角色：Central（中心设备）和Peripheral（外设）。Central通常是主动发起连接的设备，比如手机、平板等，而Peripheral是被动广播并等待连接的设备，比如手环、传感器等。但有时候设备可以同时支持两种角色，不过一般情况下，连接时会有明确的角色分配。
0x00 ADV_IND 可连接的非定向广播（最常见，音箱通常用此类型宣告存在）。
0x02 ADV_NONCONN_IND 不可连接的非定向广播（仅发送数据，不响应连接请求）。
0x03 SCAN_RSP 扫描响应（Peripheral对Central的SCAN_REQ的回复，含额外信息）。
广播包（Advertising Packet）
功能：
外设（如小米手环）通过广播包周期性发送自身存在信号，包含基础信息（如设备名称、支持的蓝牙服务UUID、电量状态等）。
触发方式：
无需中心设备（Central）请求，外设主动广播（类似“喊话”）。
当中心设备（如手机）扫描到广播包后，若需要更多信息，可发送扫描请求（SCAN_REQ），外设通过广播响应包回复补充数据（如详细服务特征、版本号等）。
触发方式：
需中心设备主动请求（发送SCAN_REQ），外设被动响应。
数据限制：
同样最大31字节，与广播包共同构成完整广播信息。
BLE广播
BLE建立连接
建立连接时，所耗费的cpu资源 通常要高？因为还没开始定时监听，都是全时进行通信的。
在优先级高的情况下，会导致占用其它线程时间
BLE从机监听
BLE连接问题案例分析
音箱与小米手环连接-BLE概率断开
08断连，一般超距断开会导致这个原因断开
Anchor Point 的工作机制
初始同步
在连接建立时，主机通过 CONNECT_IND 或 AUX_CONNECT_REQ 报文将首个 Anchor Point 发送给从机。双方以此为基准开始周期性通信。
通信窗口对齐
主从设备在每个连接事件的时间窗口内唤醒：
主机：在 Anchor Point + N × connInterval 时刻发送数据包。
从机：在相同计算的时间窗口内监听主机信号，接收成功后更新下一次窗口。
动态维护
若通信成功，Anchor Point 会根据实际通信时间微调（如补偿时钟偏移），但周期仍由 connInterval 主导。若失败，可能导致时序逐步偏移
BLE主机超时断开-导致通话音频卡顿
跟窗口监听调节有关
跟优先级有关