BLE+私有2.4G双模SoC：物联网低功耗无线通信的工程实践

1. 一个真实的产品选型困境：BLE 和私有 2.4G 为什么要做成双模

1.1 标准协议解决“生态连接”，私有协议解决“场景性能”

我去年做一款带电子价签功能的温湿度传感器，产品需求很分裂：一方面终端用户希望用手机 App 直接扫码连接、读写配置、看实时数据，这部分几乎绕不开 BLE；另一方面，一个货架上十几台设备要集中同步刷新、批量绑定，后台网关又希望用尽量短的报文、尽量低的延迟去控制每个节点，这时候通用 BLE 标准协议反而显得笨重。

这就是很多物联网设备都会撞上的矛盾：标准协议负责“连接生态”，私有协议负责“场景性能”。BLE 的好处不用多说，手机、平板、笔记本全支持，协议栈成熟，抓包工具现成，固件生态完善；但它的帧格式、连接调度、信道跳频算法是全行业统一的，厂商不能为了压低延迟去改 worse？不是不能改，而是改了就不兼容，手机端就不认。

私有 2.4G 则完全不同。基带用 GFSK、帧格式、前导码长度、CRC 算法、加密方式、信道表，都可以由厂商自己定义。你可以把一帧数据压缩到几个字节，可以把收发时隙做成硬实时的，可以让广播报文在一个时间片内被几十个节点同时接收。代价是没有手机端生态，必须配专用的网关或遥控器。所以真正聪明的方案不是二选一，而是把它们放在一颗芯片里，各干各的。

1.2 一颗芯片塞两套无线栈，省下的不只是 PCB 面积

我第一次看到 OM6625A 这类双模系统级芯片的时候，第一反应是：这不就是把我原来的“BLE SoC + 私有 2.4G 无线 MCU”两颗芯片合并了吗？后来仔细算了一下，省下来的东西比想象中多得多。

先说面积。本来是两颗芯片，每颗都要独立的晶振、退耦电容、射频匹配网络，匹配电感电容加起来一排。有些项目为了省空间，把私有 2.4G 芯片做成模块，模块本身又占一块 PCB。换到双模 SoC 之后，一颗芯片、一套晶振、一个匹配电路、一根天线就能同时承担两套射频协议。对小尺寸的电子价签、传感器标签来说，这块面积能决定产品能不能塞进现有的结构件里。

再说功耗和成本。两颗芯片之间走 UART 或 SPI 通信，唤醒、握手、数据搬移、应答，每个环节都在额外耗电。双模 SoC 内部共享 CPU、内存和射频前端，两套协议栈在同一次唤醒里就能完成调度和数据处理，休眠策略也统一了。物料清单少了，BOM 成本下降，生产贴片少了两个料，良率风险和测试工时也降了。这个账算下来，双模不是“多一个功能”，而是“整体方案更简”。

1.3 哪些产品真正需要双模

双模不是所有产品都适用，但你只要遇到下面几类场景，大概率会需要它。

第一类是电子货架标签（ESL）和集中式传感网络。标签数量动不动几百上千，后台需要一个高效的数据通道做批量更新；而现场施工、人员调试时，又需要手机直接连某个标签改价格、改绑定关系。这种情况下，私有 2.4G 负责大规模组网和低延迟刷新，BLE 5.4 负责手机近场调试，各管一段。

第二类是无线遥控、无线麦克风、同步氛围灯这类对延迟敏感的消费设备。私有 2.4G 可以做到几毫秒级甚至亚毫秒级的空中时延，而 BLE 即使是最快的 connection interval 也要预留协商时间。同时这些设备又要支持手机 App 做配对、固件升级、参数配置，双模正好覆盖。

第三类是工业数据采集器、医疗穿戴配件。现场环境里 2.4GHz 频段拥挤，WiFi、蓝牙、私有协议同时在跑，双模芯片可以让你在私有协议里做专属跳频和信道避让，同时保留一条 BLE 链路给运维人员做本地诊断。重点是两套协议都能在同一个低功耗管理框架下运转，不必为调试通道再单独供电。

2. BLE 5.4 到底更新了什么，OM6625A 能吃透哪些特性

2.1 版本演进背后的产品需求

