第3章 BLE连接参数速查：连接间隔、监控超时、slave latency 对冲突的影响

3.1 现象识别

当 BLE 多连接系统中出现数据写入冲突时，首先会在应用层或协议栈日志中暴露以下三类典型现象。请对照下表快速确认当前问题是否与连接参数相关。

故障树：数据写入冲突的连接参数诱因

• 连接参数配置不当
  • 连接间隔（Connection Interval）过短 → 连接事件频繁重叠 → 数据包碰撞
  • 监控超时（Supervision Timeout）过短 → 轻微重传即触发超时断开 → 写入中断
  • Slave Latency 过大 → 从设备长期休眠 → 数据积压后集中写入 → 缓冲区溢出
• 多连接并发写入
  • 多个 Master 同时向同一 Slave 写入
  • 单 Master 在多个连接事件中背靠背写入
• 协议栈或射频资源争抢
  • 连接间隔与广播/扫描窗口重叠
  • 射频中断或调度延迟

现象排查表

判断规则

1. 如果日志中出现 Supervision Timeout 关键字 → 优先排查监控超时参数。
2. 如果写入失败伴随 INSUFFICIENT_RESOURCES → 优先排查连接间隔和 Slave Latency。
3. 如果仅在高负载多连接场景下出现冲突 → 优先排查连接间隔是否小于 30ms。

3.2 数据采集

采集当前系统中所有 BLE 连接的参数是定位冲突的前提。使用抓包工具或主机协议栈 API 获取以下三个关键参数。

参数采集方法

• 方法一：抓包工具（Ellisys / Wireshark / Nordic nRF Sniffer）
  捕获连接请求包（CONNECT_REQ），直接解析 ConnInterval、ConnSupervisionTimeout、SlaveLatency 字段。
• 方法二：主机 API 查询
  通过 hci_read_connection_info() 或等效调用获取当前连接参数。
• 方法三：从设备端日志
  在协议栈事件回调中打印连接参数更新通知。

参数记录表

判断规则

• 连接间隔 < 20ms → 在多连接场景下极大概率产生射频碰撞，需标记为高危。
• 监控超时 < 3 × 连接间隔 × (Slave Latency + 1) → 理论上可能因少量丢包导致超时断开。
• Slave Latency > 10 → 写入数据会在从设备端积压，增加单次写入的数据量。

3.3 原因定位

将采集到的参数代入以下判断矩阵，快速定位冲突的主要诱因。

原因定位矩阵

判断规则（决策树）

1. 是否有连接断开？
   • 是 → 检查监控超时是否 < 3 × 连接间隔 × (Slave Latency + 1)。如果是，定位为监控超时过短。
   • 否 → 进入第 2 步。
2. 是否有写入失败（资源不足）？
   • 是 → 检查连接间隔是否 < 20ms 或 Slave Latency > 5。如果是，定位为连接间隔过短或 Slave Latency 过大。
   • 否 → 进入第 3 步。
3. 写入延迟高但不失败？
   • 是 → 检查连接间隔是否 > 50ms 且 Slave Latency > 0。如果是，定位为连接间隔与 Latency 组合导致吞吐不足。

3.4 修复动作

根据定位结果，执行以下参数调整步骤。所有修复必须遵守 BLE 核心规范 4.2+ 的参数范围约束。

参数范围速查

具体修复步骤（按优先级）

1. 增大连接间隔
   • 将冲突连接的间隔从 < 20ms 增大至 30–50ms。
   • 使用协议栈 API 发起连接参数更新请求：

   // 示例：通过 GAP 发起连接参数更新
   // 参数：最小间隔 30ms，最大间隔 50ms，Slave Latency 0，超时 4000ms
   gap_conn_params_update(
       conn_handle,
       24,   // 30ms / 1.25ms = 24
       40,   // 50ms / 1.25ms = 40
       0,    // Slave Latency
       400   // 4000ms / 10ms = 400
   );

2. 增大监控超时
   • 确保监控超时 ≥ 3 × 连接间隔 × (Slave Latency + 1) + 安全裕量（建议 500ms）。
   • 例如：连接间隔 40ms，Slave Latency 2 → 3×40×3 = 360ms → 建议设置 ≥ 1000ms。
3. 减小 Slave Latency
   • 将对延迟敏感的连接设为 Slave Latency = 0 或 1。
   • 对低功耗连接可保留 2–5，但需同步验证写入缓冲区不溢出。
4. 协调多连接间隔
   • 如果系统有多个连接，尽量使各连接的间隔互为整数倍，减少重叠概率。
   • 示例：连接 A 间隔 30ms，连接 B 间隔 60ms，连接 C 间隔 30ms（与 A 交错调度）。

3.5 复测

参数调整后，执行以下验证流程，确认冲突已消除且连接稳定性未受损。

验证方法

• 稳定性测试：连续运行 5 分钟，监控连接是否断开。使用以下命令抓取连接事件：

# 使用 hcitool 或 bluetoothctl 监控连接状态
bluetoothctl monitor
# 观察 Supervision Timeout 相关日志
# 预期输出：无 "Link Loss" 或 "Disconnected" 事件

• 写入成功率测试：以 10ms 间隔连续发送 1000 次写入，记录成功次数。

# 伪代码：写入成功率统计
total_writes = 1000
success_writes = 0
for i in range(total_writes):
    ret = ble_gattc_write(handle, data, len)
    if ret == BLE_ERR_OK:
        success_writes += 1
    os.sleep(10)  # 10ms 间隔
success_rate = (success_writes / total_writes) * 100
print(f"写入成功率: {success_rate}%")

复测通过标准

3.6 预防

在系统设计阶段建立参数配置规范，从源头避免连接参数引发的数据写入冲突。

预防措施清单

• 建立参数配置矩阵：根据应用场景选择预设参数组，避免临时随意配置。

• 连接参数更新请求必须校验：在主机端实现参数合理性检查，拒绝明显不合理的参数组合。

// 参数校验示例
bool is_params_valid(uint16_t interval, uint16_t timeout, uint16_t latency) {
    // 规则1：监控超时必须 ≥ 3 × 间隔 × (latency+1)
    uint16_t min_timeout = 3 * interval * (latency + 1);
    if (timeout < min_timeout) return false;

    // 规则2：多连接场景下间隔不得小于 20ms
    if (multi_conn_mode && interval < 16) return false; // 16 × 1.25ms = 20ms

    // 规则3：Slave Latency 不得超过 10（对写入敏感系统）
    if (write_sensitive && latency > 10) return false;

    return true;
}

• 定期巡检：在生产系统中每隔 1 小时拉取一次连接参数，与基线对比，发现异常自动告警。
• 使用连接参数更新协商机制：Slave 端可主动提出更优参数，避免 Master 单方面设置不合理值。

参数影响关系图