连接参数为什么不能乱填：Interval、Latency、Timeout 与频道图
前提知识
阅读本文需要具备以下基础：
- 理解
CONNECT_IND的字段含义（第 4-1 篇有详细讲解）：本文不再重复解释Interval、Latency、Timeout、ChM、Hop、SCA分别是什么，而是重点分析为什么这些值不能随便填。 - 理解第一次连接事件的时序计算（第 4-2 篇有详细讲解）：首次窗口一旦过去，连接就进入周期化运行，此时这些参数才真正长期生效。
- 理解 ppm（百万分之一）和晶振误差的基本概念：本文会解释 SCA 为什么会影响后续接收窗口大小。
不需要提前了解第 10 篇跳频算法和第 11 篇 Window Widening 的完整推导。本文只做主线所必需的最小解释。
一、为什么“参数能解析出来”不等于“参数合法”
很多协议实现初学者容易犯一个错误：只要包格式对、字段长度对、CRC 校验通过，就认为 CONNECT_IND 应该被接受。
这个想法的问题在于：链路层的很多参数不是描述性字段，而是约束性字段。
它们不是“告诉你将来会怎样”，而是“要求双方未来必须按这个节奏工作”。如果这个节奏本身物理上就不成立，那么即使现在收下这份 CONNECT_IND，连接也只会在随后几次事件里快速崩溃。
所以 Controller 在解析 CONNECT_IND 时，不能只做语法检查，还必须做物理可行性检查和规范合法性检查。
二、Interval：为什么不能小于 7.5 ms
Interval 的单位是 1.25 ms。BLE 规范规定它的最小值是 6，也就是：
为什么不是 1.25 ms、2.5 ms 或 5 ms？因为连接事件不是一个单比特动作，它里面至少包含：
- 一方发出数据包
- 另一方在 T_IFS 后回包
- 可能还会继续多轮来回交互
- 事件结束后双方还要关射频、准备下一次调度
如果 Interval 太短，某个连接事件还没收尾，下一次事件的理论起点就已经到了。多个连接事件会互相重叠，调度器根本没有时间重新装载无线配置，整个连接会陷入持续冲突。
所以 7.5 ms 不是一个随意的工程偏好，而是 BLE 对“一个最短可运行连接节奏”的规范下限。
三、Latency：为什么省电不能无限贪
Latency 允许 Slave 在没有数据时连续跳过若干个连接事件。它看起来像一个纯福利参数：数值越大，Slave 就能睡得越久，功耗越低。
但 Latency 不是越大越好。因为它改变了另一个问题：主从双方允许多久不碰面。
假设：
Interval = 50 msLatency = 4
那么 Slave 最多可以连续跳过 4 个连接事件，也就是最多有：
才会真正与 Master 重新见面一次。
这里为什么是 Latency + 1，而不是 Latency？因为“跳过 4 次”意味着前后两次真正见面之间跨越了 5 个间隔。
如果这个跨越时间已经接近甚至超过监督超时，连接逻辑就会自相矛盾：规范一边允许 Slave 合法睡着，一边又因为太久没通信把链路判死。
四、Timeout：为什么必须大于一个完整 Latency 周期
Timeout（监督超时）的单位是 10 ms。它表示：如果连续这么久都没有任何成功的连接事件，双方就认定连接已经断开。
这就引出一个硬约束：
严格换算到协议字段单位时，常见写法是：
右边为什么还要除以 10 ms？因为 Timeout 字段本身是以 10 ms 为单位编码的，必须换算到同一单位后才能比较。
如果不满足这个关系，会发生什么？
最典型的后果是：Slave 按规范允许的 Latency 连续睡了几轮，但 Master 这边的监督计时器已经先超时了，于是连接被主动断开。也就是说，Controller 一边允许不见面，一边又因为不见面惩罚断链。这是逻辑上自我冲突的配置，必须在解析 CONNECT_IND 时就直接拒绝。
五、ChM：为什么至少要保留足够多的数据信道
ChM（Channel Map）是一张 37 bit 的数据信道可用表。它看起来只是个布尔位图，但它背后约束的是连接还能否持续跳频。
为什么不能把大部分 bit 都清成 0，只留一两个"最干净"的信道？
因为 BLE 跳频的目的不是找一个永远最好用的点，而是在多个信道之间分散风险。如果可用信道太少，会出现两个问题：
问题一：抗干扰能力下降。
你把整条连接压到 1~2 个信道上，等于把所有鸡蛋都放在一个篮子里。一旦这几个频点刚好被 Wi-Fi 压住，整条链路就没有躲避空间。
问题二：跳频均匀性被破坏。
后续的 Hop 算法默认有一组可供重映射的信道池。如果池子太小，所谓跳频就退化成固定在极少数频点上反复尝试，规范层面的频率分散优势几乎消失。
因此，Controller 在处理 ChM 时，不只是“按位抄下来”这么简单，而是要保证这张可用表仍然支撑一条可运行的跳频链路。
六、Hop：为什么取值被限制在 5 到 16
Hop 是跳频增量。它规定从当前数据信道推算下一次候选信道时，每次前进多少格。
规范把它限制在 5 到 16，不是为了凑一个好记的范围，而是为了避免两个极端：
- 太小：例如 1、2、3，会让信道序列在局部缓慢移动，覆盖性差，容易在相邻信道附近长期徘徊。
- 太大或非法：会让序列在某些模数关系下过快重复，失去均匀遍历的性质。
跳频算法真正的数学细节会在第 10 篇展开。这里先抓住一个工程结论：Hop 的合法区间本质上是在保证信道访问的覆盖性，而不是随便给一个“推荐值”。
七、SCA：为什么时钟精度也要写进连接契约
SCA（Sleep Clock Accuracy）描述的是 Master 休眠时钟的精度等级，通常以 ppm 级别理解。
很多人第一次看到这个字段会疑惑：时钟准不准，不是硬件自己的事吗，为什么要放进 CONNECT_IND？
因为 Slave 后续必须根据这个精度等级，估算 Master 在两个连接事件之间可能漂移多少时间，从而决定自己的接收窗口应该提前开多早、延后关多晚。
举个最简单的量级例子：
如果 SCA 对应约 500 ppm，Interval 是 100 ms，那么单个周期的潜在时钟偏差量级就是：
50 µs 已经远大于 T_IFS 那个 ±2 µs 量级了。若不把这类误差估算进后续调度，Slave 的接收窗口很快就会偏离 Master 的真实发包时刻。第 11 篇 Window Widening 专门处理这个问题，而它的输入之一就是这里的 SCA。
八、解析后的最小合法性检查
在手写 Controller 里，CONNECT_IND 至少应做下面这些主线检查：
Interval >= 6Timeout > Interval × (Latency + 1) × 1.25 ms / 10 msHop在规范允许范围内ChM不是明显不可运行的极端配置- 所有字段换算后的物理节奏仍能被本机调度器支持
这里最后一点很重要。即使一个值在规范上合法，也未必适合当前实现。例如你的简化调度器当前只支持较短连接列表，或只支持固定 PHY，那么某些极端但合法的参数组合仍然可能超出当前代码能力边界。这时应该明确拒绝，而不是带着已知不可靠的配置硬跑。
九、代码验证：03_phy_connect_ind 例程解析
基于以上理论，我们在 03_phy_connect_ind 这一步的代码目标非常明确：从空口收到 CONNECT_IND 包，完成协议规定的字段解析与提取，并作初步印证。 不涉及复杂的调时与建连。
我们在 src/ll_pdu.c 中增加对 payload 的反序列化处理：
void parse_connect_ind(const struct pdu_adv *rx_pdu)
{const struct pdu_adv_connect_ind *ci = &rx_pdu->connect_ind;memcpy(conn_params.peer_addr, ci->init_addr, BDADDR_SIZE);memcpy(conn_params.access_addr, ci->access_addr, 4);memcpy(conn_params.crc_init, ci->crc_init, 3);conn_params.win_size = ci->win_size;conn_params.win_offset = sys_le16_to_cpu(ci->win_offset);conn_params.interval = sys_le16_to_cpu(ci->interval);conn_params.latency = sys_le16_to_cpu(ci->latency);conn_params.timeout = sys_le16_to_cpu(ci->timeout);memcpy(conn_params.chan_map, ci->chan_map, PDU_CHANNEL_MAP_SIZE); conn_params.hop = ci->hop;conn_params.sca = ci->sca;conn_params.chan_count = count_ones(conn_params.chan_map, PDU_CHANNEL_MAP_SIZE);
}
随后，在主循环中，一旦设备收到合法的该包，我们将其 12 个参数换算为易读的物理量输出。使用 bumble_connect.py 发起连接请求，可以在串口看到：
========== CONNECT_IND Received ==========Peer: A6:55:44:33:22:11AA: 0x6E2C91D3CRC Init: 0xA4B19CWinSize: 2 (x1.25ms = 2500 us)WinOffset: 8 (x1.25ms = 10000 us)Interval: 40 (x1.25ms = 50000 us)Latency: 0Timeout: 200 (x10ms = 2000 ms)Hop: 14SCA: 5 (50 ppm)Chan Count: 37 / 37T0 (RTC0): 182372 ticks
==========================================
至此，“蓝牙连接”对我们而言，正式剥离了神秘的黑盒外衣，变成了一份可以被精准解析、包含 12 个固定变量的契约束。下一步，就是如何依据这份契约里的 WinOffset 准时赴约了。
小结
| 知识点 | 结论 |
|---|---|
| 参数校验的本质 | CONNECT_IND 不能只做格式检查，还必须做规范合法性和物理可行性检查 |
| Interval 下限 | 最小值 6，即 7.5 ms；再小会让连接事件收尾与下一次调度发生重叠风险 |
| Latency 的真实含义 | 允许 Slave 连续跳过若干事件节能，但会拉长两次实际见面之间的时间 |
| Timeout 约束 | 必须大于一个完整的 (Latency + 1) × Interval 周期，否则连接逻辑自相矛盾 |
| ChM 的意义 | 不只是位图记录，而是整条跳频链路还能否持续运行的可用道路图 |
| Hop 的限制原因 | 5 到 16 的范围是为了保证跳频覆盖性，避免序列退化成局部打转 |
| SCA 的作用 | 给 Slave 提供 Master 时钟漂移量级，作为后续 Window Widening 的输入 |
| 实现层面的底线 | 规范合法不等于当前代码一定支持；超出实现能力边界的参数组合应主动拒绝 |