先从一个真实的问题说起。某天一个硬件群里的老哥发了段日志他的运动手环模块跟手机 App 连接一切正常心率数据每秒一条但记录里每隔几十秒就会少一条而且缺的位置完全随机。他怀疑是“BLE 链路参数”没调好于是把 Connection Interval 从 7.5ms 改成 30ms又从 30ms 改成 15ms折腾了一晚上丢帧依旧。这几乎是所有 BLE 初学者都会犯的错把链路参数当成一个旋钮以为调小就能提高可靠性却完全没搞清 Connection Event、链路层自动重传和应用层“丢帧”这三者之间到底是什么关系。这篇就把这层窗户纸捅破聊聊链路参数到底在干什么、自动重传为什么救不了一切以及你看到的那个“丢帧”究竟是在哪一层丢的。不管你是写单片机固件、搞手机 App还是负责产品测试都可以把它当一份 BLE 空口通信的排障手册来读。1. 链路参数是一份“双向定时合同”不是调得越小越好1.1 三个核心参数的职责和取值范围BLE 链路层参数其实就三个Connection Interval连接间隔、Slave Latency从机延迟、Supervision Timeout监督超时。很多人把它们当成三个性能开关实际它们更像是一份合同规定了两个无线电设备之间“多久见一次面、能不能请假、多久不联络就算分手”。参数单位取值范围一句话理解Connection Interval1.25ms 的倍数7.5ms ~ 4s两个 Connection Event 起始点之间的时间间隔Slave Latency事件个数0 ~ 499从机允许连续缺席多少个 Connection EventSupervision Timeout10ms 的倍数100ms ~ 32s超过这个时间双方没有任何有效数据交换连接直接判定丢失这里最容易忽略的是三者之间的硬约束Supervision Timeout 必须大于 2 × (1 Slave Latency) × Connection Interval。为什么是两倍因为链路层要留出足够余量应对时钟漂移。比如你设置连接间隔 100ms、从机延迟 5那么超时值至少得大于 2 × 6 × 100ms 1200ms否则从机合法地睡完几个事件超时窗口可能就提前触发了连接会被莫名其妙地干掉。1.2 参数由谁决定别以为你改了就等于生效很多工程师在固件里调了一版参数就以为空口上跑的就是这个值这是第二个误区。真实流程是连接建立时主设备在 CONNECT_IND 里给出初始参数之后主设备可以主动更新从机也可以发起请求——一种是通过链路层的 LL_CONNECTION_UPDATE_REQ另一种是通过 L2CAP 固定通道 0x0005 发送 Connection Parameter Update Request。但最终拍板的是主设备。落到手机上就更特殊主流手机系统通常不会开放“直接设置连接间隔”的接口App 只能表达一个“连接优先级”比如低延迟、均衡、省电具体参数由系统协议栈决定。经常出现的情况是你的模块拼命请求 7.5ms手机最后给了 30ms。所以排查问题时要做的第一件事永远是打印出实际协商成功并被对端接受的参数而不是你以为的那一组。这个习惯能省掉大量无效加班。2. Connection Event被绝大多数人忽略的最小时间骨架2.1 一个 Connection Event 内部的“回合制”交换Connection Event 是 BLE 连接状态下最基本的时间单元。每隔一个 Connection Interval主设备就会在锚点Anchor Point发出一个包从机必须在这个时间点附近处于接收状态。这个包可以是带数据的也可以是一个空包——空包不携带用户数据但携带了链路层的 SN/NESN 应答信息作用是维持连接、确认上一条数据。包与包的交换之间隔着一个 T_IFS固定 150µs。你可以把它想象成乒乓球对拉主设备发一球从机回一球一来一回才完成一次“传输机会”。一个 Connection Event 里可以有多轮这样的交换只要双方都还有数据且事件时间没有耗尽。事件结束的条件有两个要么主设备发了一个空包从机也回了一个空包双方都没有更多数据可发要么到了控制器设定的最大事件时长。事件结束后双方无线电进入待机直到下一个锚点。2.2 事件长度、多包交换和吞吐量的真实上限这里有个关键概念必须分开Connection Interval 是“多久开一次会”事件长度是“每次会开多久”。很多控制器内部对一次事件能持续多久有独立限制有些默认只允许很短的窗口导致每个事件只能交换一两包数据。举个具体的数字。假设连接间隔 30ms事件长度只有 2ms。如果没开 DLE链路层一个包最多 27 字节空口耗时大约 0.3ms那这一个事件还能塞下几个包但如果开了 DLE一个包最大 251 字节在 1M PHY 下空口耗时接近 2ms那一个事件就只够发一包。这就是为什么很多人开了 DLE 后吞吐量没提上去——瓶颈不在 MTU而在事件长度。有些协议栈支持配置最大事件长度比如设为 3 倍的连接间隔不设置的话高速传输根本跑不起来。2.3 事件节奏如何决定延迟和功耗数据从应用层写入到真正上天理论上最坏要等一个完整的连接间隔你在锚点刚过的那一刻写入那就得等到下一个锚点。连接间隔 30ms最坏延迟就是 30ms 起步如果再碰上重传每重试一次还要再叠加。而功耗方面从机为了不错过锚点即使没有数据也要醒来接收主设备的空包。连接间隔 7.5ms 意味着从机每秒要醒来 133 次。哪怕每次只醒 2ms累积起来的电流开销也相当可观。所以“连接间隔调得越小越好”这句话在大功耗场景里就是灾难。3. 自动重传的本质停止等待 ARQ 与“隐形延迟”3.1 链路层的停止等待机制SN/NESN 位翻转搞清楚自动重传先得明白 BLE 链路层的应答方式。它用的是停止等待 ARQ发送方一次只允许有一个未确认的数据包挂在空中只有收到确认后才能发下一个新包。每个链路层数据包头里有两个关键位SN发送序号和 NESN期待收到的下一个序号。接收方校验 CRC 通过后把自己的 NESN 翻转一下作为应答发回给发送方发送方发现 NESN 翻转了就知道上一包被收下了。如果 CRC 校验失败接收方根本不会送回任何有效应答发送方等不到确认就会在后续的 Connection Event 里重发这个包。有些实现允许在同一事件内补发有些则只能等下一个事件。无论哪种一次重试至少要付出一个连接间隔的时间代价。这非常重要因为它决定了自动重传的本质它把一次空口错误转化成了延迟而不是直接转化为丢失。3.2 重传风暴连接还活着数据却全“迟到”了在一个 WiFi 密集、蓝牙设备扎堆的办公环境里空口干扰是常态。假设连接间隔 30ms某个包连续 5 个事件都没收到确认那么它实际被确认的时间是 150ms 之后。对于心率这种 1 秒一条的数据150ms 的延迟通常还能容忍但对于实时控制、音频同步这类应用150ms 已经超标了应用层早就按“超时”处理了。于是连接没有断数据也一个不少但应用层看到的却是“丢帧、乱序、卡顿”。这是最容易被误判的一类问题抓包工具在空口上能看到每个包最终都发出去了对端也确认了于是你怀疑是应用逻辑的 bug结果查了半天发现是无线环境导致的重传风暴。所以说自动重传不是保险它只是把问题从“丢”变成“晚”而且这个“晚”对某些业务来说就等于“丢”。3.3 链路层救不了的四件事很多人默认“链路层有自动重传所以数据不会丢”这个认知至少错了一半。自动重传只在一个非常窄的范围内有效它有四个明确的边界第一监督超时触发。一旦超过 Supervision Timeout 双方没有任何有效包交换连接被判定丢失两端的控制器会静默清理所有未确认的发送队列和接收缓冲这时候排队中的数据是真的没了而且是不可恢复的没。第二发送队列溢出。应用写入的速度超过链路层实际能排空的速度写操作要么返回失败要么被协议栈静默丢弃——GATT Write Without Response 尤其容易踩这个坑。第三接收端处理不过来。数据到了对端控制器但对端应用层消费速度跟不上协议栈的接收缓冲区满后续包也可能被丢。第四高层协议状态被破坏。比如 L2CAP 分片还没拼完整连接就断了半条消息直接作废。还有一个必须强调的事实BLE 链路层不会把重传次数上报给应用层。应用层看不到任何“重传”事件只能从延迟变化、吞吐下降这些间接信号里去猜。这就让“自动重传到底发生了什么”成了一个很难直接观察的黑盒也是很多排查工作陷入僵局的原因。4. 一帧 Notify 的完整旅程四个“看起来发出去了”的层4.1 发送侧的每一层都在干什么要从根上理解应用层丢帧得跟着一帧数据走完全程。假设外设端应用调用 Notify往特征值里写 20 字节数据这一帧会经历这些步骤应用层调用写特征值类型是通知Notification。GATT/ATT 层组包生成一个 ATT Handle Value Notification 报文包含属性句柄和数据内容。L2CAP 层给这个 ATT 报文加 4 字节头长度加通道号变成一个 L2CAP 报文。链路层把这个 L2CAP 报文放进发送队列等待下一个 Connection Event。控制器在锚点发出这个包等待对端链路层确认。收到确认后发送队列释放空间应用层的写回调才真正完成。注意第 4 步和第 6 步之间的本质区别写回调返回成功只代表本地协议栈把这个包放进了队列不代表对端收到了更不代表对端应用读到了。对于 Write Without Response 这种无应答写协议栈甚至允许在队列满时直接丢弃数据而不产生任何错误。这就是第一个“看起来发出去了”。4.2 接收侧的自动确认是个独立于应用的流程再看接收侧。对端控制器收到数据后链路层先做 CRC 校验和 MIC 解密然后自动把应答包回给发送方。这个确认动作发生在控制器内部在应用层任何代码运行之前。控制器确认之后数据才沿着链路层、L2CAP、ATT、GATT 逐层往上递交最后触发应用层的特征值变化回调。所以空口抓包看到“对方 ACK 了”只能说明对方的无线电控制器收到了那个包并不能说明对方的 App 已经处理了这个通知。如果对方应用的主线程正卡在别的事务上回调被延迟执行甚至被协议栈合并处理应用层看到的现象就是“丢了”。这是第二个“看起来发出去了”。4.3 四个坑的表格式总结把上面前因后果整理成一个表排查时对照着看会清晰很多。现象真实原因结论写特征值返回成功但对端没反应本地队列接受成功不代表空口发送成功无应答写的成功回调不可靠空口抓包看到包已发出且被 ACK对端控制器收到了但 App 消费速度跟不上ACK 只证明物理层收到了Notification 一条接一条发App 有缺口Notify 没有端到端确认发送方永远不知道对端是否处理需要业务层自行加序号校验写入超过 ATT MTU 的大数据经常失败超过 MTU-3 的 Write Without Response 可能被直接拒绝先协商 MTU再考虑分片策略第三坑尤其值得展开Notify 在 GATT 层没有任何确认机制发送方的协议栈只是把数据交给链路层就不管了。做产品设计时如果业务要求“每条通知必须可靠送达”靠 BLE 原生的 Notification 永远做不到必须在应用数据里加序号、加校验甚至在需要时改用 Indication带确认或者做应用层的重传协议。5. 参数配置实战心率、OTA、低功耗传感器的取舍与算例5.1 吞吐量、延迟与功耗的三条约束参数配置不是拍脑袋而是在三条硬约束里找平衡点。下面的公式很重要理论吞吐量 ≈ 每个连接事件能承载的数据字节数÷ 连接间隔最坏延迟 ≈ 连接间隔 重传次数 × 连接间隔 Slave Latency 跳过的间隔数从机功耗 ≈ 每秒实际参与的事件数 × 单个事件的无线电耗电每秒实际参与的事件数等于 1 除以连接间隔再乘上一个系数如果 Slave Latency 允许从机跳过 5 个事件从机实际参与的事件数大约是每 6 个事件才参与 1 个。这就把三个参数和吞吐、延迟、功耗直接绑定了。调参数本质上就是在这个三角形里选位置。5.2 三种典型场景的参数建议不同业务对三者的权重完全不同先给一个参考表业务场景推荐连接间隔Slave LatencySupervision Timeout其他关键配置实时心率/控制命令7.5ms ~ 30ms0 ~ 21 ~ 2sMTU 23 就够无需 DLEOTA 升级/文件传输7.5ms ~ 15ms01 ~ 2s必须开 DLE协商 MTU 247事件长度拉满电池传感器几分钟上报一次100ms ~ 1s4 ~ 205 ~ 10sMTU 23 够重点是降低事件参与频率心率场景的要点是延迟和抖动每条数据 1 秒一次30ms 间隔能保证最坏延迟只有几十毫秒显示曲线不会一顿一顿的。OTA 场景的要点是吞吐间隔越小、每个事件的包越多吞吐越高同时要注意事件长度设置以及手机侧通常能接受的下限。低功耗传感器场景的要点是省电连接间隔拉到几百毫秒Slave Latency 给到十几甚至几十让从机绝大多数时间深度睡眠但这时 Supervision Timeout 必须记得按第二节的公式重新核算否则会出现“睡过头被判定掉线”的奇葩事故。5.3 一个具体算例50kB/s 的 OTA 目标和 20 字节心率的对比先说 OTA。假设你要求下载速度达到 50kB/sMTU 协商到 247一条 Notification 的应用程序负载最多是 MTU 减 3 字节也就是 244 字节。50kB/s 换算成每秒包数就是 51200 ÷ 244约等于 210 包每秒。如果连接间隔 15ms每秒有约 66.7 个事件那么每个事件必须塞下约 3.15 个包。一个 251 字节的链路层包在 1M PHY 下空口大约要 2ms加上确认往返一个包大约占 2.4ms4 个包约 9.6ms离 15ms 还有富余所以理论上可行。换成 2M PHY 会更轻松。这个算例的过程本身就是排查吞吐不足问题的标准方法把目标字节数除以单包负载得到包率再除每秒事件数看每个事件需要几包然后看事件长度够不够。再看心率。20 字节加上 ATT 头、L2CAP 头、链路层头总共不到 30 字节1M PHY 下空口只要 0.3ms 左右。哪怕连接间隔 100ms一个事件也绰绰有余。这时决定功耗的不是数据量而是唤醒次数。所以对这种业务间隔选 30ms 还是 100ms 差别很大选 7.5ms 则纯粹是浪费电池。5.4 为什么不要迷信“最小化”把连接间隔调到极限的 7.5ms 并不总是好事。除了功耗暴涨它还会带来两个容易被忽视的问题一是与同芯片上其他射频任务广播、扫描的调度冲突概率增大二是手机端主控如果同时连接多个外设7.5ms 的密集锚点会让调度变得非常紧张一旦错过锚点效果反而比 15ms 更差。经验上能不用 7.5ms 就不要用15ms 到 30ms 之间通常是延迟、功耗、可靠性的甜点区。6. 应用层丢帧排查从抓包到协议栈统计的完整路线6.1 先把“丢”的定义定清楚排查丢帧的第一步不是看日志而是统一口径。所谓“丢帧”至少有三种完全不同的情况第一种是数据真的没到比如序号有缺口第二种是数据到了但晚了比如 RSSI 差导致重传风暴App 按照自己的超时逻辑把迟到的数据当成无效第三种是数据全到了但被覆盖了比如 App 回调里只保存“最新值”两帧之间的中间值根本没被读取。我强烈建议所有涉及 BLE 数据的业务从第一天起就在负载里加一个自增序号。有了序号丢还是没丢、丢在哪一段一目了然。没有序号所有的“好像少了”都只能靠猜排查效率至少低一半。6.2 按“信息量最大”排序的排查步骤真按顺序来我建议这样做抓空口。用 BLE 嗅探器在发送端和接收端附近抓包。先看发送端是否每个事件都把数据包发出来了对端链路层是否 ACK 了再看重传次数和 Supervision Timeout 事件。如果空口一切正常问题大概率在上层。打印实际协商参数。把连接间隔、Slave Latency、Supervision Timeout、MTU、事件长度全部打出来和你预期的对比。这里经常会发现“我设了 7.5ms实际是 30ms”。统计协议栈内部事件。CRC 错误计数、错过锚点的次数、发送队列溢出次数、接收丢包计数。这些数据在多数协议栈里都有接口只是很多人从来不看。最小化复现。关掉其他设备固定单连接、固定间隔、固定负载跑 30 分钟。如果只在这种条件下复现那多半是射频共存或者并发连接调度的问题。应用层对照日志。接收端把每条通知的到达时间和序号记录下来和发送端的日志对齐时间轴。6.3 三个经典“伪丢帧”原因排到最后你会发现很多“丢帧”根本不是空口丢的而是这三个经典原因之一。一MTU 没有协商。默认 ATT MTU 只有 23 字节应用负载一次最多 20 字节。你要写个 200 字节的数据就得拆成 10 个包排队排到天荒地老队列一满就丢。很多人把 MTU 协商漏了然后被“大数据传输丢帧”折磨一星期。二事件长度被限制。前面说过连接间隔和事件长度是两回事。控制器默认的事件长度往往很短导致每个事件只能发一两包。症状是明明间隔调得很小吞吐却上不去数据在队列里堆积超时被丢。三单芯片多角色共用无线电。外设同时在跑广播和连接或者在做周期性扫描而芯片只有一个射频前端。扫描窗口或广播事件一旦和连接锚点冲突连接事件就被缩短甚至错过。表现常常是周期性的丢帧缺口——观察抓包时间轴几乎每个缺口都能对应上广播或扫描的活动。这种问题不是调链路参数能解决的而是要安排射频任务的时序让它们避开连接事件。手机端多个连接并存时也有类似的调度问题只是你只能通过调小或者调大间隔来给主控留出调度余量。6.4 一张症状对照表症状优先排查方向通知序号有缺口空口抓包 对端应用消费速度写入大数据频繁失败或丢包MTU 未协商、事件长度不足、发送队列溢出丢包呈现周期性同芯片广播/扫描共存、主控多连接调度偶发断连Supervision Timeout 配置、2.4GHz WiFi 干扰、天线匹配说实话调 BLE 链路参数这几年我踩过最大的坑就是当初把 7.5ms 当成万能药一遇到丢帧就往上调结果问题没解决功耗还翻了一倍。现在我的做法是新项目第一天就在固件里把实际协商出的连接间隔、MTU、重传计数打成一条 debug 日志出问题先看这条日志。很多所谓“丢帧”查到最后根本不是无线空口的问题而是协议栈配置、队列深度和应用消费速度的问题。把这个思路捋顺了BLE 那些看似玄学的现象其实大多都能在三十分钟内定位到具体那一层。