蓝牙只是 2.4GHz ISM 频段上的一种协议。无线时间同步的底层方案分三大类：BLE 标准协议、2.4GHz 私有协议、应用层软件方案。本文把三类方案放在一起梳理，核心结论一句话：同步精度取决于在协议栈哪一层拿时间戳。

BLE 基础

协议栈分层

┌─────────────────────────┐
│  Host（主机）            │  主 CPU 上跑（Linux/RTOS）
│  - GAP/GATT 应用层       │
│  - L2CAP                 │
├─────────────────────────┤
│  HCI（UART/SPI/USB）    │
├─────────────────────────┤
│  Controller（控制器）    │  蓝牙芯片自己的 MCU
│  - Link Layer 链路层     │  管理连接事件、时序、跳频
│  - Physical Layer 物理层 │  射频收发
└─────────────────────────┘

• HCI 是通用架构模式（Host Controller Interface），非蓝牙专有。USB 的 UHCI/OHCI/EHCI/xHCI、SATA 的 AHCI、SD 卡的 SDHCI 都是同一模式
• BLE 的 HCI 是蓝牙核心规范里的标准协议，跨厂商互通

ACL vs ISO（两种数据传输模式）

连接事件

BLE 连接的核心：主设备和从设备约定每隔 Connection Interval（最小 7.5ms）碰面一次。主设备发起、从设备响应。

• Connection Interval：7.5ms ~ 4s
• Slave Latency：从设备可跳过次数（省电）
• Supervision Timeout：连续无响应则断连
• 从第一个连接事件起，Event Counter 从 0 递增

配对 vs 连接 vs 绑定

• 连接：物理通道建立
• 配对：身份认证 + 密钥协商（LE Secure Connections 三步：能力交换→密钥协商→密钥分发）
• 绑定：密钥持久化，下次自动重连

四种认证方式（根据双方 I/O 能力自动选择）：

五套时间同步方案

应用层（Host软件）    ← 方案一        毫秒级~亚毫秒，不稳定
链路层（Controller）   ← 方案二/三/四   百微秒~毫秒，稳定
物理层（RF寄存器）     ← 方案五        亚微秒，需定制

方案一：应用层时间戳交换

• 原理：Host 侧 send()/recv() 打时间戳 T1~T4，Cristian 算法：Δ = ((T2-T1)+(T3-T4))/2
• 精度：亚毫秒数毫秒，不稳定。实验室最优 TI 平台 69±71μs、Nordic 477±490μs；实际有传输阻塞时跳变到连接间隔量级（1015ms）
• 根因：T1~T4 含 Host 协议栈、HCI 传输、Controller 排队等所有延迟，Cristian 假设对称延迟在 BLE 不成立
• 芯片：任何 BLE 芯片
• 适用：控制指令同步、状态轮询

方案二：链路层连接事件同步

• 原理：连接事件 = 中断，双方 Controller 各自在同一连接事件（Event Counter）打时间戳，交换后算偏移。不传时间值，传"第几次碰面"
• 精度：纯 BLE 场景百微秒级。资料标 1~10ms 是 CCC 的 BLE→UWB 映射场景（有插值误差），纯 BLE 下精度取决于 Controller 中断抖动而非连接间隔
• 芯片：任意 BLE 芯片，但需 SDK 暴露连接事件回调 + Controller 时钟
• 适用：需要稳定亚毫秒同步的场景

方案三：ISO 等时通道

• 原理：BLE 5.2 新增等时传输模式，ISO Interval + Subevent 结构。Controller 在收发每个子事件时自动记录精确时间戳，同一 CIG 内所有设备自动对齐
• 精度：微秒级（BlueKitchen 实测 13μs）
• 芯片：BLE 5.2+
• 关键：Host 零代码，Controller 闭环。方案二的高频标准版
• 注意：ISO ≠ 经典蓝牙音频。市面上大多数 TWS 仍是 BR/EDR + 私有转发，LE Audio/ISO 是未来方向

方案四：PAwR 周期性广播响应

• 原理：不建连接，广播者周期广播，监听者分时响应。子事件序号 = 时间刻度。BLE 5.4 引入
• 精度：毫秒级。Subevent Interval 7.5ms~318.75ms，广播周期最大约 82s
• 精度不如方案二的原因：广播单向，无连接事件那种双向闭环确认
• 芯片：BLE 5.4+
• 适用：电子货架标签、工业物联网——一对多、低功耗优先

方案五：物理层直接捕获

• 原理：绕过所有协议栈，直接读射频芯片物理层寄存器，RX/TX 完成中断打时间戳
• 精度：亚微秒级（ETH Zurich 实现标准差 112ns）
• 芯片：特定芯片 + 定制开发
• 特点：非标准，实现复杂度高
• 适用：精密测距、工业测量专用设备

方案对比

三个容易踩的坑：

1. 方案二的精度要区分场景：资料标 1~10ms 是 BLE→UWB 映射场景（有插值误差），纯 BLE 同步可到百微秒级
2. ISO 通道 ≠ 支持蓝牙音频：ISO 是 BLE 5.2 特性，需要 LE Audio；市面上绝大多数 TWS 是经典蓝牙 + 私有转发
3. PAwR 精度不如方案二不是因为打不了时间戳，而是广播是单向的，没有连接事件那种双向闭环确认

2.4GHz 私有协议

核心概念

