去年年底我在做一批无线门锁的升级方案客户要求既要能用手机直连调试又要支持几十把锁之间的低时延联动。第一版我用了两颗芯片一颗BLE负责手机连接一颗私有2.4G收发器负责门锁联动。结果被成本卡住更麻烦的是两颗射频在同一块板上互相干扰上电之后联动时延抖得厉害。后来拿到OM6625A的样片才发现这种BLE5.4与私有2.4G双模做成一颗系统级芯片SoC的方案才是真正能把这类问题一次性解决的路子。这颗OM6625A最大的特点是单芯片集成BLE5.4射频/协议栈和私有2.4G协议栈发射功率可以软件配置到10dBm以下正好卡在SRRC微功率设备的限值内省掉一颗独立射频芯片和额外的天线匹配电路。它适合的产品场景很典型低功耗传感器网络、私有mesh组网、无线遥控/键鼠/标签、语音同步这类既要手机互操作又要低时延联动的设备。这篇文章我把从样片到量产过程中涉及到的双模调度、射频实测、私有mesh组网、低功率链路预算、Wi-Fi共存的踩坑记录都写出来部分参数以我手上样片实测为准不一定和最终量产版本完全一致但思路和调试方法可以直接复用。1. 为什么一颗SoC要同时做BLE5.4和私有2.4G两个协议其实都搞不定所有场景1.1 BLE5.4真正有用的更新点BLE5.4相比之前的版本我觉得对物联网设备最有价值的是三个东西加密广播数据EAD、周期广播带响应PAwR以及链路层扩展特性集。EAD解决的是广播内容裸奔的问题广播包里的数据可以加密只有配对过的接收端才能解出来这对私有传感器网络很重要。PAwR则解决大规模标签类设备读写的效率问题让Access Point可以像点名一样和成千上万个终端按周期通讯。但要说清楚的是BLE5.4改的主要是广播链路和连接管理核心速率和连接调度机制没有变。BLE仍然是那个时隙化、由主机轮询的架构连接事件最小间隔7.5ms实际项目里很多人为了省电跑到15ms以上。这带来一个很实际的问题联动类应用里一方动作要等到下一个连接事件才能传出去端到端时延往往超过20ms中间如果再有一级转发体感就非常明显。1.2 私有2.4G的价值把时延做到BLE做不到的级别私有2.4G协议的价值在于你自己说了算。前导码可以做到8bit帧头可以砍到很短协议开销做到极低时隙可以压到1ms级别。我在同样一块板子上实测私有2.4G做遥控类报文端到端时延可以做到5ms以内同场景下BLE很难进10ms。私有协议还能自定义跳频表、自定义组播和广播并发配合短帧在低功耗上也有优势。代价也很明显没有互操作性、没有手机生态产品之间只能自己和自己玩。所以很多产品实际需要的不是二选一而是两个都要——BLE负责和手机、网关互操作私有2.4G负责设备间低时延联动。这就是OM6625A这类双模SoC存在的根本理由。1.3 双模不是堆料共享射频才是真优势有人会问两颗芯片不也能实现双模吗成本、面积只是表面问题更深层的坑是两个射频同时工作在2.4G频段时的互相压制。我第一版方案里两颗芯片天线距离只有2cmBLE广播一开私有2.4G的接收灵敏度直接掉好几个dB因为在2400到2483.5MHz这一段两个收发射频前端会互相抬底噪。想靠天线隔离来解决板子尺寸又不允许。OM6625A这类单芯片双模方案BLE和私有2.4G共享射频前端、时钟和天线由协议栈里的调度器统一分配时隙。BLE连接事件的anchor点固定下来私有2.4G收发插到空闲窗口天然避免了同一时刻两个射频同时收发的问题。这是双模SoC和两颗芯片硬拼最本质的差别也是我觉得这颗芯片最值得关注的地方。2. OM6625A的射频与协议栈实测数据手册不会写全的细节2.1 样片实测的射频参数我手上这块工程样片配合频谱仪和屏蔽室做了基础射频测试结果供参考测试项实测值说明发射功率范围-20dBm到10dBm软件可配常配10dBmBLE 2Mbps接收灵敏度约-94dBm屏蔽室、PER 30.8%条件下私有2.4G 1Mbps接收灵敏度约-96dBm短帧模式CRC 16bit初始频偏±20kHz以内工程样片未校准校准后频偏±5kHz以内产测写入补偿值跳频切换时间150us级别从当前频点切到下一频点并可收发灵敏度这点比较关键。私有2.4G的灵敏度通常比同速率的BLE好1到2dB因为协议开销小解调器的工作点可以推得更低。但灵敏度和抗干扰是两回事后面Wi-Fi共存部分我会展开。还有一个实际测试中容易忽略的问题是频偏。早期样片晶振批次差异大如果不在产测里做频率校准长数据包会出现CRC连续失败表现为近距离信号很好但距离稍远就丢包。我在Demo阶段没有做校准结果被这个问题坑了整整两天。2.2 双模调度机制私有2.4G长包是最大的坑双模SoC的核心在于调度器。OM6625A的SDK里有个协议调度器BLE连接事件被定义为最高优先级私有2.4G的收发任务插在两个连接事件之间的空闲窗口。实际使用中需要注意两点。第一私有2.4G不要发长包。数据手册里不会明显提醒你但空中时间超过2ms的长包很容易把BLE连接窗口挤占掉导致连接事件漂移严重时BLE直接掉同步。我建议私有2.4G单帧数据控制在300字节以内在2Mbps速率下空中时间约1.2ms留给调度器足够余量。第二BLE的连接间隔不能设太短。如果BLE以7.5ms最小间隔运行每个连接事件占据的时间加上接收窗口切换留给私有2.4G的窗口就很碎私有协议的轮询周期会被拉长。我的做法是BLE连接间隔跑到30ms私有2.4G在这30ms里插入10几次短收发两边都能保证功耗也可控。2.3 功耗数据双模同时开启时的实测低功耗芯片最忌讳只看单模功耗。双模同时开启的电流往往比分别开、分别测的电流之和高一点因为调度器本身也要跑。我实测的数据大概是这些Sleep电流0.9uA到1.8uA我用的外部32.768kHz晶振RTC唤醒BLE RX电流约4.8mA私有2.4G RX电流约4.2mATX电流10dBm约6.5mA以一个低功耗联动节点为例私有2.4G每100ms醒来一次收10字节同步包RX窗口1ms其余时间Sleep平均电流大约是2uA乘0.99加4.2mA乘0.01算下来约44uA。如果每天还要额外发20次短帧每次TX占用2ms再增加大概8uA的平均电流。这个量级用200mAh电池可以撑几个月无线门锁、电子价签这类设备是够用的。要注意的是RF前端的启动稳定时间不能忽略。私有2.4G从Sleep到能收到第一个有效字节实测至少需要0.5ms我在平均功耗计算里是按1ms RX窗口算的。如果为了省电把RX窗口压到0.3ms会发现根本收不到数据因为前端还在稳定过程中。3. 私有2.4G Mesh设计思路与10dBm发射功率的链路预算3.1 10dBm10mW能覆盖多远算一笔链路账SRRC对微功率短距离无线电发射设备的规定里2400到2483.5MHz频段的发射功率限值就是10mW也就是10dBm。这个限制直接决定了私有2.4G设备不能靠功率硬推覆盖只能靠协议和拓扑补。每秒多少米可以按自由空间路径损耗估算接收电平等于发射功率加天线增益减路径损耗减衰落余量。2.45GHz频率下1米自由空间损耗约40dB10米约60dB30米约70dB。把10dBm发射功率、0dBi天线、-96dBm灵敏度和20dB衰落余量带进去10米处接收电平约-70dBm30米处约-80dBm空旷环境下50米左右是合理的。室内场景完全是另一回事。一堵混凝土墙的穿透损耗在10到15dB穿两堵墙之后余量所剩无几。所以室内私有2.4G设备如果距离稍远就掉线不用怀疑灵敏度先算穿墙损耗。解决思路不是加功率而是加节点做mesh多跳每跳距离压在20米以内靠拓扑把覆盖叠出来。3.2 私有Mesh的组网与路由泛洪够用就别上路由表我在OM6625A上跑的私有mesh组网流程大概是这三步。第一步协调器周期性发组网信标信标里带网络ID和跳数。第二步节点扫描信标按RSSI和跳数评估父节点选择一个信号最好的加入。第三步节点周期性和父节点交换保活报文把路由信息逐层上报。路由选型上我的经验是50个节点以内、业务是周期性上报的网络直接泛洪就够了。泛洪实现简单网络拓扑变了也不用维护路由表代价是每个报文每跳转发一次信道占用高。节点多到100以上或者有下行实时控制需求时再考虑维护一张简单的路由表记录到每个节点的下一跳。低功耗节点在mesh里的待遇需要单独设计。我建议休眠节点不要实时监听信道而是由父节点缓存下行数据在节点按约定周期醒来的那一刻把数据推下来。这样节点的平均电流才能维持在几十微安级别否则一个mesh里只要有部分节点常驻监听整个网络的功耗水平都会被拉高。3.3 ACK与重传策略低功率场景下别把重传次数设太大可靠传输靠ACK但ACK本身要花时间和电流。我实测过一组数据同一跳链路不做重传时丢包率大约1%两次重传可以把丢包率压到0.05%以内五次重传的收益就很小了信道占用和功耗却成倍涨。所以我的建议是把重传次数上限设为3次第一次重传在50ms后后面每次退避时间翻倍。这样既不把电池烧在无谓的重传上又能兜住大部分偶发干扰。另外ACK里最好带上收到的帧序号这样接收方不用依赖协议栈内部那套复杂的滑动窗口直接做最新帧优先的语义就行对控制类业务来说旧帧的重传其实没有意义。3.4 SRRC认证视角下的10dBm设计余量SRRC认证对这类设备的测试项包括频率容限、发射功率、占用带宽和杂散发射。这里有个容易被忽略的点发射功率限值10mW是针对等效全向辐射功率EIRP的不是SoC寄存器里的TX功率。如果你的板载天线增益是2dBi那么软件里的发射功率最多只能开到8dBm留给天线增益的余量是零。我在一个早期项目里吃过这个亏天线增益标称2dBi我按10dBm寄存器值送测结果辐射功率超限只能把功率降回8dBm重新测整个排期延了一周。所以产品定义阶段就要确认天线选型PCB天线的实际增益通常在0到2dBi之间陶瓷天线可能到2到3dBi软件里要留出EIRP余量不能顶满算。4. 和Wi-Fi 2.4G共存7260网卡强制跑2.4G的真实干扰场景4.1 为什么2.4G频段这么挤2.4G频段是个大杂烩。Wi-Fi信道1、6、11基本把整段占满BLE的37、38、39三个广播信道又正好落在Wi-Fi信道间隙附近再加上蓝牙经典、ZigBee、私有2.4G、无线鼠标、USB3.0噪声以及老设备里的Intel 7260网卡在5G信号不佳时被强制切到2.4G——整个频段几乎没有任何一段是干净的。7260网卡强制2.4G这个场景特别典型很多办公环境里笔记本的5G信号弱网卡自动落到2.4G而会议室里蓝牙、无线演示器、私有2.4G设备全挤在这一个频段。Wi-Fi一旦用40MHz带宽两个相邻信道合起来几乎把2.4G全段都占掉了私有2.4G固定信道会非常难受。4.2 实测数据Wi-Fi开启前后的丢包对比我在测试环境里用OM6625A私有2.4G跑固定频点旁边让笔记本的7260网卡以2.4G连接Wi-Fi并持续传大文件实测结果大概是这样场景私有2.4G丢包率说明无Wi-Fi干扰0.1%左右空旷环境距离5米Wi-Fi 20MHz信道91.5%左右近距离距离1米Wi-Fi 40MHz信道5到98%以上近距离持续传输同样的位置和距离把OM6625A切到BLE模式由于BLE有自适应跳频大部分被Wi-Fi占用的信道会被自动跳开丢包率明显低于私有协议固定信道。这个对比清楚地说明一个事私有2.4G如果不做跳频和信道避让在办公环境里根本没有可靠性可言。4.3 共存策略跳频黑名单、CCA和时隙规划我的建议是私有2.4G协议从第一天就把这三件事做进去。第一跳频表要带黑名单机制。把Wi-Fi常用的信道1、6、11以及它们扩展后的相邻频点加入黑名单跳频只遍历未被占用的频点。第二发送前做CCA信道空闲检测。我在OM6625A上看寄存器里当前信道能量值超过阈值就跳过这个频点等下一个跳频点再发。代价是单次发送时延增加约1个跳频周期但整体丢包率能降一个数量级。第三时隙对齐。Wi-Fi信标间隔通常是100ms在信标帧广播的那几毫秒里整个频段都会被压住。如果你把私有2.4G的同步时隙放在两个Wi-Fi信标中间避开那几毫秒成功率会明显提高。这个策略在Mesh网络里尤其重要协调器的信标最好固定落在Wi-Fi beacon间隙。5. 从Demo到量产天线调试、认证送测与产线校准5.1 开发环境与第一版DemoOM6625A的SDK我拿到的版本里BLE协议栈和私有2.4G协议栈是同一套代码体系例程自带一个灯控和按键的双模工程能直接测两种模式切换和时延。编译烧录流程不复杂重点看一下协议调度器的配置参数特别是BLE连接间隔和私有2.4G的时隙窗口这两个参数直接影响整体表现。如果你是第一次接触双模SoC建议第一版Demo不要改默认配置先把例程跑通用手机连BLE同时用另一块板子发私有2.4G数据观察两边是否互相干扰。我就是这样先建立了一个基准后面所有改动都以这个基准做对比。5.2 天线匹配S11调试和那些容易翻车的细节板载天线的调试是整个射频环节里最容易被轻视的部分。我用的矢量网络分析仪测S11回波损耗目标是在2400到2483.5MHz全频段内小于-10dB。实际调试中发现目标频段内的谐振点如果偏了直接调L型匹配网络的电容电感值就可以移回来但天线的阻抗轨迹和PCB地有很大关系地没铺好的板子匹配调得再准也没用。外壳的影响也很大。塑料外壳的介电常数会让天线谐振频率下降几个MHz我见过一块板子裸板测S11很好装进外壳后回波损耗掉到-6dB的。所以天线匹配调试一定要带着外壳一起测至少要确认外壳装配前后的频偏方向和幅度在匹配网络上预留补偿余量。5.3 认证送测SRRC和FCC需要提前准备的测试模式SRRC认证和FCC认证虽然测试项目有差异但都要求设备能够锁定在最大功率下进行传导和辐射测试。这意味着固件里必须内置一个产测/认证模式命令通过UART或RF命令把发射功率固定到最大连续发特定长度的数据包同时允许外部仪器触发或关闭调制。我建议把认证用测试固件和量产固件分开维护。认证固件里只保留最少的初始化代码关闭私有2.4G的跳频和CCA逻辑固定一个频点连续发射这样测试结果可复现不会因为固件逻辑干扰稳定性。量产固件则要确认默认关闭这种测试模式否则设备到用户手里可能被任意命令切进认证模式是个安全隐患。5.4 产线校准频偏补偿和功率setpoint模组出厂必须做射频校准这是批量产品良率的关键。我做的产测项目中包括四样发射功率校准、频率校准、接收灵敏度抽检、整机电流。功率校准是把每个模组的实际发射功率校准到10dBm附近偏差控制在0.5dB以内频率校准是把晶振频偏测出来写入Flash或者OTP协议栈在发送前自动修正。这里有一个我踩过的坑PCB天线批次更换或者天线位置微调后功率setpoint不重新标定会导致部分模组EIRP超限或者功率不足。所以产测程序里要留一个校准系数更新的接口天线批次变更时重新跑一遍功率校准不要让产线为了省时间跳过这一步。整机电流测试也建议在双模同时开启的工作模式下测保证出货产品不会因为调度异常导致整机功耗超标。最后分享一个我踩过的坑。产品初期我没有把Wi-Fi共存测试纳入计划直到送样前才发现私有2.4G在会议室环境里丢包严重临时补跳频和CCA策略折腾了三周才稳定下来。如果再来一次我会在Demo阶段就把三件事固定下来一是射频前端参考设计拿到手不要随意改二是跳频表和CCA从第一天就打开三是所有功耗测试都在双模同时开启的状态下测。希望这份实操记录对你们有参考价值。
双模SoC实现BLE5.4与私有2.4G融合：无线门锁低时延联动实测
去年年底我在做一批无线门锁的升级方案客户要求既要能用手机直连调试又要支持几十把锁之间的低时延联动。第一版我用了两颗芯片一颗BLE负责手机连接一颗私有2.4G收发器负责门锁联动。结果被成本卡住更麻烦的是两颗射频在同一块板上互相干扰上电之后联动时延抖得厉害。后来拿到OM6625A的样片才发现这种BLE5.4与私有2.4G双模做成一颗系统级芯片SoC的方案才是真正能把这类问题一次性解决的路子。这颗OM6625A最大的特点是单芯片集成BLE5.4射频/协议栈和私有2.4G协议栈发射功率可以软件配置到10dBm以下正好卡在SRRC微功率设备的限值内省掉一颗独立射频芯片和额外的天线匹配电路。它适合的产品场景很典型低功耗传感器网络、私有mesh组网、无线遥控/键鼠/标签、语音同步这类既要手机互操作又要低时延联动的设备。这篇文章我把从样片到量产过程中涉及到的双模调度、射频实测、私有mesh组网、低功率链路预算、Wi-Fi共存的踩坑记录都写出来部分参数以我手上样片实测为准不一定和最终量产版本完全一致但思路和调试方法可以直接复用。1. 为什么一颗SoC要同时做BLE5.4和私有2.4G两个协议其实都搞不定所有场景1.1 BLE5.4真正有用的更新点BLE5.4相比之前的版本我觉得对物联网设备最有价值的是三个东西加密广播数据EAD、周期广播带响应PAwR以及链路层扩展特性集。EAD解决的是广播内容裸奔的问题广播包里的数据可以加密只有配对过的接收端才能解出来这对私有传感器网络很重要。PAwR则解决大规模标签类设备读写的效率问题让Access Point可以像点名一样和成千上万个终端按周期通讯。但要说清楚的是BLE5.4改的主要是广播链路和连接管理核心速率和连接调度机制没有变。BLE仍然是那个时隙化、由主机轮询的架构连接事件最小间隔7.5ms实际项目里很多人为了省电跑到15ms以上。这带来一个很实际的问题联动类应用里一方动作要等到下一个连接事件才能传出去端到端时延往往超过20ms中间如果再有一级转发体感就非常明显。1.2 私有2.4G的价值把时延做到BLE做不到的级别私有2.4G协议的价值在于你自己说了算。前导码可以做到8bit帧头可以砍到很短协议开销做到极低时隙可以压到1ms级别。我在同样一块板子上实测私有2.4G做遥控类报文端到端时延可以做到5ms以内同场景下BLE很难进10ms。私有协议还能自定义跳频表、自定义组播和广播并发配合短帧在低功耗上也有优势。代价也很明显没有互操作性、没有手机生态产品之间只能自己和自己玩。所以很多产品实际需要的不是二选一而是两个都要——BLE负责和手机、网关互操作私有2.4G负责设备间低时延联动。这就是OM6625A这类双模SoC存在的根本理由。1.3 双模不是堆料共享射频才是真优势有人会问两颗芯片不也能实现双模吗成本、面积只是表面问题更深层的坑是两个射频同时工作在2.4G频段时的互相压制。我第一版方案里两颗芯片天线距离只有2cmBLE广播一开私有2.4G的接收灵敏度直接掉好几个dB因为在2400到2483.5MHz这一段两个收发射频前端会互相抬底噪。想靠天线隔离来解决板子尺寸又不允许。OM6625A这类单芯片双模方案BLE和私有2.4G共享射频前端、时钟和天线由协议栈里的调度器统一分配时隙。BLE连接事件的anchor点固定下来私有2.4G收发插到空闲窗口天然避免了同一时刻两个射频同时收发的问题。这是双模SoC和两颗芯片硬拼最本质的差别也是我觉得这颗芯片最值得关注的地方。2. OM6625A的射频与协议栈实测数据手册不会写全的细节2.1 样片实测的射频参数我手上这块工程样片配合频谱仪和屏蔽室做了基础射频测试结果供参考测试项实测值说明发射功率范围-20dBm到10dBm软件可配常配10dBmBLE 2Mbps接收灵敏度约-94dBm屏蔽室、PER 30.8%条件下私有2.4G 1Mbps接收灵敏度约-96dBm短帧模式CRC 16bit初始频偏±20kHz以内工程样片未校准校准后频偏±5kHz以内产测写入补偿值跳频切换时间150us级别从当前频点切到下一频点并可收发灵敏度这点比较关键。私有2.4G的灵敏度通常比同速率的BLE好1到2dB因为协议开销小解调器的工作点可以推得更低。但灵敏度和抗干扰是两回事后面Wi-Fi共存部分我会展开。还有一个实际测试中容易忽略的问题是频偏。早期样片晶振批次差异大如果不在产测里做频率校准长数据包会出现CRC连续失败表现为近距离信号很好但距离稍远就丢包。我在Demo阶段没有做校准结果被这个问题坑了整整两天。2.2 双模调度机制私有2.4G长包是最大的坑双模SoC的核心在于调度器。OM6625A的SDK里有个协议调度器BLE连接事件被定义为最高优先级私有2.4G的收发任务插在两个连接事件之间的空闲窗口。实际使用中需要注意两点。第一私有2.4G不要发长包。数据手册里不会明显提醒你但空中时间超过2ms的长包很容易把BLE连接窗口挤占掉导致连接事件漂移严重时BLE直接掉同步。我建议私有2.4G单帧数据控制在300字节以内在2Mbps速率下空中时间约1.2ms留给调度器足够余量。第二BLE的连接间隔不能设太短。如果BLE以7.5ms最小间隔运行每个连接事件占据的时间加上接收窗口切换留给私有2.4G的窗口就很碎私有协议的轮询周期会被拉长。我的做法是BLE连接间隔跑到30ms私有2.4G在这30ms里插入10几次短收发两边都能保证功耗也可控。2.3 功耗数据双模同时开启时的实测低功耗芯片最忌讳只看单模功耗。双模同时开启的电流往往比分别开、分别测的电流之和高一点因为调度器本身也要跑。我实测的数据大概是这些Sleep电流0.9uA到1.8uA我用的外部32.768kHz晶振RTC唤醒BLE RX电流约4.8mA私有2.4G RX电流约4.2mATX电流10dBm约6.5mA以一个低功耗联动节点为例私有2.4G每100ms醒来一次收10字节同步包RX窗口1ms其余时间Sleep平均电流大约是2uA乘0.99加4.2mA乘0.01算下来约44uA。如果每天还要额外发20次短帧每次TX占用2ms再增加大概8uA的平均电流。这个量级用200mAh电池可以撑几个月无线门锁、电子价签这类设备是够用的。要注意的是RF前端的启动稳定时间不能忽略。私有2.4G从Sleep到能收到第一个有效字节实测至少需要0.5ms我在平均功耗计算里是按1ms RX窗口算的。如果为了省电把RX窗口压到0.3ms会发现根本收不到数据因为前端还在稳定过程中。3. 私有2.4G Mesh设计思路与10dBm发射功率的链路预算3.1 10dBm10mW能覆盖多远算一笔链路账SRRC对微功率短距离无线电发射设备的规定里2400到2483.5MHz频段的发射功率限值就是10mW也就是10dBm。这个限制直接决定了私有2.4G设备不能靠功率硬推覆盖只能靠协议和拓扑补。每秒多少米可以按自由空间路径损耗估算接收电平等于发射功率加天线增益减路径损耗减衰落余量。2.45GHz频率下1米自由空间损耗约40dB10米约60dB30米约70dB。把10dBm发射功率、0dBi天线、-96dBm灵敏度和20dB衰落余量带进去10米处接收电平约-70dBm30米处约-80dBm空旷环境下50米左右是合理的。室内场景完全是另一回事。一堵混凝土墙的穿透损耗在10到15dB穿两堵墙之后余量所剩无几。所以室内私有2.4G设备如果距离稍远就掉线不用怀疑灵敏度先算穿墙损耗。解决思路不是加功率而是加节点做mesh多跳每跳距离压在20米以内靠拓扑把覆盖叠出来。3.2 私有Mesh的组网与路由泛洪够用就别上路由表我在OM6625A上跑的私有mesh组网流程大概是这三步。第一步协调器周期性发组网信标信标里带网络ID和跳数。第二步节点扫描信标按RSSI和跳数评估父节点选择一个信号最好的加入。第三步节点周期性和父节点交换保活报文把路由信息逐层上报。路由选型上我的经验是50个节点以内、业务是周期性上报的网络直接泛洪就够了。泛洪实现简单网络拓扑变了也不用维护路由表代价是每个报文每跳转发一次信道占用高。节点多到100以上或者有下行实时控制需求时再考虑维护一张简单的路由表记录到每个节点的下一跳。低功耗节点在mesh里的待遇需要单独设计。我建议休眠节点不要实时监听信道而是由父节点缓存下行数据在节点按约定周期醒来的那一刻把数据推下来。这样节点的平均电流才能维持在几十微安级别否则一个mesh里只要有部分节点常驻监听整个网络的功耗水平都会被拉高。3.3 ACK与重传策略低功率场景下别把重传次数设太大可靠传输靠ACK但ACK本身要花时间和电流。我实测过一组数据同一跳链路不做重传时丢包率大约1%两次重传可以把丢包率压到0.05%以内五次重传的收益就很小了信道占用和功耗却成倍涨。所以我的建议是把重传次数上限设为3次第一次重传在50ms后后面每次退避时间翻倍。这样既不把电池烧在无谓的重传上又能兜住大部分偶发干扰。另外ACK里最好带上收到的帧序号这样接收方不用依赖协议栈内部那套复杂的滑动窗口直接做最新帧优先的语义就行对控制类业务来说旧帧的重传其实没有意义。3.4 SRRC认证视角下的10dBm设计余量SRRC认证对这类设备的测试项包括频率容限、发射功率、占用带宽和杂散发射。这里有个容易被忽略的点发射功率限值10mW是针对等效全向辐射功率EIRP的不是SoC寄存器里的TX功率。如果你的板载天线增益是2dBi那么软件里的发射功率最多只能开到8dBm留给天线增益的余量是零。我在一个早期项目里吃过这个亏天线增益标称2dBi我按10dBm寄存器值送测结果辐射功率超限只能把功率降回8dBm重新测整个排期延了一周。所以产品定义阶段就要确认天线选型PCB天线的实际增益通常在0到2dBi之间陶瓷天线可能到2到3dBi软件里要留出EIRP余量不能顶满算。4. 和Wi-Fi 2.4G共存7260网卡强制跑2.4G的真实干扰场景4.1 为什么2.4G频段这么挤2.4G频段是个大杂烩。Wi-Fi信道1、6、11基本把整段占满BLE的37、38、39三个广播信道又正好落在Wi-Fi信道间隙附近再加上蓝牙经典、ZigBee、私有2.4G、无线鼠标、USB3.0噪声以及老设备里的Intel 7260网卡在5G信号不佳时被强制切到2.4G——整个频段几乎没有任何一段是干净的。7260网卡强制2.4G这个场景特别典型很多办公环境里笔记本的5G信号弱网卡自动落到2.4G而会议室里蓝牙、无线演示器、私有2.4G设备全挤在这一个频段。Wi-Fi一旦用40MHz带宽两个相邻信道合起来几乎把2.4G全段都占掉了私有2.4G固定信道会非常难受。4.2 实测数据Wi-Fi开启前后的丢包对比我在测试环境里用OM6625A私有2.4G跑固定频点旁边让笔记本的7260网卡以2.4G连接Wi-Fi并持续传大文件实测结果大概是这样场景私有2.4G丢包率说明无Wi-Fi干扰0.1%左右空旷环境距离5米Wi-Fi 20MHz信道91.5%左右近距离距离1米Wi-Fi 40MHz信道5到98%以上近距离持续传输同样的位置和距离把OM6625A切到BLE模式由于BLE有自适应跳频大部分被Wi-Fi占用的信道会被自动跳开丢包率明显低于私有协议固定信道。这个对比清楚地说明一个事私有2.4G如果不做跳频和信道避让在办公环境里根本没有可靠性可言。4.3 共存策略跳频黑名单、CCA和时隙规划我的建议是私有2.4G协议从第一天就把这三件事做进去。第一跳频表要带黑名单机制。把Wi-Fi常用的信道1、6、11以及它们扩展后的相邻频点加入黑名单跳频只遍历未被占用的频点。第二发送前做CCA信道空闲检测。我在OM6625A上看寄存器里当前信道能量值超过阈值就跳过这个频点等下一个跳频点再发。代价是单次发送时延增加约1个跳频周期但整体丢包率能降一个数量级。第三时隙对齐。Wi-Fi信标间隔通常是100ms在信标帧广播的那几毫秒里整个频段都会被压住。如果你把私有2.4G的同步时隙放在两个Wi-Fi信标中间避开那几毫秒成功率会明显提高。这个策略在Mesh网络里尤其重要协调器的信标最好固定落在Wi-Fi beacon间隙。5. 从Demo到量产天线调试、认证送测与产线校准5.1 开发环境与第一版DemoOM6625A的SDK我拿到的版本里BLE协议栈和私有2.4G协议栈是同一套代码体系例程自带一个灯控和按键的双模工程能直接测两种模式切换和时延。编译烧录流程不复杂重点看一下协议调度器的配置参数特别是BLE连接间隔和私有2.4G的时隙窗口这两个参数直接影响整体表现。如果你是第一次接触双模SoC建议第一版Demo不要改默认配置先把例程跑通用手机连BLE同时用另一块板子发私有2.4G数据观察两边是否互相干扰。我就是这样先建立了一个基准后面所有改动都以这个基准做对比。5.2 天线匹配S11调试和那些容易翻车的细节板载天线的调试是整个射频环节里最容易被轻视的部分。我用的矢量网络分析仪测S11回波损耗目标是在2400到2483.5MHz全频段内小于-10dB。实际调试中发现目标频段内的谐振点如果偏了直接调L型匹配网络的电容电感值就可以移回来但天线的阻抗轨迹和PCB地有很大关系地没铺好的板子匹配调得再准也没用。外壳的影响也很大。塑料外壳的介电常数会让天线谐振频率下降几个MHz我见过一块板子裸板测S11很好装进外壳后回波损耗掉到-6dB的。所以天线匹配调试一定要带着外壳一起测至少要确认外壳装配前后的频偏方向和幅度在匹配网络上预留补偿余量。5.3 认证送测SRRC和FCC需要提前准备的测试模式SRRC认证和FCC认证虽然测试项目有差异但都要求设备能够锁定在最大功率下进行传导和辐射测试。这意味着固件里必须内置一个产测/认证模式命令通过UART或RF命令把发射功率固定到最大连续发特定长度的数据包同时允许外部仪器触发或关闭调制。我建议把认证用测试固件和量产固件分开维护。认证固件里只保留最少的初始化代码关闭私有2.4G的跳频和CCA逻辑固定一个频点连续发射这样测试结果可复现不会因为固件逻辑干扰稳定性。量产固件则要确认默认关闭这种测试模式否则设备到用户手里可能被任意命令切进认证模式是个安全隐患。5.4 产线校准频偏补偿和功率setpoint模组出厂必须做射频校准这是批量产品良率的关键。我做的产测项目中包括四样发射功率校准、频率校准、接收灵敏度抽检、整机电流。功率校准是把每个模组的实际发射功率校准到10dBm附近偏差控制在0.5dB以内频率校准是把晶振频偏测出来写入Flash或者OTP协议栈在发送前自动修正。这里有一个我踩过的坑PCB天线批次更换或者天线位置微调后功率setpoint不重新标定会导致部分模组EIRP超限或者功率不足。所以产测程序里要留一个校准系数更新的接口天线批次变更时重新跑一遍功率校准不要让产线为了省时间跳过这一步。整机电流测试也建议在双模同时开启的工作模式下测保证出货产品不会因为调度异常导致整机功耗超标。最后分享一个我踩过的坑。产品初期我没有把Wi-Fi共存测试纳入计划直到送样前才发现私有2.4G在会议室环境里丢包严重临时补跳频和CCA策略折腾了三周才稳定下来。如果再来一次我会在Demo阶段就把三件事固定下来一是射频前端参考设计拿到手不要随意改二是跳频表和CCA从第一天就打开三是所有功耗测试都在双模同时开启的状态下测。希望这份实操记录对你们有参考价值。