BLE 从 4.0 到 5.4，并不是单纯把速率提上去。4.x 时代大家追求的是低功耗和手机兼容，5.0 引入了 2M PHY 和长距离 Coded PHY，5.1 加入了方向定位（AoA/AoD），5.2 带来了 LE Audio，到了 5.3 把连接更新、外围设备功率控制做了一些修补，而 5.4 的重点已经明显转向“单设备如何管理几千个低功耗节点”。

这个转向不是凭空来的，正好对应电子货架标签、资产追踪、传感器标签这类大规模部署需求。以前做几百个节点的 BLE 网络，要靠厂商自己在应用层堆扫描调度、堆广播窗口、堆 ASYNC 处理；协议栈里没有统一的“中心节点定向唤醒、终端节点按需响应”机制，于是大家都在造轮子，而且轮子之间不兼容。

BLE 5.4 就是在这个背景下出现的。它新增的 PAwR（Periodic Advertising with Responses，带响应的周期性广播）允许一个扫描节点与多个广播节点在固定调度下进行双向数据交换，本质上是在标准协议里定义了一套适合海量低功耗终端的星型/广播式传输机制。OM6625A 这类新出的系统级芯片把 BLE 5.4 协议栈直接吃下来，我理解的意义不只是“兼容新版标准”，而是让开发者少写几层调度算法。

2.2 主要特性拆解：PAwR、加密广播与多广播调度

我对 PAwR 这块比较关注，因为它对 ESL 类场景价值最直接。它的工作方式大致是：中心设备发送周期性广播序列（Periodic Advertising Train），终端的广播在固定的时间子事件里带响应返回。好处是中心节点可以安排几百个终端在不同时隙里上报数据，避免随机碰撞。对开发者来说，这比自己在应用层做 TDMA 要省事得多，而且对端是标准协议栈，未来换其他支持 BLE 5.4 的芯片，逻辑可以直接迁移。

另一个点是加密广播数据。以前 BLE 广播报文基本都是明文，谁拿个抓包器就能看到温度值、设备地址、校准参数。BLE 5.4 允许对广播数据进行加密，从协议层解决了“广播数据裸奔”的问题。在私有 2.4G 和 BLE 共存的场合，这个特性非常实用，因为公共频段里任何接收机都能听到你的射频能量，真正决定数据安全的是帧加密。

当然，BLE 5.4 不是把之前版本推倒重来。2M PHY、Coded PHY、CSA#2（信道选择算法#2）、扩展广播集这些基础能力，在支持 5.4 的 SoC 里通常是完整继承的。OM6625A 作为双模芯片，它的 BLE 侧如果能把广播扩展和定期广播调度合理地支撑起来，那应用层能玩的花样就多了，比如同时维护多个广告集（Advertising Set），一个用于设备发现，一个用于数据下发，一个用于配合私有 2.4G 的握手切换，互不干扰。

2.3 这些特性落到工程项目上的意义

落到工程上，我最直观的感受是：BLE 5.4 把“手机连接”和“规模化网络管理”这两种模式之间的距离拉近了。以前我们只能把 BLE 用作本地点对点调试，大量数据走私有 2.4G，因为私有协议能保证吞吐和时延；现在标准 BLE 也提供了一套相对高效的多设备机制，虽然不能完全替代私有协议在极端低延迟场景下的表现，但至少给了设计者第二条相对标准化的路。

对 OM6625A 这类双模 SoC 而言，BLE 5.4 的意义更像是“标准侧的能力补全”。我可以把设备日常数据上报继续放在私有 2.4G mesh 上跑，把手机入场自动识别、近场配置、批量固件升级放在 BLE 5.4 上跑。需要高确定性的控制通道时切私有 2.4G，需要兼容通用设备时切 BLE，两套协议在同一颗芯片上无缝配合，这样产品既不会被私有协议的孤立生态限制，也不会被标准协议的性能天花板拖住。

3. 私有 2.4G 协议不是过时方案：低延迟与高密度组网的本土化实践

3.1 为什么私有协议还活着

有朋友问我：都在用 BLE 了，为什么还要搞私有 2.4G？答案是：BLE 的调度开销和数据链路逻辑，在某些实时性要求极高的场景里不够“硬”。

