蓝牙 6.0 信道探测技术：厘米级定位如何改变 IoT 场景

为什么蓝牙定位一直差口气

很多做 IoT 的团队都有过这种体验：用蓝牙做设备定位，论覆盖和成本都挺合适，但一到精度层面就“尽力而为”。TDOA 做到两三米，RSSI 做指纹能到两米就不错，AOA 在某些限定环境下可以到半米，但受天线阵列和部署环境影响很明显。真正到数字钥匙、仓储盘点、机器人对接这类需要分米甚至厘米级判断的场景，蓝牙往往被直接跳过，换成 UWB。

蓝牙 6.0 最让我关注的，不是又多了一个会话层协议，也不是传输速率的变化，而是把信道探测（Channel Sounding）作为核心能力放了进来。这意味着蓝牙第一次有机会，在普通 BLE 硬件基础上实现厘米级测距。它不是去替代 UWB 的所有战场，而是把一批原来只能靠 UWB 高成本方案才能解决的 IoT 问题，拉回到蓝牙的生态里。

要理解这种变化，得先看看过去的蓝牙测距为什么上不去。

从 RSSI 到 AOA，蓝牙测距的真实瓶颈

蓝牙测距这么多年，主要手段就是两类。一类是基于接收信号强度（RSSI）的衰减模型，另一类是根据到达角（AOA）计算相对方位。RSSI 的问题在于反射和多径会让信号叠加，同一个位置走两步，强度可能差出 6dB，对应距离误差能到两三米。关键是这个误差不是随机波动，而是和环境强相关，很难通过滤波完全消除。AOA 靠切换天线阵列的相位差估算角度，角度有了再结合多基站交会定位。方案确实比 RSSI 稳，但硬件上要多天线和射频开关，成本上去了，视野范围也有限，还需要提前标定。

真正麻烦的地方在于，这些方法都是在已知的信号属性里做推断，没有去主动测量信号在空中的飞行过程。蓝牙 6.0 的信道探测换了一条思路：它同时测量信号的往返时间和频率相位，把测距从“猜强度算距离”变成了“测量时间加相位”。这就是行业里常说的 Channel Sounding，也叫“基于相位测距（PBR）与往返时间（RTT）的混合方案”。

信道探测的核心机制：相位差与往返时间

先理解一个基本事实：无线电波在空气中速度恒定，如果能测出信号从 A 到 B 再回到 A 的时间差，距离就是时间差乘以光速再除以二。这个原理任何射频技术都能用，难点在于蓝牙的带宽太窄，没有 UWB 那种窄脉冲，时间分辨率不够。BLE 越窄的带宽，抗噪能力越弱，直接测 TOF 精度可能只有几米。

于是蓝牙 6.0 用了另一种手段——相位测距。它在多个不同的 RF 频率上交替发送信号，接收方测量每个频率下信号的相位变化。距离变化一个波长，相位就会变化 2π。通过多个频率的相位差，就可以解算出完整的距离值。这个方案对天线设计的要求比 UWB 低，不需要专门的脉冲收发电路，用普通 BLE 射频就能实现。

工程上不是直接用单一相位差，而是结合 RTT 做模糊度消解。因为相位测量有 2π 周期模糊问题——当距离超过一个波长时，你得知道它到底绕了多少圈。蓝牙 6.0 的机制是先用 RTT 得到一个粗糙的距离估值，再用多频率相位差在这个粗糙范围内精化，最终达到亚米级甚至厘米级。这个过程在协议里是自动完成的，对外表现为一次测距事件。

为了理解这种组合，可以看一个简化的伪代码流程：

// 蓝牙 6.0 信道探测测距流程（示意）
function measureDistance(initiator, reflector):
    # 阶段1: 初步往返时间测量，获得粗距离
    t0 = sendPacket(initiator, reflector)
    t1 = receiveAck(reflector)
    coarseDistance = ((t1 - t0) * c) / 2

    # 阶段2: 多频率相位步进扫描
    phaseOffsets = []
    for f in [2.402GHz, 2.408GHz, ... 2.480GHz]:
        phase = measurePhase(f, reflector)
        phaseOffsets.append(phase)

    # 阶段3: 用相位差精化距离
    fineDistance = resolvePhaseAmbiguity(phaseOffsets, coarseDistance)
    return fineDistance

看清楚，这不是某个厂商的私有协议，而是蓝牙 SIG 在 6.0 里定义的一套标准测距流程。它最大的价值在于，任何时候两个蓝牙设备只要都支持 Bluetooth 6.0，就能直接测距，不需要额外硬件。

对比：蓝牙 6.0 信道探测到底强在哪

很多人会拿蓝牙 6.0 和 UWB 比较，尤其是 UWB 已经先行一步做数字钥匙。从技术指标上，UWB 能在更复杂的多径环境下保持厘米级精度，但成本、功耗和天线面积都更高。蓝牙 6.0 的信道探测在开阔视距环境下可以达到类似效果，在非视距环境下精度会劣化，但优于 RSSI。它更适合那些对功耗和成本敏感、且不要求极端多径抗干扰的 IoT 场景。

这张表不是让你直接选中归哪一行，而是告诉你要看约束条件。如果你的设备是挂牌资产，距离精度要求 10 厘米，周围环境又不算特别杂乱，蓝牙 6.0 很有可能是最省成本的解法；但如果要开车门，车辆周围各种金属遮挡，还是 UWB 更稳。

