★ FEATURED ARTICLE 一个做资产追踪标签的团队遇到过这样一件事。标签固件烧录完毕功耗测试过了广播内容用嗅探工具抓包也正常RSSI 在预期范围内。但配套的接收端在实验室里就是扫不到这批标签。换一台接收端能扫到。再换回来又扫不到。标签和接收端都是同一版硬件、同一版固件差别只在个体。团队一开始怀疑天线一致性把标签拆开测了匹配网络没发现问题。又怀疑接收端灵敏度用信号源打了一个已知强度的广播包接收端能正常解调。问题卡了两天最后发现是广播间隔参数和接收端扫描窗口参数在时域上形成了稳定错配——两者各自都合规合在一起就互相躲开了。这个坑值得单独拎出来讲因为公开资料里通常只告诉你广播间隔有哪些档位、扫描窗口和扫描间隔怎么配但很少讲它们在时间轴上撞车之后会发生什么以及现场怎么判断是不是撞车了。先看现象不是扫不到是“有时候扫不到”这类问题的典型表现很有辨识度。用两个接收端同时扫同一批标签一个能扫到大部分一个只能扫到零星几个。把扫不到的接收端拿到离标签更近的位置还是扫不到。抓包工具挂在旁边能看到标签确实在广播广播内容也没问题。接收端自己的日志显示扫描已经启动没有任何报错。更迷惑的是如果你把标签断电再上电有时候接收端立刻就能扫到但过一段时间又扫不到了。或者把接收端重启能扫到几秒钟然后标签从列表里消失。这种“短暂可见、随后消失”的模式基本可以把射频链路和协议栈初始化的问题排除掉方向应该往时间调度上收。这里要区分两种“不可见”。一种是接收端完全扫不到任何广播连抓包工具也看不到那是发射端没工作。另一种是抓包工具能看到广播接收端扫不到那是接收端的扫描调度和广播时刻没有重叠。本文讲的是后一种。广播和扫描在时间轴上是怎么互相找的广播端的行为是周期性的。它在一个广播事件里依次在三个广播信道37、38、39上各发一个包包与包之间有一个很小的间隔通常几十到几百微秒量级由协议规定。三个信道发完这个广播事件结束。然后广播端休眠一段时间等到下一个广播事件再重复。两个广播事件起点之间的时间差就是广播间隔。扫描端的行为也是周期性的。它在一个扫描窗口内打开接收机在三个广播信道上轮流监听。扫描窗口结束后接收机关闭休眠一段时间再打开下一个扫描窗口。两个扫描窗口起点之间的时间差是扫描间隔。扫描间隔必须大于等于扫描窗口否则接收机没有休息时间。接收端要扫到一个广播包需要满足一个条件广播包落在某个扫描窗口内并且落在正确的信道上。注意这里有两个维度——时间维度和信道维度。信道维度的问题通常表现为扫到概率低但不为零时间维度错配则可能表现为完全扫不到或者呈现周期性时有时无。错配是怎么形成的假设广播间隔是 T_adv扫描间隔是 T_scan扫描窗口是 W_scan。如果 T_adv 和 T_scan 之间存在一个简单整数比而且相位差恰好让广播事件总是落在扫描窗口之外就会出现稳定错配。举个具体数字。广播间隔设为 1 秒扫描间隔也设为 1 秒扫描窗口设为 100 毫秒。如果广播事件总是发生在扫描窗口关闭的那 900 毫秒里接收端就永远扫不到。而且因为两个周期相同这个相位关系不会漂移错配会一直保持下去。如果两个周期不是整数比比如广播间隔 1 秒、扫描间隔 1.1 秒相位会缓慢漂移接收端会呈现“隔一段时间能扫到一次”的模式。这种反而容易排查因为现象是间歇性的不像完全扫不到那么让人怀疑硬件。真正阴险的是周期相同或成整数倍、且相位固定错开的情况。两个设备各自跑自己的时钟晶振频差会让相位缓慢漂移但漂移速度可能非常慢。如果晶振精度是 ±20 ppm1 秒周期下每秒漂移 20 微秒要漂过 900 毫秒的盲区需要几万秒。在现场调试的几分钟里你看到的就是“完全扫不到”。为什么参数各自都是合规的广播间隔的取值通常有协议规定的档位比如 20 毫秒到 10.24 秒之间若干离散值。扫描间隔和扫描窗口也有各自的取值范围和约束。单独看每一个参数都落在允许范围内协议栈不会报错编译也能过。问题出在组合上。协议规范通常不会规定“广播间隔和扫描间隔不能成整数比”因为这属于实现层面的调度问题不是协议合规性问题。芯片厂家的协议栈也不会主动帮你检测这种错配它只负责按你给的参数去调度。还有一个容易被忽略的点广播端的实际广播间隔不一定等于你配置的值。协议栈在两次广播之间可能插入随机延迟目的是避免多个设备长期碰撞。这个随机延迟通常是几毫秒量级。如果扫描窗口很窄比如 10 毫秒这个随机延迟就足以让广播包在扫描窗口边缘反复进出表现为扫到概率忽高忽低。如果扫描窗口是 100 毫秒几毫秒的随机延迟影响不大。所以窄扫描窗口对广播端的调度抖动更敏感。现场怎么判断是不是错配第一步先确认广播端确实在发。用抓包工具在标签附近抓一段时间看广播包的时间戳间隔是否稳定是否等于配置的广播间隔。如果抓包工具能看到包接收端看不到基本可以排除发射端问题。第二步把接收端的扫描日志打开。很多协议栈支持输出扫描窗口的起止时间戳。如果拿不到这么细的日志可以退而求其次在接收端固件里加一个计数器记录每次扫描窗口内收到的广播包数量。如果计数器长期为零说明时间维度上没有重叠。第三步做一个简单的交叉验证把广播间隔改成一个和扫描间隔不成整数比的值比如原来两边都是 1 秒把广播间隔改成 1.3 秒。如果接收端立刻能扫到了那基本可以确认是周期错配。这个验证动作很快但能省掉大量怀疑天线和灵敏度的时间。第四步如果不想改广播端也可以改扫描端。把扫描窗口从 100 毫秒加宽到 200 毫秒或者把扫描间隔改成一个和广播间隔不成整数比的值。如果问题消失同样指向错配。这里有一个取舍加宽扫描窗口能提高扫到概率但接收端功耗会上升。对于电池供电的接收端扫描窗口和扫描间隔的乘积占比直接决定平均功耗。所以现场往往不能简单地把窗口拉到很大而是要在功耗和可见性之间找平衡。一个常用的做法是让扫描间隔略小于广播间隔并且两者不成整数比这样每个广播周期内至少有一次扫描窗口能覆盖到广播事件同时平均功耗可控。一个容易踩的隐形陷阱广播信道轮转和扫描信道轮转的相位除了时间维度信道维度也有相位问题。广播端在一个广播事件里依次在 37、38、39 三个信道上发。扫描端在一个扫描窗口里依次在 37、38、39 三个信道上听。如果扫描窗口很短短到只能覆盖一个信道那么扫描端在每个窗口里只监听一个信道。如果广播端的信道轮转顺序和扫描端的信道轮转顺序恰好错开比如广播端在 37 信道发的时候扫描端在听 38广播端在 38 发的时候扫描端在听 39就会一直错开。这种情况在扫描窗口小于单个信道监听时间时尤其容易出现。协议栈通常会在扫描窗口内尽快轮转三个信道但如果窗口太窄可能只够听一个信道。此时如果广播间隔和扫描间隔又成整数比信道错配也会稳定保持。判断方法把扫描窗口加宽到能覆盖三个信道轮转如果问题消失说明是信道轮转相位问题。或者把广播端的广播事件改成在单个信道上重复发看接收端是否能扫到。参数配置的工程建议广播间隔不要取扫描间隔的整数倍尤其不要取相等值。如果接收端扫描间隔是 1 秒广播间隔可以取 1.1 秒、0.9 秒、1.3 秒这类非整数比的值。如果协议栈支持广播随机延迟把延迟范围设得比扫描窗口大这样即使某一轮错开下一轮也能漂移进窗口。扫描窗口不要设得太窄。如果广播端的随机延迟是 5 毫秒量级扫描窗口至少要是它的几倍否则扫到概率会受随机延迟支配。但窗口也不能太大否则功耗上去了。一个经验值是窗口取 30 到 100 毫秒具体看广播间隔和功耗预算。如果接收端和广播端都是自己可控的最稳妥的做法是让扫描间隔略小于广播间隔并且扫描窗口覆盖广播事件的可能漂移范围。比如广播间隔 1 秒、随机延迟 ±5 毫秒扫描间隔取 900 毫秒、窗口取 50 毫秒这样每个广播周期内扫描窗口都会在时间轴上“扫过”广播时刻不会形成稳定错配。如果接收端是手机或通用设备扫描参数不可控那就只能调广播端。把广播间隔设成一个和常见扫描间隔不成整数比的值并且打开广播随机延迟。很多通用设备的扫描间隔是固定的几个档位广播端避开这些档位的整数倍能显著提高被扫到的概率。调试时的一个实用手段时间戳对齐如果条件允许在广播端和接收端分别打时间戳然后把两组时间戳放到同一时间轴上对比。广播端记录每次广播事件的起始时刻接收端记录每个扫描窗口的起止时刻。把两组数据画出来一眼就能看出广播事件是否落在扫描窗口内。这个手段听起来简单但现场往往没人做因为打时间戳需要额外的调试接口和日志存储。不过对于这种错配问题时间戳对齐是最直接的证据比反复换硬件、改天线效率高得多。如果项目里已经有日志系统加这个调试信息的成本并不高。小结一下判断路径接收端扫不到广播先确认广播端在发。抓包工具能看到包就排除发射端。然后看接收端扫描日志确认扫描窗口在运行。如果两者都在运行但就是扫不到优先怀疑周期错配。把广播间隔或扫描间隔改成非整数比如果问题消失就是错配。如果改参数不方便用时间戳对齐确认广播事件和扫描窗口的时间关系。这个问题的麻烦之处在于它不像天线问题那样有直观的指标可测也不像协议错误那样有报错可查。它藏在两个各自合规的参数组合里靠的是对时间轴的理解和一点调试耐心。一旦踩过一次后面配参数时就会本能地避开整数比。
阅读完成 · 觉得有帮助？