“蓝牙"是 Bluetooth SIG 定义的完整协议栈（PHY → Link Layer → L2CAP → GATT），而非 2.4GHz 频率本身。同一频段可以跑完全不同协议栈的无线电：

2.400 - 2.4835 GHz ISM 频段（全球免许可）

  ┌────────┬─────────┬────────┬──────────┬─────────┐
  │  WiFi  │ 蓝牙    │Zigbee  │  Thread  │ 私有协议 │
  │802.11  │BLE/BR   │802.15.4│ 802.15.4 │ 你自己定 │
  ├────────┼─────────┼────────┼──────────┼─────────┤
  │ 信道宽 │ 信道窄  │ 5MHz   │ 5MHz     │ 随意    │
  │ 22MHz  │ 2MHz    │        │          │         │
  ├────────┼─────────┼────────┼──────────┼─────────┤
  │ 高速率 │ 低功耗  │ 低功耗 │ 低功耗   │ 全自由  │
  └────────┴─────────┴────────┴──────────┴─────────┘

没有"蓝牙私有协议"这种说法。 要么走蓝牙 SIG 规范（叫蓝牙），要么自定义链路层（叫私有 2.4GHz 协议）。

Nordic 2.4GHz 私有协议：ESB 与 Gazell

Nordic 官方提供两套私有协议（nRF51/nRF52/nRF53 全系列支持，nRF54 支持 4Mbps 高速模式）：

ESB（Enhanced ShockBurst）：轻量、高速、无连接间隔，适合高精度时间戳广播。发包延迟 ~200µs，配合 PPI 硬件触发达到 <16ns 抖动。

Gazell：ESB 的升级版，增加跳频（抗干扰）、配对（安全）、同步通信模式、星形网络拓扑。架构分两层：

• Gazell Link Layer：负责底层的包收发、时序管理、自动应答
• Gazell Pairing：可选的上层，提供安全配对和加密

Gazell 的实际定位：VR/AR 手柄的"标准答案”

Nordic 官方 VR/AR 应用页面明确写道：“In VR and AR, proprietary 2.4GHz is best”。Gazell 在 VR/AR 手柄中的关键优势：

• 报告率高达 8K（8000Hz），远超 BLE 的 1000Hz（LLPM 模式）
• 实现 “seamless synchronization across devices”
• nRF Desktop 参考设计是 VR/AR 应用的起点，提供完整 ANSI C 源码
• nRF54 系列支持 4Mbps 射频模式，进一步提升手柄数据上报能力

Gazell 也是无线键鼠的成熟方案：nRFready Desktop 2 参考设计明确支持 BLE + Gazell 双模——键盘/鼠标可以通过 BLE 连接电脑，同时通过 Gazell 连接 USB Dongle 获得低延迟体验。

同步通信模式的意义

Gazell 的"同步通信：是"意味着主机和从机在精确的时间窗口交替收发。这与 BLE 连接事件类似，但没有 BLE 协议栈的开销和 7.5ms 最小连接间隔限制。对于时间同步场景，Gazell 的同步通信模式天然适合——可以在固定周期内发送时间码广播帧，所有从设备在同一窗口收到，配合 PPI 硬件触发获得微秒级对齐。

协议并发：Timeslot API

同一颗 nRF52840 可同时跑 BLE + Gazell/ESB，SoftDevice 自动调度射频时间片：

  ┌──────┬──────┬──────┬──────┬──────┬──────┐
  │ ESB  │ BLE  │ ESB  │ BLE  │ ESB  │ BLE  │
  │私有  │ 连接 │私有  │ 连接 │私有  │ 连接 │
  └──────┴──────┴──────┴──────┴──────┴──────┘
  ├─1ms ─┤├─2ms ─┤├─1ms ─┤├─2ms ─┤├─1ms ─┤

这是影视时码器 Deity TC-1 最可能的底层：BLE 给手机 App 控制，ESB 给时码器间 30ft 范围高精度 Jam Sync。

精度链（以 nRF52840 ESB 为例）

[主设备 TX]
定时器触发 → 射频发射 → 空中传播 → 射频接收 → 引脚中断
└── 0µs ──┘└─ ~100µs ─┘└─ 3µs/m ─┘└─ ~100µs ─┘└── ~5µs ──┘

总单向延迟：~200µs（30m距离）
NTP 式往返测延迟补偿后 → 理论对齐精度：< 10µs

影视无线时码器

SMPTE LTC（线性时间码）

影视行业标准，把时间码（时:分:秒:帧）编码为音频信号，通过 3.5mm 音频口注入摄影机/录音机：

• 编码：曼彻斯特码（二进制调频），比特率约 2.4 kbps
• 格式：每帧 80 bit，最低有效位在前
• 后期软件（DaVinci Resolve、Premiere）自动识别音轨中的 LTC

Jam Sync 模型

和 BLE ISO/CIG 的持续等时同步本质不同：

• 一次对齐 + 各自 TCXO 守时，而非持续握手
• 早上开机对齐一次，全天靠 TCXO 独立跑
• 无线连接只在偶尔对齐时用，对齐精度不是主导指标
• TCXO 精度（±0.1~0.5 ppm）决定最终漂移量

产品精度对比

时码器精度由 TCXO 守时主导。对齐精度 50ms vs 200µs 的差异在一天的 TCXO 漂移（~40ms）面前不是瓶颈。

Jam Sync 对齐方式

BLE ISO/CIG vs 私有 2.4GHz vs 时码器