【从零开始】手写BLE协议栈(2-2)T_IFS:为什么是150 µs

150 µs 的物理账单:T_IFS 与帧间精确计时

前提知识

阅读本文需要具备以下基础:

  • 理解 BLE 广播与主动扫描流程(1-2 篇和 2-1 篇有详细讲解):T_IFS 适用于所有有"问答"结构的 BLE 帧间交互——ADV_IND→SCAN_REQ→SCAN_RSP 是最直观的场景。理解三包握手才能直观感受"为什么必须在 150 µs 内回包"。
  • 理解 RADIO 状态机(1-1 有详细讲解):T_IFS 的本质是从 RX 切换到 TX(或反向)所需时间的上界。不理解 TXRU / RXRU(Ramp-Up)阶段就无法理解 40 µs 补偿数字的来源。

不需要提前了解 PPI 或 TIMER 外设——T_IFS 的概念本身与具体实现方式无关。具体实现(HW TIFS 和 SW TIFS)在 2-3 篇展开。


一、T_IFS:有"问答"的地方就有这条规则

BLE 的物理层是半双工的——一根天线不能同时发送和接收。当甲刚发完一帧,乙还没开始回应的这段空白时间,就叫做帧间间隔。你可能会想:帧间间隔越短越好,节省空口时间。BLE 规范的答案是:是的,但不能无限短。BLE Core Spec(Vol 6, Part B, Section 4.2.1)对这张账单给出了精准定义:

在任何需要"应答"的链路层交互中,回包方必须在上一帧最后一个 bit 结束后,恰好 150 µs ±2 µs 内发出回包的第一个 bit。

这条规则叫做 T_IFS(Inter-Frame Space,帧间间隔),适用于 BLE 链路层所有的应答式交互场景:

  • 扫描器收完 ADV_IND → 150 µs 后发出 SCAN_REQ 第一个 bit
  • 广播者收完 SCAN_REQ → 150 µs 后发出 SCAN_RSP 第一个 bit
  • 连接中主设备发完数据包 → 从设备 150 µs 后发出应答包
  • 连接中从设备发完数据包 → 主设备 150 µs 后发出应答包

image

"恰好"这两个字很关键。 T_IFS 不是"不超过 150 µs",而是精确等于 150 µs ±2 µs。太早不行,太晚也不行——接收方是在预设位置开了一扇宽度只有 2 µs 的窗户在等,早了还没开,晚了已经关了。


二、±2 µs:为什么窗口这么窄?

2 µs 的容忍范围是这样算出来的。

BLE 1M PHY 的空口数据速率是 1 Mbps,意味着每 1 µs 正好传输 1 bit。如果回包的第一个 bit 比预期晚了 3 µs,接收方的同步检测逻辑里就会有 3 个 bit 的错位——前导码(Preamble)的同步窗口就此失效,整包数据无法被正确解码,彻底丢失。

从接收方的角度倒推:它只能把等待窗口开得稍微宽一丁点(各允许 ±1 µs),因为再宽一点,偶发的空口噪声就可能被误认为是合法回包的开头,误判率急剧上升。出于信噪比的权衡,±2 µs(即各自向前向后各 1 µs)是 BLE 规范选定的折中点。

这个容忍范围意味着:回包方的计时精度必须优于 2 µs 的误差。换算成等效采样频率,至少需要 500 kHz 量级的精度——每 2 µs 最多只能差一个 tick。


三、为什么是 150 us

150 µs 不是工程师拍脑袋定的。从收到上一帧的最后一个 bit,到发出回帧的第一个 bit,芯片内部有一系列硬件阶段必须依次完成。下面的分解展示的是各阶段的最大耗时预算,而非实际执行的先后顺序——真实芯片在实现层面会重排和流水线化这些步骤。

image

  • T = 0 µs,上一帧最后一个 bit 到达(RADIO EVENTS_END 触发)
  • T < 5 µs,射频前端切换:天线路径从 RX 通道倒换到 TX 通道
  • T < 20 µs 基带处理:
    • 完成 CRC 校验(循环冗余校验,判断收包是否有效)
    • 解白化(Dewhitening)
    • 确认 PDU 类型合法性
  • T ≈ 40 µs, PLL 重新锁定(TX Ramp-Up):射频发送频率与接收频率虽然在同一信道,但 PLL 需要从"收"模式重新切换到"发"模式,锁相环需要重新稳定到目标频率,约需 40 µs
  • T = 150 µs,TX 第一个 bit 出现在天线口

其中最耗时的是 PLL 重新锁定。PLL(Phase-Locked Loop,锁相环)是将 16 MHz 参考晶振倍频到 2.4 GHz 射频载频的电路。每次射频模式切换,PLL 都要重新"咬住"目标频率——nRF52 芯片规格书(nRF52832 PS, Section 6.20.15.7)标注的 TX Ramp-Up 时间约为 40 µs

把这些阶段加在一起,nRF52 的硬件流水线大约需要 ~65 µs。但 150 µs 是 BLE 规范选定的值,它必须覆盖所有合规芯片——不同厂商的 PLL 锁定时间差异很大(有些可达 80~100 µs),还需要为固件处理(地址校验、缓冲区切换)预留余量。


本系列教程同款硬件:👇
芯片: nRF 52832 开发板
工具: nRF 52840 BLE Dongle 蓝牙嗅探器
工具: 逻辑分析仪
工具: BPA low energy 蓝牙分析仪

posted @ 2026-03-28 10:14  ixbwer  阅读(9)  评论(0)    收藏  举报