举个例子，控制几十个 LED 灯带做一个同步呼吸效果。BLE 连接模式下，每个连接事件之间有固定的间隔，从主机下发指令到从机执行，通常要经过连接事件调度、应用层解析、IO 更新，整体延迟能做到几十毫秒就算不错。而私有 2.4G 可以把一帧控制在 100 到 200 微秒以内，配合硬件同步信号，所有节点在同一个绝对时间戳里切换 PWM 输出，同步误差能到微秒级。这种差距不是靠优化 BLE 应用代码就能追平的，因为协议栈里那一层层调度是标准规定的。

另一个场景是高密度组网。在一块几百平方米的区域里放几百个传感节点，如果全部用 BLE 连接，一个智能手机或网关要维护这么多连接，连接事件调度、信道跳频、重传策略都会成为压力。私有 2.4G mesh 则可以让节点只监听非常短的广播时隙，按需中继，数据汇聚更自由。简单说，私有协议能更高效地利用空口时间。

3.2 2.4GHz 频段的公共属性：WiFi、BLE、私有协议共存与“能否解码”的误区

大家常搜到一个问题：“2.4G 无线 WiFi 信号可以解码出来吗？”这个误解要澄清一下。2.4GHz 是一个开放的短距离无线频段，WiFi、BLE、私有 2.4G 协议都挤在 2.400GHz 到 2.4835GHz 这一百多兆赫兹的频段里，它们之间是共存关系，不是兼容关系。

“解码”这件事，取决于协议是否公开、帧格式是否可知、数据是否加密。WiFi 有完整的 802.11 标准文档，帧头和帧结构公开，用支持监听模式的网卡配合抓包软件，当然可以解析出管理帧和多数业务帧。BLE 也是公开标准，用嗅探器可以抓到广播报文和连接事件。但私有 2.4G 协议是厂商自己定义的，帧长度、前导码、地址字段、白化算法、加密方式都不公开，再加上 GFSK 调制本身可以配合跳频表使用，外部设备即使收到了射频脉冲，也很难直接还原成有意义的数据。

所以“同一个频段能被监听”和“能被解码”是两个等级的问题。对开发者来说，这反而是做私有协议的价值点：在公版协议之上，再套一层私有加密和私有跳频，等于给数据加了双重保险。

3.3 SRRC 认证与 10dBm 发射功率：合规边界也是设计边界

在国内做 2.4G 无线产品，绕不开 SRRC 认证。针对短距离低功率设备，很多产品都把发射功率控制在 10dBm（10mW）以内，这个值既是常见的型号核准要求，也是设计上的一个合理取舍。

很多人一听到“发射功率小于 10dBm”就觉得是不是太弱了，实际不是。无线链路预算不只是发射功率，接收灵敏度同样关键。一颗常见的 2.4G SoC，接收灵敏度做到 -90dBm 到 -95dBm 并不难，于是 10dBm 减掉 -95dBm，链路预算大约有 100 到 105dB。2.4GHz 自由空间路径损耗在 10 米距离大约 60dB，加上穿透隔墙、人体遮挡和衰落余量 20 到 30dB，仍然还有十几二十 dB 的余量。也就是说，在室内 10 到 30 米尺度上，10dBm 完全够用。

从工程角度讲，功率贴着 10dBm 走还有另一个好处：对 WiFi、蓝牙等其他协议形成的干扰更小，设备自身功耗也能降下来。高密度部署时，发射功率不是越大越好，太大会造成节点之间互相压制的“远近效应”，接收机前端饱和，反而把整体网络的稳定性拉下来。所以 SRRC 的 10dBm 限制，某种程度上是在帮产品设计者画好一条安全边界。

3.4 私有 2.4G mesh：拓扑、跳频与干扰规避

既然进了私有 2.4G 的地盘，mesh 组网几乎是必选项。mesh 的核心是让每个节点同时充当终端和路由器，数据可以通过邻居节点逐跳转发，覆盖范围不再受限于单跳链路。

做私有 mesh 有几件事要提前想清楚。第一是拓扑层数。数据每转发一跳，时延和丢包率都会增加，所以我一般建议一条路由路径最多 5 到 8 跳，再高就要考虑分层或改用星型汇聚。第二是跳频策略。2.4G 频段里有 WiFi、蓝牙、微波炉干扰源，私有协议最好配置一张包含几十个信道的跳频表，在检测到连续丢包时自动切频，而不是死守一个信道。

