4、广播扩展测试：扩展广播PDU、周期性广播、广播同步

广播扩展，说白了就是BLE 5.0里最让我兴奋的特性之一。以前做传统广播时，数据量稍微大点就得拆包，效率低得让人抓狂。我记得第一次在项目中用上扩展广播，那种「终于能一口气发完」的感觉，真的很爽。

但爽归爽，测试起来坑也不少。这一章，我就把我在多个项目中踩过的坑、总结的经验，掰开了讲给你听。

4.1 扩展广播PDU测试

扩展广播PDU，核心变化就是数据包变大了。传统广播最多31字节，扩展广播能到255字节。你想想看，这意味着什么？以前要分8次发的信标数据，现在一次搞定。

测试时，我一般会关注三个维度：

• PDU类型验证：扩展广播有ADV_EXT_IND、AUX_ADV_IND、AUX_CHAIN_IND等好几种。我最开始做测试时，就吃过「PDU类型配错」的亏——设备A发的是AUX_ADV_IND，设备B只认ADV_EXT_IND，结果死活连不上。
• 数据长度测试：从1字节到255字节，每个边界值都得测。我个人习惯用递增法：先发1字节，再发31字节（传统广播上限），然后直接跳到255字节。中间如果有丢包，八成是接收端缓冲区没配够。
• 信道选择：扩展广播默认走1、2、3三个主信道，但AUX_PACKET可以跳到37个数据信道上。这里有个坑——有些老设备只监听主信道，你一跳信道它就丢了。

4.2 周期性广播测试

周期性广播，是BLE 5.0里另一个让我又爱又恨的功能。爱的是它能让接收端提前知道「什么时候会有数据」，省电效果拔群。恨的是——同步过程太容易出问题了。

我曾经在一个智能家居项目里，用周期性广播做传感器数据上报。测试时发现，手机偶尔会漏掉几包数据。排查了半天，最后发现是广播间隔设置得太短，接收端来不及处理。

周期性广播的关键参数有三个：

参数	范围	我的建议
广播间隔	7.5ms ~ 4s	别低于15ms，否则接收端容易丢包
同步超时	100ms ~ 16s	设成广播间隔的3倍以上，防止误判失步
事件计数	0 ~ 65535	注意回绕问题，我见过设备在计数回绕后同步失败

4.3 广播同步测试

广播同步，是周期性广播的「灵魂」。没有同步，接收端就不知道什么时候该醒来听数据。

同步过程其实不复杂：发送端先发一个AUX_SYNC_IND，里面包含了广播间隔、信道映射等信息。接收端收到后，就能算出下一次广播的时间，然后准时醒来接收。

但实际测试中，我遇到过几个典型问题：

• 同步建立失败：发送端和接收端的时钟漂移不一致。我曾经在高温环境下测试，晶振漂了50ppm，同步直接崩了。解决办法是缩短同步超时，让接收端更频繁地重新同步。
• 同步丢失后恢复慢：有些设备丢失同步后，要等好几个广播周期才能重新同步。我建议在测试用例里加入「人为干扰」场景——比如用金属板遮挡天线，看看设备多久能恢复。
• 多设备同步冲突：当多个发送端同时发周期性广播时，接收端可能搞混。我记得有一次测试，三个传感器同时广播，接收端只同步了其中一个。后来发现是广播地址没区分开。

4.4 实战测试流程

说了这么多理论，咱们来点实际的。我一般按这个流程测广播扩展：

1. 基础功能测试：先测扩展广播PDU能不能正常收发。用最简单的1字节数据开始，逐步增加到255字节。
2. 周期性广播测试：打开周期性广播，验证接收端能否同步。重点测不同广播间隔下的同步成功率。
3. 干扰测试：在Wi-Fi、Zigbee等干扰环境下测试。我习惯用2.4GHz信号发生器制造干扰，看看设备在「恶劣环境」下表现如何。
4. 边界测试：测极端情况——比如广播间隔设成7.5ms、同步超时设成100ms。虽然实际产品不会这么用，但能帮你发现底层驱动的问题。
5. 长时间稳定性测试：跑24小时以上。我遇到过设备在运行12小时后同步漂移的问题，不长时间跑根本发现不了。

---

公众号:蓝海资料掘金营，微信deep3321