去年年底我在做一批无线门锁的升级方案，客户要求既要能用手机直连调试，又要支持几十把锁之间的低时延联动。第一版我用了两颗芯片：一颗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频段时的互相压制。我第一版方案里两颗芯片天线距离只有2cm，BLE广播一开，私有2.4G的接收灵敏度直接掉好几个dB，因为在2400到2483.5MHz这一段，两个收发射频前端会互相抬底噪。想靠天线隔离来解决，板子尺寸又不允许。
OM6625A这类单芯片双模方案，BLE和私有2.4G共享射频前端、时钟和天线，由协议栈里的调度器统一分配时隙。BLE连接事件的anchor点固定下来，私有2.4G收发插到空闲窗口，天然避免了同一时刻两个射频同时收发的问题。这是双模SoC和"两颗芯片硬拼"最本质的差别，也是我觉得这颗芯片最值得关注的地方。
2. OM6625A的射频与协议栈实测：数据手册不会写全的细节
2.1 样片实测的射频参数
我手上这块工程样片配合频谱仪和屏蔽室做了基础射频测试，结果供参考：
| 测试项 | 实测值 | 说明 |
|---|---|---|
| 发射功率范围 | -20dBm到+10dBm | 软件可配，常配10dBm |
| BLE 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.2mA
- TX电流（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 10dBm（10mW）能覆盖多远：算一笔链路账
SRRC对微功率短距离无线电发射设备的规定里，2400到2483.5MHz频段的发射功率限值就是10mW，也就是10dBm。这个限制直接决定了私有2.4G设备不能靠功率硬推覆盖，只能靠协议和拓扑补。
每秒多少米？可以按自由空间路径损耗估算：接收电平等于发射功率加天线增益减路径损耗减衰落余量。2.45GHz频率下，1米自由空间损耗约40dB，10米约60dB，30米约70dB。把10dBm发射功率、0dBi天线、-96dBm灵敏度和20dB衰落余量带进去，10米处接收电平约-70dBm，30米处约-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信道9 | 1.5%左右 | 近距离，距离1米 |
| Wi-Fi 40MHz信道5到9 | 8%以上 | 近距离持续传输 |
同样的位置和距离，把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 开发环境与第一版Demo
OM6625A的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从第一天就打开，三是所有功耗测试都在双模同时开启的状态下测。希望这份实操记录对你们有参考价值。