第三是时隙同步。mesh 节点之间如果采用 TDMA 方式传输，需要定期同步时间基准，否则中继转发时隙会逐渐漂移。OM6625A 这类双模 SoC 内部通常有时钟校准机制，私有协议栈会利用 SoC 的本地定时器和射频事件时间戳来做全网时槽对齐。实测下来，同步精度做到几十微秒级别是可行的。

4. 双模共存的工程实现：天线、协议切换与功耗预算

4.1 天线方案：共用射频前端的切换逻辑

双模芯片的硬件设计，第一个要决策的是天线。BLE 和私有 2.4G 工作在同一个频段，物理上完全可以共用一根天线、一个射频前端。芯片内部通常有射频开关或收发切换机制，SDK 里也会提供协议切换接口，外层只需要保证天线匹配网络覆盖 2400MHz 到 2483.5MHz 全频段即可。

但如果你的产品需要在 BLE 保持连接的同时，私有 2.4G 还在高频收发，那就要认真评估是不是需要双天线方案。共用天线意味着同一时刻只能跑一路协议，另一路必须挂起或退避。我做完几个项目之后的经验是：绝大多数物联网场景都能接受“时分复用”，因为 BLE 连接事件的间隔是毫秒级，私有 2.4G 的收发窗口也是毫秒甚至亚毫秒级，只要软件调度合理，两路数据不会互相饿死。

真的上了双天线，反而要处理天线间隔离度、两个馈点之间的串扰、PCB 面积翻倍等问题。除非产品有“全双工并发”的硬性指标，否则优先选单天线共用。

4.2 协议栈调度：让 BLE 连接事件和私有 2.4G 时隙不打架

软件上最容易翻车的点是两套协议栈同时申请射频资源。以 BLE 为例，协议栈会产生周期性连接事件，每个事件内要完成收发和 ACK 处理；私有 2.4G 也有自己的收发时隙。如果两个事件撞在一起，芯片的射频仲裁单元必须决定谁先上。处理不好，轻则私有时隙丢包，重则 BLE 连续错过连接事件导致触发超时断连。

我的做法是把私有 2.4G 的周期性收发窗口刻意错开 BLE 连接事件的时间中心。举例，BLE 连接间隔配 30ms，私有 2.4G 接收窗口每 20ms 一次，那就把私有窗口安排在两次 BLE 连接事件的中间段，并预留 1ms 保护时间。SDK 里如果支持射频事件优先级配置，我会把私有 2.4G 的关键时隙设为高优先级，BLE 连接事件设成可跳过一个周期，但要确保在一个 supervision timeout 周期内至少成功处理够次数。

还有一个容易忽略的点：协议切换以后，射频频率和调制参数要重新加载，这需要十几到几十微秒的稳定时间。我在调试时遇到过切换完立刻发包导致首包 CRC 错误的情况，后来在切换后加了一个短延时，问题就消失了。这种问题在仿真阶段暴露不出来，只有上了实际射频环境才会现形。

4.3 功耗预算实例：小电池方案下的平均电流估算

双模芯片最容易被吐槽的往往是功耗。我按一个纽扣电池供电的传感器标签来估算一下典型工况，参数如下表：

平均电流的计算方式为：BLE 广播部分，1.2ms 除以 1000ms，再乘以 15mA，约等于 18uA。私有 2.4G 接收部分，0.6ms 除以 300ms 得 0.002，乘以 18mA，约等于 36uA。MCU 处理部分，每次唤醒 2ms，按 300ms 周期折算，2ms / 300ms × 12mA，约等于 80uA。三项加底电流，平均不到 140uA。如果电池容量是 100mAh，理论续航大约 700 到 750 小时，接近 30 天。这里还没算上报时的发射电流，如果每 5 分钟上报一次，每次发射 2ms，平均贡献的电流其实只有零点几微安。