IoT 场景里真正会被改变的几个地方

厘米级定位能力放进蓝牙以后，最先受益的往往不是那些做高精度地图的，而是做设备间相对位置判断的场景。

最典型的是数字钥匙。以前手机靠近车门，用 RSSI 判断距离，可能 1 米和 3 米区分不够灵敏，就会出现站在车边还没解锁的尴尬。蓝牙 6.0 信道探测能在手机与车机间做精确距离测量，配合安全机制，只有真正贴近驾驶位才解锁。当然车厂可能会继续用 UWB 做最高安全级，但蓝牙信道探测可以作为中低配车型的降本方案。

另一个变化是资产追踪。仓库里每件货品贴一个 UWB 标签成本太高，但普通 BLE Beacon 精度又太差。蓝牙 6.0 给了中间选项：定位基站和标签都支持信道探测时，盘点人员拿着手持终端走过货架，就能准确知道货品在哪一排甚至哪个位置。这种场景中，多径干扰不如室外复杂，厘米级精度基本够用。

智能家居的场景更有意思。比如智能音箱判断用户坐在沙发上而不是站在门口，才能决定要不要开启近场交互。传统 PIR 传感器只能感知活动，蓝牙信道探测可以给出设备间的近似距离，配合加速度计做态势判断。调光、锁屏、消息推送这些操作都可以因为距离判断的精确化而变得更智能。

还有一个常被忽略的领域是工厂的机械互锁。两台 AGV 相遇时精确到 30 厘米的安全距离，以前要么用红外、要么用 UWB，现在两个普通 BLE 模块就能承担这个角色。当然，涉及人身安全的主功能不能全依赖单一测距，但它可以作为冗余传感器参与避障逻辑。

落地时真正要注意的四个坑

虽然蓝牙 6.0 信道探测的门槛看起来低，但它不是随便拿两个 BLE 模块就能跑出厘米级精度。工程落地时这些问题很容易被忽略。

第一，天线设计和布局直接影响相位稳定性。信道探测依赖相位测量，如果天线附近有金属螺丝、主板走线或塑胶外壳，都会让相位发生非线性偏移。手机厂商能调好，是因为有大团队专门校准；IoT 厂商如果沿用旧款 PCB 天线，测出来的距离曲线可能很怪异。

第二，多径是精度最大的敌人。信道探测在无遮挡环境下表现很好，但一旦进入满是金属货架、机械手臂的工厂，反射信号会和直射信号叠加，相位差解算会出现偏差。这时可以通过多次测量和算法滤波补救，但实时性会下降。如果业务要求每一帧都是稳定高精度，可能必须上 UWB。

第三，功耗比想象中高。完成一次信道探测需要收发多个频率的相位测量，比普通 BLE 广播耗电得多。如果标签是由纽扣电池供电，并且每秒钟测一次距，电池寿命可能不到三个月。设计时得考虑测距频次和协议缓存的折中。

第四，兼容性不是“所有蓝牙 6.0 设备都能互通”。信道探测支持多种模式，有的设备只实现了 RTT，没实现 PBR，或者只有单频段相位测量，精度就大打折扣。采购芯片和模组时，要明确是否支持完整的信道探测特性组合。

怎么开始落地？从选型和验证起步

如果你的团队正在评估是否采用蓝牙 6.0 信道探测，我建议不要一开始就铺大规模方案。先做小范围验证，重点关注几个关键指标：

• 在自己真实的环境里测量距离误差分布，至少要统计 90% 和 95% 置信区间。
• 测不同朝向和角度的表现，因为天线极化会产生盲区。
• 验证测距率与功耗的平衡，确定业务上可接受的最低测距频率。
• 检查是否有需要非视距（NLOS）场景，提前规划额外的检测逻辑。

硬件上优先选择已经通过蓝牙 6.0 认证、且提供成熟 SDK 的模组厂商。目前主流芯片厂商都在跟进，但底层算法（如相位噪声补偿、多径抑制）很多是闭源实现的，不同模组的实际效果差异很大。你需要测，而不是只看宣传页。

软件层面，测距结果通常以“距离+置信度”的形式上报。业务系统不要直接拿原始距离当绝对真值，可以设计简单的状态判断：比如连续三帧都在 1 米内才触发解锁，超过 5 米再重置。这样能过滤掉偶发的跳变噪声。

如果将来要和 UWB 共存，你还可以把蓝牙信道探测作为 UWB 的辅助唤醒。平时用 BLE 低功耗待机，当距离进入一定范围后，再唤醒 UWB 做高精度确认。这样既省电，又能获得更高安全性的测距结果。

不是替代 UWB，而是把蓝牙的边界往前推了一大步

蓝牙 6.0 信道探测技术不会让 UWB 消失，但它会让很多原本必须用 UWB 的轻量场景有更便宜的选择。IoT 行业的本质是成本、功耗、精度的三元平衡，以前三角坐标里靠近蓝牙的位置只能做到米级，现在有了厘米级的可能，整个系统的设计空间一下子大了很多。

真正要关注的不是“蓝牙能不能比过 UWB”，而是你的业务里那些因为精度不够没能用蓝牙解决的问题，哪些现在可以重新拿回来了。这就是协议演进最实际的价值，它不追逐极限，但总能把某些能力下沉到普及层。