像做IoT的硬件工程师几乎都遇到过这种尴尬设备要上云要本地组网还要方便产线调试。结果一看方案Wi-Fi模组挂一个蓝牙模组挂一个LTE模组再挂一个。三个模块挤在一块主板上天线互相抢位置电源纹波互相干扰驱动代码各写各的开局一个网关项目硬生生做成了三个嵌入式项目。最近我评估了一款把Wi-Fi、Bluetooth、LTE三种通信能力集成到一起的Companion Module配套通信模块简单说就是一颗通信协处理器把三条链路的管理全部收编。这个思路很对我的胃口这篇就顺着这个模块聊聊IoT设备选通信方案时那些绕不开的设计决策和实操细节。这类模块对应的是典型的IoT网关、工业数据采集器、资产追踪器、便携医疗设备等场景。主控MCU只负责业务逻辑所有网络接入、协议栈、连接维护都交给通信模块处理。比如一个冷链运输记录仪平时用LTE回传温度数据到了仓库用Wi-Fi批量同步历史记录工程师靠近设备时用蓝牙现场配置参数。三个场景三种制式一个模块全搞定。对做产品的人来说最大的价值是省掉了射频前端设计的巨大工作量天线匹配、阻抗调节、认证测试这些硬骨头模块厂商基本都啃完了。1. 模块化通信方案的思路拆解1.1 为什么会有Companion Module这种形态传统IoT设备的通信方案大部分工程师第一反应是主控直接集成通信芯片。比如用一颗带Wi-Fi的SoC做主控Wi-Fi有了但蓝牙和LTE还是没有再加一颗LTE模组就得通过USB或UART挂上去。这么做的麻烦在于每一路通信都有独立的协议栈、独立的电源管理、独立的天线系统主控要同时伺候好几路中断和数据流软件复杂度直线上升。Companion Module解决的就是这个多路通信伺候不过来的问题。它里面通常有一颗专门的通信SoC自带协议栈和网络管理能力对外通过串口、SPI或SDIO跟主控打交道。主控只需要发指令、收数据不用关心底层是Wi-Fi在传还是LTE在传。模块内部反而可以做很多智能调度比如Wi-Fi断了自动切LTE蓝牙广播的同时保持Wi-Fi连接不掉线。这是单芯片集成方案很难做到的——不是性能不够而是工程复杂度全堆在应用层了。1.2 三条链路在IoT场景里的分工Wi-Fi、蓝牙、LTE在IoT设备里的角色完全不同选型时必须想清楚各自承担什么任务。LTE是远程生命线。设备部署在野外、车辆、海上、偏远工厂没有任何本地网络设施数据全靠运营商基站传。关键特征是覆盖广、移动性好但功耗高、有流量成本。IoT设备常用的LTE制式有Cat.1、Cat.M1和NB-IoTCat.1带宽够能跑语音和中等速率数据Cat.M1和NB-IoT主打低功耗和深度覆盖但速率低。模块里如果支持Cat.1基本能满足大部分远程数据回传场景。Wi-Fi是本地带宽出口。设备如果在室内或园区Wi-Fi能提供远超LTE的吞吐量而且不产生蜂窝流量费用。比如产线设备批量上传日志、视频监控设备回传画面走Wi-Fi明显更划算。Wi-Fi的问题是需要热点或路由器配套没法在野外独立覆盖。蓝牙是近场运维通道。产线巡检员拿手机靠近设备用蓝牙小程序看状态、改参数、升级固件不需要接线不需要设备联网。这个能力在量产和售后环节特别重要——一台已经部署在现场的设备如果配置错了没有蓝牙你只能派工程师拆机成本高得吓人。1.3 Companion Module对比分体方案的三个核心优势把三条链路塞进一个模块不只是省面积这么简单还有三个容易被忽略的好处。第一是天线管理的统一调度。三个制式挤在一个设备里射频信号互相干扰的问题非常棘手。模块内部会做共存协调比如Wi-Fi和蓝牙共用天线时的时分切换LTE上行时避开Wi-Fi的信标监听窗口。如果三个模块是分开采购的共存机制几乎没法做——每个模块只知道自己什么时候发射不知道旁边在发什么。第二是功耗策略的统一规划。休眠模式下模块可以同时管理三路通信的唤醒策略LTE保持轻连接、Wi-Fi关断信标监听、蓝牙保持可发现广播整体电流比三个独立模块联动低得多。这一点在做电池供电的设备时非常关键。第三是认证成本的收敛。LTE需要入网认证Wi-Fi需要Wi-Fi联盟认证蓝牙需要SIG认证如果三个模块分开搞认证周期和费用翻三倍。Companion Module的厂商通常会预先把这些认证做完设备厂商只需要做整机的FCC/CE级别认证省掉大头的通信模块认证开销。2. 核心硬件设计细节和链路预算2.1 模块内部架构和对外接口我看了模块的参考设计内部结构大致是这样主通信SoC典型是Cortex-M4或M33内核跑协议栈和网络应用外挂一块LTE射频前端PA、滤波器、收发器Wi-Fi和蓝牙则集成在SoC内部或者共用一颗2.4GHz射频芯片。对外接口一般提供至少两路UART、一路SPI、一路I2C再加上SIM卡接口和天线接口。UART用来跑AT指令或透传数据SPI/ SDIO可以接高速数据流——比如Wi-Fi的原始TCP/IP数据走SDIO吞吐量比UART高一个数量级。模块的BOOT脚、RESET脚、状态指示脚、唤醒脚是必须要引出来的做产品设计时至少留出3个GPIO给模块的状态交互不然调试的时候会非常痛苦。2.2 天线方案和射频链路预算天线是IoT设备射频设计里最容易翻车的环节。Companion Module通常推荐两种天线方案板载天线或外置天线。板载天线省成本、省装配工序但天线周围不能铺铜、不能走线、不能放金属件这对结构设计的要求极高。外置天线IPEX座外接天线灵活性高但装配成本和故障率也高尤其是防水的设备天线穿壳的地方很容易出问题。射频链路预算可以从模块标称灵敏度倒推比如LTE接收灵敏度-101dBm实际带内典型值天线口到芯片的插损如果做到1dB以内整机灵敏度大约-100dBm。如果天线附近有金属遮挡或者走线太长插损会飙升到3-5dB灵敏度直接掉到-96dBm甚至更低。这个差距在城市里可能就是从满格信号变成经常掉线。所以做结构堆叠的时候我建议在原理图阶段就锁定天线位置和走线空间等画完板再想挪天线基本都是大改动。模块厂商提供的天线净空区参考设计一定要严格遵守净空区里的铺铜和过孔不是你想加就能加的。2.3 功耗预算的实测数据参考电池供电的IoT设备功耗预算是生死线。我把模块在几种典型状态下的电流数据整理了一下基于3.8V锂电池供电可以当个参考基准工作状态电流平均值说明深度休眠10-20μA仅保留RTC和唤醒源蓝牙广播间隔100ms30-60μA依赖广播参数配置蓝牙连接但空闲80-150μA保持连接无数据传输Wi-Fi DTIM3待机0.8-1.5mA周期监听信标Wi-Fi 持续传输70-90mA实际吞吐约5-8MBpsLTE Cat.1 空闲附着3-5mA取决于网络寻呼周期LTE Cat.1 持续传输100-180mA上行时峰值可达400mA以上注意LTE持续传输的峰值电流模块发射功率高的时候能拉到400mA以上这会导致电池电压瞬间跌落。有些设备在LTE上传时莫名重启十有八九就是电源路径的压降没核算清楚——电池内阻加板级阻抗如果超过200mΩ0.4A的瞬间电流就会产生80mV以上的压降如果电池已经接近低压保护点直接触发欠压重启。2.4 主控协同的电路设计要点主控和Companion Module的接口电路我有几个固定的设计习惯。第一个是电平匹配模块的IO电压通常是1.8V或3.3V跟主控不一致时必须加电平转换不要图省事直接分压——信号速率高的时候分压电路边沿变缓UART波特率1Mbps以上容易误码。第二个是电源滤波模块的电源脚要加磁珠加多级电容避免通信发射时的电流脉动污染主控的模拟电源。第三个是复位和唤醒逻辑尽量用主控GPIO硬控制模块的RESET不要依赖软件AT指令复位死机的时候软件复位不干净。3. 软件配置与网络接入实操3.1 三种制式的初始化流程模块上电后建议按蓝牙- Wi-Fi- LTE的顺序初始化。先启动蓝牙因为它最快几毫秒就能开始广播方便产线用手机直接连接调试然后启动Wi-Fi扫描并连接预设的热点最后启动LTE注册网络并建立PDP上下文。这个顺序的好处是即使后面Wi-Fi和LTE都配置失败至少蓝牙是通的工程师能通过蓝牙登录模块的调试接口排查问题。初始化用AT指令集演示一下UART默认波特率115200,8N1ATCWMODE1 // Wi-Fi Station模式 ATCWJAPMyAP,password123 // 连接热点 ATCFUN1 // LTE射频功能开启 ATCOPS0 // 自动选网 ATCGDCONT1,IP,cmnet // 配置APN ATCGACT1,1 // 激活PDP上下文 ATCGATT1 // 附着网络每一条指令都要等模块返回OK或ERROR后再发下一条不要一次性把所有指令丢进去。串口缓冲有限指令积压会丢数据。3.2 LTE网络接入的参数设置与计算LTE配置里APN是关键。APN是运营商分配的网络接入点国内三大运营商的公共APN一般是移动cmnet、联通3gnet、电信ctnet。如果走物联网卡APN可能是定制的比如某些车联网卡用CMIOT。APN配错了PDP上下文激活会失败也就是常说的有信号但上不了网。Cat.1模块还要配置频段国内常用LTE B12100MHz、B31800MHz、B5850MHz、B8900MHz、B402300MHz、B412555MHz。默认配置一般是全频段自动搜索但如果你明知设备只在国内用可以手动关闭国际漫游频段加快搜网速度。搜网慢的排查优先看是不是频段太多导致扫频耗时长。APN配置示例ATCGDCONT1,IP,cmnet,,0,0 ATCGPIAF1,1,,0 // 设置PDP地址为IPv4优先 ATCGACT1,1激活后可以用ATCGPADDR1查询分配的IP地址。如果拿到的是10.x.x.x开头的地址说明APN配置成功如果一直是0.0.0.0说明PDP激活失败要去查SIM卡是否欠费、APN是否正确、模块是否插紧。3.3 Wi-Fi配网和蓝牙调试链路的工程实践Wi-Fi配网是IoT设备使用体验的分水岭。消费级设备常用手机App把Wi-Fi SSID和密码通过蓝牙或SoftAP方式传给设备。Companion Module支持两种方式一种是模块临时开启SoftAP手机连上后通过HTTP把Wi-Fi信息POST过去模块再切换到Station模式去连接路由器另一种更方便走蓝牙GATT服务在Service里定义几个Characteristic分别写入SSID、密码、连接触发标志。我在项目里更偏好蓝牙配网。原因很简单SoftAP配网需要用户切换手机Wi-Fi容易连错热点路由器热点名字有时候会干扰体验繁琐。蓝牙配网只要App拿到蓝牙权限搜索设备写入参数设备自动切换全程无感。蓝牙GATT服务和Wi-Fi控制的代码逻辑大致如下蓝牙GATT服务定义 - Service UUID: 0xFFE0 - Characteristic SSID: UUID 0xFFE1, 属性Write, 长度32字节 - Characteristic PASS: UUID 0xFFE2, 属性Write, 长度64字节 - Characteristic CTRL: UUID 0xFFE3, 属性WriteNotify, 长度1字节 写入CTRL0x01表示开始连接Wi-Fi 连接成功后模块通过Notify上报状态码0x00成功, 0x01密码错误, 0x02热点未找到。这个服务定义可以在量产前用手机App或nRF Connect工具实测确认读写正常再固件化。3.4 数据上行链路与OTA升级的处理数据上行路径一般有两种方式。简单设备走UART透传模块把TCP/UDP数据直接透传到云端主控什么都不用管。复杂设备走SPI/SDIO AT命令集主控更精细地控制连接和数据流。TCP长连接的保活参数要重点调优。嵌入式设备的TCP连接经常被运营商NAT超时踢掉一般运营商NAT映射超时在5分钟到30分钟不等。设备端的心跳间隔如果设置成60秒比较稳但也要兼顾功耗——心跳越频繁设备越难深度休眠。平衡做法是自适应心跳连接刚建立时每30秒发一次心跳持续5分钟稳定后拉长到5分钟一次如果发现连接被断开发数据无ACK立即重连并恢复短心跳。OTA升级的设计更考验模块架构。推荐采用双分区断点续传方案模块把固件包分段写入Flash的备份分区下载过程中意外断电重启后从断点续传下载完成后做完整性校验通过才切换启动分区。代码逻辑上注意模块每次写Flash之前要擦除扇区擦除期间不能有数据写入否则会丢包。4. 系统集成中的关键问题与排查技巧4.1 天线布局的工程禁忌天线布局是Companion Module项目里最容易出问题的环节。我见过最典型的案例一个带金属外壳的网关设备工程师把天线放在金属壳正下方灵敏度掉了15dB整机变成信号残疾。几个硬性要求可以记下来天线净空区至少保证6mm以上无铺铜、无走线天线距离金属外壳至少10mm天线馈点与模块射频口之间的微带线阻抗控制在50Ω且走线不要超过20mm避免天线正下方走高速数字线否则数字谐波会干扰接收灵敏度调试时用网络分析仪看S11参数保证天线在工作频段反射系数低于-8dB——也就是驻波比低于2.3:1。如果没有网分可以用最土的办法贴近天线用手摸信号变好说明天线失谐严重人和手变成了地平面的一部分这往往就是净空区不够。4.2 Wi-Fi和蓝牙共存问题的实测心得Wi-Fi和蓝牙都在2.4GHz频段共存是个老生常谈但永远踩不完的坑。模块做了时分复用但软件层面依然要认真配置。比如蓝牙连接后如果Wi-Fi在做高吞吐传输蓝牙的广播和扫描必须让出时隙否则蓝牙会出现连上了但数据一去不回的情况。我在项目里遇到过几次蓝牙连接频繁断开排查到最后发现是Wi-Fi速率升级到MCS7高吞吐模式时射频发射时间变长挤占了蓝牙的接收窗口。解决办法是在模块配置里设置Wi-Fi的共存模式为WLAN_BT_SCO强制Wi-Fi在蓝牙事件期间让出时隙同时把蓝牙的连接间隔拉长到30ms以上减少两个协议的冲突概率。如果有多路天线参与比如Wi-Fi独立天线、蓝牙独立天线还要注意天线之间的空间隔离度至少要30dB否则Wi-Fi发射功率会直接烧掉蓝牙接收前端。实测可以用频谱仪看蓝牙接收频段的底噪抬升量。4.3 整机认证前必做的三项自测别等送实验室才做认证那等于花钱买教训。送去之前三个自测必须做第一是杂散发射预扫。用频谱仪在模块工作状态下扫描30MHz到6GHz看是否有超过法规限值的尖峰。Wi-Fi和LTE同时工作时最容易出现互调产物如果发现尖峰优先排查两个射频通道之间的隔离度。第二是接收灵敏度复测。用综测仪分别在LTE B3、B40和Wi-Fi 2.4GHz通道测一遍灵敏度和模块手册标称值对比差异超过3dB就要回去查天线匹配。第三是长时间老化测试。整机在LTE持续上传Wi-Fi持续下载同时跑48小时看有没有死机、掉线、过热。4.4 常见问题速查表现象可能原因排查建议LTE显示有信号但无法上网APN配置错误 / PDP激活失败用ATCGDCONT查看APNATCGACT激活确认PDP状态LTE频繁掉线信号弱 / 供电电压跌落看ATCSQ信号强度用示波器测模块供电脚电压跌落Wi-Fi连接但吞吐很低天线失谐 / 信道拥挤测S11驻波比换到1、6、11信道测试蓝牙连不上广播参数配置异常 / 共存冲突检查广播间隔确认Wi-Fi未占满射频时隙整机待机电流偏大模块未真正休眠 / 存在漏电路径拆下模块单独测休眠电流再逐步排查外围模块发热严重长时间高功率发射 / 充电和通信同时进行检查发射功率回退确认散热设计合理5. 从选型到量产的几点经验5.1 选型时别只看参数表拿到模块的datasheet先不要急着比参数。我建议先看参考设计和应用笔记——参考设计暴露了厂商真正关心的难点如果参考设计里把天线布局、电源去耦、EMI滤波画得很细说明厂商有丰富的量产经验如果参考设计只有个最小系统图后续你踩坑的概率会大很多。其次看量产手册和已知问题列表。正规模块厂商都会公布已发现的硬件勘误和软件bug这个比规格书更值钱——等于别人掏了几百万的学费你免费学。另外注意看模块的工作温度范围是商业级0~70℃还是工业级-40~85℃IoT设备经常部署在户外工业级是基本要求。5.2 AT指令日志和调试技巧实际调模块的时候强烈建议从一开始就建立完整的AT指令日志。把每一条发出的指令和模块返回的回答全部打上时间戳记录下来问题复现时回看日志十有八九能找到根因。LTE掉线问题的排查我会在日志里加一个定时查询ATCSQ信号强度和ATCEREG?网络注册状态的任务每10秒打一条。掉线瞬间看最后一条日志信号是还在还是已经衰落到-110dBm以下——两种情况处理方向完全不同前者查模块和网络侧的异常释放后者查天线和部署位置。Wi-Fi问题则要善用模块提供的调试断言信息连接失败时模块会返回错误码比如ERROR: 2表示密码错误ERROR: 3表示热点不存在ERROR: 4表示连接超时。这些错误码对照表在量产时是售后客服的宝贝——用户报障时先看错误码能拦下一大半误报。5.3 量产阶段的固件和测试策略量产阶段我的经验是给每条产线准备一个黄金测试件。这个设备装的是经过充分验证的标准固件任何新烧录的设备都拿它做对比基准。产线测试项目不用多但必须覆盖三条链路蓝牙广播能否被工装手机发现、Wi-Fi能否连上指定热点并完成回环通信、LTE能否注网并PING通云端服务器。三条过了再测一次唤醒电流和休眠电流基本就能放行。固件版本管理要和生产日期挂钩模块固件升级要留后门——比如通过串口bootloader强制升级或者通过蓝牙空中升级。设备出货后再发现固件bug能远程升级就远程升级不能远程升级的至少也要让售后能用蓝牙连上设备现场刷机这比拆机返厂省太多了。我个人踩过最大的坑是没在量产前做弱信号环境测试结果设备在信号差的仓库里频繁掉线用户投诉后才紧急提OTA修复。从那以后我每做一个新产品都会在测试阶段专门跑到地下室、电梯口、钢筋混凝土结构的建筑里做信号测试把真实环境的链路余量测清楚。Companion Module这类产品选得好能把通信复杂度从主控工程里剥离出来但设备整机的稳健性还是得靠板级设计和测试的扎实程度两者缺一不可。