从这个预算能看出，真正的功耗大头不是无线发射，而是周期性唤醒后的 MCU 处理时间。所以优化方向应该放在减少无谓唤醒、合并 BLE 事件和私有 2.4G 事件、尽量把数据处理压缩到同一次唤醒窗口里。双模芯片的价值恰好在这里，两套射频事件可以共用 MCU 唤醒，而不是像分离方案那样各醒各的，这也是集成设计在功耗上最明显的好处。

5. 系统级芯片（SoC）给了嵌入式开发者什么

5.1 MCU、存储与低功耗模式：集成度带来的开发模式变化

OM6625A 这类双模芯片既然叫系统级芯片，说明无线之外还集成了完整的 MCU 子系统。通常包括一个 Cortex-M 核心、几十到几百 K 的 SRAM 和 Flash，以及标准的 DMA、中断控制器和低功耗管理单元。对开发者来说，这意味着单颗芯片就能跑完整的应用代码，不需要再挂外部 MCU。

开发模式也随之改变。以前用“无线芯片 + 外部 MCU”的方案，两边要协商通信协议，要处理唤醒握手、数据校验、串口波特率匹配，出了问题很难判断是哪一侧的责任。集成之后，一套工具链编译整个固件，应用逻辑和无线协议栈共享内存和调试接口，断点可以打在射频回调函数里。debug 体验提升一个档次。

低功耗模式方面，双模 SoC 一般会提供 sleep、deep sleep、shutdown 档位。我的建议是：如果产品允许，尽量把“待机不掉线”的需求做成由射频定时器唤醒，而不是让 MCU 一直轮询。把私有 2.4G 的监听窗口和 BLE 的广播事件都挂在硬件定时器上，MCU 闭眼睡，到点自动醒，单次处理完再睡，这样能把平均电流压低很多。

5.2 常用外设、封装与硬件设计要点

既然要做产品，外设资源得够用。双模 SoC 最常见的外设配置是 UART、SPI、I2C、ADC、PWM、GPIO，这些已经覆盖传感器读取、屏幕驱动、电机控制、电平采集大多数场景。封装上，双模芯片通常会控制在 QFN 32 到 56 脚之间，引脚过少会影响射频测试点布置和外设扩展，过多又会牺牲面积，选型时重点看 GPIO 数量和 ADC 通道是否满足你的传感器数量。

硬件设计上，双模 SoC 和普通 MCU 最大的差别在于射频部分。晶振要靠近芯片，负载电容按数据手册校准；天线馈线的阻抗要控制在 50 欧姆；匹配网络要预留 π 型拓扑的调试焊盘，方便量产时调整。不要只照着参考设计抄，板厂板材、走线厚度、参考地平面变化都会让匹配偏移，第一次打样后必须实测 S11。

5.3 和传统单模系统级芯片的对比：不只是多一个射频链路

很多人会先看传统单模系统级芯片，比如 LM10xx 这类以低功耗 BLE 为卖点的产品。对比下来，单模方案的优点是体积极小、协议栈专门为 BLE 优化、功能上非常聚焦，适合纯手机互联产品。问题在于，如果你的产品需要私有 2.4G 组网，它只能外挂射频芯片，或者放弃私有通道，于是又回到分离方案的路子上。

OM6625A 这类双模 SoC 多出来的不只是第二个射频链路，而是把两套协议栈、统一的射频调度、共享的天线匹配和低功耗管理做在了一起。单模芯片省的是单点功耗，双模芯片省的是“系统复杂度”。尤其在国内物联网场景里，mesh 私有协议 + BLE 近场调试已经是很多产品的标配组合，双模比分离方案更容易控制成本和生产一致性。

换句话说，选型不应该问“哪颗芯片功耗更低”，而应该问“我的系统总功耗、总面积、总成本谁更低”。双模芯片可能在某个单项指标上不是最极限的，但把它放进完整产品框架里算账，优势往往就出来了。

6. 实际开发调试中的经验与建议

6.1 两套调试工具链：BLE 抓包很容易，私有 2.4G 只能靠日志

开发双模产品，最现实的问题是调试工具不对称。BLE 这侧，花几百块买个 BLE 嗅探器，或者直接用支持蓝牙抓包的手机，配合 Wireshark 就能看到连接事件、广播报文、服务发现流程，排查问题非常直观。

私有 2.4G 这侧则几乎没有现成抓包器。厂商不做，第三方也没法做，因为协议不公开。我的做法有两套：一套是在固件里打详细的事件日志，把所有收发时间戳、CRC 结果、信道号、RSSI 打印到串口；另一套是用频谱仪或矢量信号分析仪看射频能量，配合自己写的解析工具对基带数据进行离线分析。有一套能随时导出的“空中日志”机制，做 mesh 中继调试时能省很多时间。

另外，RSSI 和频偏这两个指标建议在上电自检阶段就打印出来。私有 2.4G 的中继节点散布在房间里，单靠“包能收到”很难定位弱信号节点，有 RSSI 变化曲线才能判断是距离问题还是天线盲区问题。

6.2 布板与天线匹配：双模芯片容易踩的射频坑

双模芯片的射频布板，和单模 BLE 基本类似，但更容易踩两个坑。第一个是天线净空区被双模功能挤占。不少产品既要 BLE 又要私有 2.4G，功能越加越多，板子越来越满，天线区域最后只剩一条窄缝。实测这种设计的辐射效率通常很差，频偏和灵敏度都受影响。我会在布局阶段就给天线留足空间，宁可牺牲一点电池位置也不要压缩净空。

第二个坑是电池、金属外壳、FPC 排线等部件对天线的影响。在调试时我用网络分析仪看过一个产品，天线匹配调好了，但盖上外壳后谐振点偏移了 20MHz 以上，原因是外壳内侧的金属涂层改变了天线的等效环境。双模芯片既然支持两套协议，天线就得同时照顾全频段，外壳打样后一定要复测 S11 和空中有源性能。

6.3 量产测试与认证前的自测清单

量产测试不能省，尤其双模产品比单模多了私有 2.4G 这一路射频，测试项自然要多一倍。我一般会在产测固件里加入几个固定功能：BLE 广播强度检测、私有 2.4G 指定信道回环测试、频偏测量、Flash 读写校验。

认证前自测时，重点盯三个指标：传导发射功率是否在 10dBm 以下但足够稳定、带外杂散是否超标、接收灵敏度是否达到标称值。这三个指标如果有余量，SRRC 测试的返工概率会小很多。还要注意，某些无线测试设备在测私有 2.4G 协议时需要把设备配置成连续发射模式，产测固件里要留这个入口。

还要提一点：双模切换瞬间可能产生额外的频谱杂散。我遇到过切换瞬间杂散超标的情况，后来通过调整射频 LDO 的上电时序和 PA 的开启/关闭斜坡时间解决了。这个问题在预测试时非常容易暴露，建议留有 GPIO 口接一个示波器探头观察切换时序。

6.4 几个高频问题的排查思路

最后把几个我实际遇到的高频问题列一下，给更多人做参考。

第一类是“双模切换后丢包”。先别急着改软件，用示波器抓切换引脚的时序，看射频开关和 PA 使能是不是有重叠，再在协议栈里加切换稳定延时。大部分情况下是硬件切换时序和软件配置没对齐。

第二类是“BLE 经常断连，私有 2.4G 却正常”。这种一般不是射频问题，而是私有 2.4G 的收发任务占用射频时间太长，导致 BLE 连接事件被频繁跳过，超出 supervision timeout。解决方法要么缩短私有 2.4G 占用时间，要么把 BLE 连接间隔调大，要么把私有 2.4G 的收发窗口挪到连接事件间隙。

第三类是“两个相同产品靠得太近，私有 2.4G 互相干扰”。检查跳频表是否一致、有没有随机化频点，以及载波侦听有没有做。高密度场景下，随机化跳频顺序比固定跳频表可靠得多。

第四类是“手机连上 BLE 之后，私有 2.4G 的延迟明显变大”。这是很常见的时分复用效应，BLE 扫描和连接事件会插入私有收发窗口。我会在做产品配置时，把手机的 BLE 连接间隔拉到允许的最大值，或者只保留定向扫描而非连续扫描，给私有 2.4G 留出充分的空口时间。

如果你正在评估双模方案，我的建议是先把你最核心的那个场景做成一张时序表，把 BLE 事件和私有 2.4G 事件都标出来，再看芯片的射频仲裁能不能容下这个排布。多数双模芯片的坑，都能在画板之前用一张纸算清楚。