1. 从一堆热词里看LoRa自组网的真实需求先把标题拆开看LoRa 自组网设备原理深度分析。这里面有三个关键词——LoRa、自组网、设备原理。热词列表里还混进来一堆 RS485、IAP、嵌入式、STM32WLE5、HC32L136 之类的词说明关注这个话题的人大概率是搞嵌入式硬件或者做工业现场通信的工程师而不是纯做应用层开发的人。我先把结论摆在前面LoRa 自组网设备的核心价值不是通信距离远这一个点而是在无运营商网络覆盖、无固定供电、节点数量多且分散的场景下用极低的功耗和极低的维护成本把数据从末端节点汇聚到网关。这句话听起来像废话但你真正做过现场部署就知道能同时满足远距离低功耗多节点免布线这四个条件的无线方案其实没几个。LoRa 本身的物理层特性决定了它的定位。它用的是扩频调制Chirp Spread Spectrum在相同发射功率下接收灵敏度比传统 FSK 高出 20dB 左右。这个 20dB 是什么概念发射端功率不变接收端能多收到大约 10 倍的信号强度余量或者说通信距离理论上能拉到原来的 3 倍以上。代价是速率低典型配置下 125kHz 带宽、SF7 到 SF12空中速率从 5.5kbps 一路降到 0.3kbps 左右。所以 LoRa 从来不是用来传视频、传大文件的它就是传几十字节的传感器数据。那自组网又是什么意思很多人一听到自组网就想到 Mesh觉得节点之间要互相转发、动态路由。但 LoRa 自组网在工业场景里绝大多数实现其实是星型拓扑 中继扩展而不是真正意义上的多跳 Mesh。原因很现实LoRa 的占空比限制、信道冲突、路由维护开销都会让多跳 Mesh 的复杂度急剧上升。一个 100 节点的 LoRa Mesh光是路由表的同步和冲突退避就能把工程师折腾到怀疑人生。所以市面上能落地的 LoRa 自组网设备通常是网关 若干节点 可选中继的结构节点自动入网、自动分配地址、自动上报网关负责汇聚和转发。这篇文章我打算按实际做项目的思路来写先讲整体架构怎么设计再拆核心细节然后是实操流程最后是踩坑记录。适合正在选型 LoRa 方案、或者已经拿到模块但不知道怎么组网的嵌入式工程师看。如果你只是想调通两个模块之间的点对点通信那这篇文章可能有点重但如果你要做的是几十上百个节点的现场部署那下面的内容应该能帮你少走不少弯路。2. 整体架构设计与方案选型思路2.1 为什么大多数LoRa自组网最终都做成了星型先讲一个我自己的经历。早年做过一个农业大棚的项目客户一开始要求节点之间能互相转发最远的节点离网关有 3 公里。我们当时兴致勃勃地设计了一套三跳 Mesh 路由结果现场一测问题全出来了节点之间的链路质量随天气、作物高度、大棚金属骨架变化剧烈路由表一天要重建好几次而且 LoRa 的空中速率本来就低每多一跳延迟就翻倍一个数据从最远节点到网关要等好几秒。后来我们改成了星型 一个固定中继的方案反而稳定了。原因很简单LoRa 的链路预算足够大在大多数现场单跳就能覆盖 1 到 3 公里真正需要多跳的场景其实很少。与其花大力气做动态路由不如把网关的天线架高一点、把节点的发射功率调到位、把扩频因子选对。所以现在我做 LoRa 自组网默认架构是这样的网关Gateway负责汇聚所有节点数据通过 4G、以太网或者 RS485 上行到服务器或本地控制器。网关通常用性能强一点的 MCU比如 STM32F4 或者带 Linux 的方案。节点Node末端传感器节点MCU 用低功耗系列比如 STM32WLE5内置 LoRa 射频、HC32L136、GD32 等负责采集数据并定时上报。中继Repeater可选放在链路质量差的位置做一次转发。中继可以是独立设备也可以让某个供电充足的节点兼任。这个架构的好处是逻辑简单、维护成本低、故障定位容易。坏处是网关的覆盖半径有限超出范围的节点需要中继。但对于大多数工业现场来说这个取舍是划算的。2.2 射频参数怎么选SF、BW、CR 的取舍逻辑LoRa 的射频参数直接决定了通信距离、速率和抗干扰能力。这三个参数是参数含义增大后的影响SF扩频因子每个符号携带的比特数7~12距离更远速率更低空中时间更长BW带宽信道带宽常见 125/250/500kHz速率更高灵敏度下降距离变短CR编码率前向纠错比例4/5~4/8抗干扰更强开销更大我一般按这个顺序来定先定距离需求再定速率需求最后定抗干扰需求。如果节点离网关 1 公里以内SF7、BW125 就够了空中速率 5.5kbps传 20 字节数据不到 50ms。如果距离 3 公里以上或者中间有遮挡就要上 SF10 到 SF12速率降到 1kbps 以下传同样的数据要几百毫秒甚至一秒多。这里有个很多人忽略的点SF 越大空中时间越长节点占用的信道时间就越多。如果一个网关下面挂了 100 个节点每个节点都用 SF12那信道会非常拥挤碰撞概率急剧上升。所以实际项目中我会根据节点到网关的距离给不同节点分配不同的 SF近的用 SF7远的用 SF10这叫自适应数据速率ADR。ADR 在 LoRaWAN 里是标准功能但在私有协议里需要自己实现。BW 的选择相对简单国内 470MHz 频段一般用 125kHz少数场景用 250kHz 换速率。500kHz 在国内用得少因为占空比和法规限制。CR 我通常用 4/5也就是每 4 个有效比特加 1 个纠错比特。如果现场干扰特别严重可以上 4/8但速率会掉一半。实测下来工业现场用 4/5 基本够用除非旁边有大功率电机或者变频器。2.3 自组网协议栈私有协议还是LoRaWAN这是选型时绕不开的问题。LoRaWAN 是标准协议有完整的入网、加密、ADR、Class A/B/C 定义生态成熟网关和服务器都有现成方案。但它有几个重的地方入网流程需要 OTAA 或 ABPOTAA 要多次交互节点首次入网慢。协议栈代码量大对低端 MCU 不友好。服务器端需要 Network Server、Join Server、Application Server部署复杂。在国内 470MHz 频段LoRaWAN 的某些参数配置需要调整才能合规。私有协议则完全相反代码量小、入网快、参数随便调但所有东西都要自己写包括地址分配、确认重传、加密、固件升级。我的经验是如果节点数量在 50 个以内、场景固定、不需要跟第三方平台对接私有协议更省事。如果节点上百、需要跟云平台对接、或者客户明确要求标准协议那就上 LoRaWAN。热词里出现了stm32wle5 lora smart tdma 完整协议栈工程实现说明有人在做 TDMA 的私有协议。TDMA 在 LoRa 自组网里确实是个好思路给每个节点分配固定的时隙避免随机接入的碰撞。但 TDMA 需要全网时间同步而 LoRa 的空中时间又长同步开销不小。我见过做得好的 TDMA 方案网关周期性发信标节点根据信标对齐时隙效果不错但实现难度比纯 ALOHA 高一个量级。3. 核心细节解析与实操要点3.1 节点入网与地址分配IAP和Flash的坑热词里有个很有意思的词iap boot里面定义的变量复位后会怎样。这个问题跟 LoRa 自组网设备关系很大因为节点通常需要支持远程固件升级OTA而 OTA 的基础就是 IAPIn-Application Programming。先说 IAP 的基本结构MCU 的 Flash 分成 Bootloader 区和 Application 区。Bootloader 负责接收新固件、校验、写入 Application 区然后跳转。Application 区就是正常运行的业务代码。这里有个经典坑Bootloader 里定义的全局变量在跳转到 Application 之后如果发生复位这些变量的值会怎样答案是取决于复位类型和变量存储位置。如果变量在 RAM 里普通复位看门狗、软件复位不会清 RAM值可能保留但上电复位会清 RAM值丢失。如果变量在 Flash 里比如用const或者指定到特定段复位后值保留但要注意 Flash 写入次数限制。如果变量在备份寄存器Backup Register里只要 VBAT 供电不断复位后值保留。我实际做 OTA 时会在 Bootloader 里用一个备份寄存器存升级标志。Application 收到升级命令后写标志、复位Bootloader 启动时读标志如果标志有效就进入升级模式否则跳转 Application。这样即使中途断电标志也不会丢只要 VBAT 有电。另一个坑是中断向量表的偏移。Application 区的起始地址不是 0x08000000而是 Bootloader 之后比如 0x08008000。这时候 Application 里必须设置SCB-VTOR 0x08008000否则中断会跳到 Bootloader 的向量表直接跑飞。这个坑我踩过不止一次尤其是用 HAL 库的时候SystemInit里默认设的是 0x08000000需要手动改。对于 LoRa 节点来说OTA 还有个特殊问题LoRa 速率低固件大。一个 100KB 的固件用 SF10、BW125 传空中速率大概 1kbps理论上要 800 秒实际加上协议开销和重传可能要 20 分钟以上。所以 LoRa OTA 通常采用分片传输 断点续传而且要在节点供电充足的时候做。我一般会把 OTA 设计成网关主动推送 节点确认的模式而不是节点主动拉取这样网关可以控制升级节奏避免所有节点同时升级把信道占满。3.2 RS485与LoRa的配合为什么很多设备要带485接口热词里 RS485 出现的频率极高rs485组网、rs485电路、rs485自动换向电路、rs485与rs232协议详解及modbus通信指南说明很多人关心的不是纯 LoRa而是LoRa RS485 的组合设备。这个组合的逻辑很清晰工业现场大量传感器、PLC、仪表都是 RS485 接口走 Modbus RTU 协议。LoRa 自组网设备如果带一路 RS485就可以直接接这些设备把 Modbus 数据透传或者解析后通过 LoRa 发出去。这样既不用改原有设备又能实现无线化。RS485 电路设计有几个关键点收发切换RS485 是半双工发送和接收不能同时。传统方案用 MCU 的 GPIO 控制 DE/RE 引脚但这样软件开销大时序容易出错。现在常用自动换向电路用三极管或者专用芯片根据 TX 信号自动控制 DEMCU 只管发数据就行。保护电路现场环境恶劣RS485 总线容易受浪涌、静电、共模电压影响。TVS 管、共模电感、自恢复保险丝是标配。我见过没加保护的板子雷雨天一打就烧一片。终端电阻RS485 总线两端要接 120 欧姆终端电阻中间节点不接。很多人忘记这个导致通信距离短、误码率高。AB 线极性热词里有人问rs485的ab波形哪种才是正确的。标准定义是 A 线比 B 线高时表示逻辑 1但实际芯片标注可能相反接线前一定要看手册或者用示波器确认。LoRa 设备接 RS485 传感器时典型流程是MCU 通过 RS485 发 Modbus 查询帧等传感器回复解析数据打包成 LoRa 帧发出去。这里要注意超时设置Modbus 回复有延迟如果超时设太短会误判传感器离线设太长又影响 LoRa 上报周期。我一般设 200ms 到 500ms根据传感器手册调整。3.3 低功耗设计节点怎么做到电池撑几年LoRa 节点很多是电池供电低功耗是核心指标。一个设计良好的节点平均电流可以做到几十微安用 2000mAh 的锂亚电池能撑 3 到 5 年。低功耗的关键是让 MCU 和射频大部分时间都在睡。典型的工作周期是这样的MCU 定时器唤醒比如每 5 分钟一次。采集传感器数据如果是 RS485 传感器还要给传感器供电、等预热。打开 LoRa 射频发送数据。等待网关确认如果需要确认。关闭射频和传感器电源MCU 进入 STOP 或 STANDBY 模式。这里面每个环节都有优化空间传感器供电很多传感器静态电流不小不能一直供电。用 MOS 管控制传感器电源只在采集时打开。LoRa 发射功率发射功率越大电流越大。20dBm 发射时电流可能 120mA而 14dBm 只有 40mA 左右。如果距离够没必要用最大功率。唤醒周期这是最大的变量。5 分钟一次和 1 小时一次平均电流差 10 倍以上。要根据实际需求定不要盲目追求实时。STANDBY 模式STM32 的 STANDBY 模式电流只有几微安但唤醒后相当于复位所有 RAM 丢失。STOP 模式电流几十微安但 RAM 保留。我一般用 STOP 模式因为唤醒后不用重新初始化。实测数据一个 STM32WLE5 节点每 5 分钟采集一次 RS485 传感器并上报发射功率 14dBm平均电流大约 80 微安。2000mAh 电池理论寿命 2000/0.08 25000 小时约 2.8 年。如果改成 15 分钟一次平均电流降到 30 微安左右寿命能到 7 年以上。4. 实操过程与核心环节实现4.1 硬件选型与最小系统搭建先列一下我做 LoRa 自组网设备时的典型物料清单部件选型说明主控射频STM32WLE5JC内置 LoRa 射频省一颗芯片适合节点网关主控STM32F407 或 Linux 方案需要处理多节点数据性能要够射频前端SX1262 或内置网关可用外置 PA 提升功率电源锂亚电池 LDO节点用注意 LDO 静态电流RS485SP3485 或 MAX3485带自动换向天线470MHz 弹簧天线或外置网关用高增益节点用小型最小系统搭建步骤供电检查先用稳压电源给板子供电测各路电压是否正常尤其是射频部分的 3.3V 要干净。晶振起振STM32WLE5 需要 32MHz 和 32.768kHz 晶振用示波器确认起振。SWD 连接确认能下载程序读到芯片 ID。射频校准用官方工具或者自己写代码校准射频的频偏和功率。点对点通信先让两个节点互相发数据确认射频链路通。这一步最容易出问题的是射频部分。LoRa 的射频电路对布局很敏感尤其是匹配网络。如果匹配没做好发射功率上不去接收灵敏度也差。我一般会先用频谱仪测发射频谱确认功率和频偏正常再测接收灵敏度。4.2 私有协议帧格式设计私有协议的核心是帧格式。我一般这样设计| 前导码 | 同步字 | 帧头 | 载荷 | CRC | | 8字节 | 2字节 | 4字节| N字节| 2字节|帧头里包含源地址2字节节点地址入网时分配。目的地址2字节网关地址通常是 0x0000。帧类型1字节入网请求、数据上报、确认、升级等。序列号1字节用于去重和确认。载荷根据帧类型不同而不同。数据上报帧的载荷就是传感器数据入网请求帧的载荷是节点唯一 ID比如 MCU 的 UID。入网流程节点上电发入网请求载荷带 UID。网关收到检查 UID 是否已注册。如果已注册回复入网成功带分配的短地址如果未注册根据策略决定是否允许。节点收到回复保存短地址进入正常上报模式。如果节点没收到回复随机延迟后重试避免所有节点同时入网。这里有个细节入网请求要用较低的 SF 和较高的功率因为节点还不知道自己离网关多远。入网成功后网关可以根据收到的信号质量指示节点调整 SF 和功率。4.3 网关数据汇聚与上行网关收到节点数据后要做几件事去重同一个序列号的数据只处理一次。时间戳给数据打上网关本地时间。缓存如果上行链路4G/以太网断了数据要缓存恢复后补传。上行通过 MQTT、Modbus TCP 或者自定义协议发给服务器。网关的缓存策略很重要。我一般用环形缓冲区存最近 10000 条数据。如果上行断了超过缓冲区容量最老的数据会被覆盖。对于关键数据可以加一个重要标志重要数据不覆盖。网关的另一个功能是下行控制。服务器可以通过网关给节点发命令比如修改上报周期、触发采集、启动 OTA。下行帧和上行帧用同样的格式只是方向相反。4.4 现场部署与信号测试设备做好了现场部署才是真正的考验。我的标准流程是现场勘测先带一个网关和一个节点到现场测信号。网关放在预定位置节点拿到各个角落记录 RSSI 和 SNR。确定网关位置网关尽量放高避开金属遮挡。如果现场有多个建筑可能需要多个网关或者中继。节点安装节点安装位置要避开金属、电机、变频器。天线尽量竖直不要贴着墙面。全网测试所有节点装好后观察一段时间的数据看有没有丢包、延迟异常。参数微调根据实测数据调整节点的 SF 和发射功率。这里有个经验RSSI 大于 -100dBm、SNR 大于 0dB 的链路基本能稳定通信。如果 RSSI 在 -110 到 -120 之间SNR 为负就要考虑加中继或者调整天线。5. 常见问题与排查技巧实录5.1 通信距离不达标怎么排查这是最常见的问题。排查顺序现象可能原因排查方法近距离能通远距离不通天线匹配差、功率不足频谱仪测发射功率白天通晚上不通干扰源变化扫频看背景噪声晴天通雨天不通湿度影响、天线进水检查天线密封某些节点不通遮挡、金属反射换位置测试全部不通网关故障、频点错误检查网关和频点配置我遇到过一个案例节点装在金属配电箱里信号出不来。后来把天线用馈线引到箱外问题解决。所以金属遮挡是 LoRa 最大的敌人比距离本身影响还大。5.2 丢包率高怎么办丢包率高通常是信道冲突或者链路质量差。解决思路降低上报频率如果所有节点都 1 分钟上报一次信道肯定挤。改成 5 分钟或者 10 分钟。错开上报时间给每个节点加一个随机延迟避免同时上报。调整 SF近的节点用低 SF减少空中时间。加确认重传重要数据加 ACK没收到就重传。但重传会增加信道负担要权衡。换频点如果现场有同频干扰换个频点试试。5.3 节点功耗异常怎么查功耗异常一般是某个环节没关干净。排查方法用高精度电流表比如 uCurrent测不同状态下的电流。确认 MCU 进入了低功耗模式。确认射频进入了 Sleep。确认传感器电源被切断。检查有没有悬空的 GPIO悬空引脚会漏电。我踩过一个坑某个 GPIO 配置成输入但没上拉浮空状态下电流多了几十微安。后来全部改成模拟输入或者输出低功耗才降下来。5.4 OTA升级失败怎么恢复OTA 失败最怕的是节点变砖。我的做法是Bootloader 永远不升级只升级 Application。Application 升级前先写一个升级中标志到备份寄存器。升级完成后清除标志。Bootloader 启动时如果发现升级中标志还在说明上次升级失败回滚到旧固件或者重新进入升级模式。这样即使升级中途断电节点也能恢复。另外Bootloader 要留一个串口或者 LoRa 的强制升级入口万一标志逻辑出问题还能手动救回来。6. 一些实际项目中的经验体会做 LoRa 自组网设备最深的体会是射频这东西理论是一回事现场是另一回事。你在实验室里调好的参数到现场可能完全不是那么回事。所以我的习惯是任何新方案先做小批量现场测试跑至少两周看数据稳定性再批量部署。另一个体会是不要过度设计。我见过有人非要在 LoRa 上跑 Mesh结果复杂度爆炸维护成本极高。其实大多数场景星型加中继就够了。把简单的事情做稳定比把复杂的事情做出来更有价值。最后分享一个小技巧网关加一个 RSSI 日志功能。每个节点每次上报网关都记录 RSSI 和 SNR。这样运行一段时间后你就能看到哪些节点链路质量在下降提前发现天线老化、遮挡物增加等问题。这个功能实现很简单但运维价值很大。这个内容后续还可以这样扩展如果你要做的是带定位功能的 LoRa 设备可以研究一下 LoRa 的到达时间差TDOA定位虽然精度不如 GPS但在室内或者 GPS 信号差的地方能派上用场。另外LoRa 和蓝牙、WiFi 的共存问题也值得关注尤其是网关同时带多种无线的时候射频干扰要提前规划。
LoRa自组网设备原理深度分析：架构、协议与低功耗实战
1. 从一堆热词里看LoRa自组网的真实需求先把标题拆开看LoRa 自组网设备原理深度分析。这里面有三个关键词——LoRa、自组网、设备原理。热词列表里还混进来一堆 RS485、IAP、嵌入式、STM32WLE5、HC32L136 之类的词说明关注这个话题的人大概率是搞嵌入式硬件或者做工业现场通信的工程师而不是纯做应用层开发的人。我先把结论摆在前面LoRa 自组网设备的核心价值不是通信距离远这一个点而是在无运营商网络覆盖、无固定供电、节点数量多且分散的场景下用极低的功耗和极低的维护成本把数据从末端节点汇聚到网关。这句话听起来像废话但你真正做过现场部署就知道能同时满足远距离低功耗多节点免布线这四个条件的无线方案其实没几个。LoRa 本身的物理层特性决定了它的定位。它用的是扩频调制Chirp Spread Spectrum在相同发射功率下接收灵敏度比传统 FSK 高出 20dB 左右。这个 20dB 是什么概念发射端功率不变接收端能多收到大约 10 倍的信号强度余量或者说通信距离理论上能拉到原来的 3 倍以上。代价是速率低典型配置下 125kHz 带宽、SF7 到 SF12空中速率从 5.5kbps 一路降到 0.3kbps 左右。所以 LoRa 从来不是用来传视频、传大文件的它就是传几十字节的传感器数据。那自组网又是什么意思很多人一听到自组网就想到 Mesh觉得节点之间要互相转发、动态路由。但 LoRa 自组网在工业场景里绝大多数实现其实是星型拓扑 中继扩展而不是真正意义上的多跳 Mesh。原因很现实LoRa 的占空比限制、信道冲突、路由维护开销都会让多跳 Mesh 的复杂度急剧上升。一个 100 节点的 LoRa Mesh光是路由表的同步和冲突退避就能把工程师折腾到怀疑人生。所以市面上能落地的 LoRa 自组网设备通常是网关 若干节点 可选中继的结构节点自动入网、自动分配地址、自动上报网关负责汇聚和转发。这篇文章我打算按实际做项目的思路来写先讲整体架构怎么设计再拆核心细节然后是实操流程最后是踩坑记录。适合正在选型 LoRa 方案、或者已经拿到模块但不知道怎么组网的嵌入式工程师看。如果你只是想调通两个模块之间的点对点通信那这篇文章可能有点重但如果你要做的是几十上百个节点的现场部署那下面的内容应该能帮你少走不少弯路。2. 整体架构设计与方案选型思路2.1 为什么大多数LoRa自组网最终都做成了星型先讲一个我自己的经历。早年做过一个农业大棚的项目客户一开始要求节点之间能互相转发最远的节点离网关有 3 公里。我们当时兴致勃勃地设计了一套三跳 Mesh 路由结果现场一测问题全出来了节点之间的链路质量随天气、作物高度、大棚金属骨架变化剧烈路由表一天要重建好几次而且 LoRa 的空中速率本来就低每多一跳延迟就翻倍一个数据从最远节点到网关要等好几秒。后来我们改成了星型 一个固定中继的方案反而稳定了。原因很简单LoRa 的链路预算足够大在大多数现场单跳就能覆盖 1 到 3 公里真正需要多跳的场景其实很少。与其花大力气做动态路由不如把网关的天线架高一点、把节点的发射功率调到位、把扩频因子选对。所以现在我做 LoRa 自组网默认架构是这样的网关Gateway负责汇聚所有节点数据通过 4G、以太网或者 RS485 上行到服务器或本地控制器。网关通常用性能强一点的 MCU比如 STM32F4 或者带 Linux 的方案。节点Node末端传感器节点MCU 用低功耗系列比如 STM32WLE5内置 LoRa 射频、HC32L136、GD32 等负责采集数据并定时上报。中继Repeater可选放在链路质量差的位置做一次转发。中继可以是独立设备也可以让某个供电充足的节点兼任。这个架构的好处是逻辑简单、维护成本低、故障定位容易。坏处是网关的覆盖半径有限超出范围的节点需要中继。但对于大多数工业现场来说这个取舍是划算的。2.2 射频参数怎么选SF、BW、CR 的取舍逻辑LoRa 的射频参数直接决定了通信距离、速率和抗干扰能力。这三个参数是参数含义增大后的影响SF扩频因子每个符号携带的比特数7~12距离更远速率更低空中时间更长BW带宽信道带宽常见 125/250/500kHz速率更高灵敏度下降距离变短CR编码率前向纠错比例4/5~4/8抗干扰更强开销更大我一般按这个顺序来定先定距离需求再定速率需求最后定抗干扰需求。如果节点离网关 1 公里以内SF7、BW125 就够了空中速率 5.5kbps传 20 字节数据不到 50ms。如果距离 3 公里以上或者中间有遮挡就要上 SF10 到 SF12速率降到 1kbps 以下传同样的数据要几百毫秒甚至一秒多。这里有个很多人忽略的点SF 越大空中时间越长节点占用的信道时间就越多。如果一个网关下面挂了 100 个节点每个节点都用 SF12那信道会非常拥挤碰撞概率急剧上升。所以实际项目中我会根据节点到网关的距离给不同节点分配不同的 SF近的用 SF7远的用 SF10这叫自适应数据速率ADR。ADR 在 LoRaWAN 里是标准功能但在私有协议里需要自己实现。BW 的选择相对简单国内 470MHz 频段一般用 125kHz少数场景用 250kHz 换速率。500kHz 在国内用得少因为占空比和法规限制。CR 我通常用 4/5也就是每 4 个有效比特加 1 个纠错比特。如果现场干扰特别严重可以上 4/8但速率会掉一半。实测下来工业现场用 4/5 基本够用除非旁边有大功率电机或者变频器。2.3 自组网协议栈私有协议还是LoRaWAN这是选型时绕不开的问题。LoRaWAN 是标准协议有完整的入网、加密、ADR、Class A/B/C 定义生态成熟网关和服务器都有现成方案。但它有几个重的地方入网流程需要 OTAA 或 ABPOTAA 要多次交互节点首次入网慢。协议栈代码量大对低端 MCU 不友好。服务器端需要 Network Server、Join Server、Application Server部署复杂。在国内 470MHz 频段LoRaWAN 的某些参数配置需要调整才能合规。私有协议则完全相反代码量小、入网快、参数随便调但所有东西都要自己写包括地址分配、确认重传、加密、固件升级。我的经验是如果节点数量在 50 个以内、场景固定、不需要跟第三方平台对接私有协议更省事。如果节点上百、需要跟云平台对接、或者客户明确要求标准协议那就上 LoRaWAN。热词里出现了stm32wle5 lora smart tdma 完整协议栈工程实现说明有人在做 TDMA 的私有协议。TDMA 在 LoRa 自组网里确实是个好思路给每个节点分配固定的时隙避免随机接入的碰撞。但 TDMA 需要全网时间同步而 LoRa 的空中时间又长同步开销不小。我见过做得好的 TDMA 方案网关周期性发信标节点根据信标对齐时隙效果不错但实现难度比纯 ALOHA 高一个量级。3. 核心细节解析与实操要点3.1 节点入网与地址分配IAP和Flash的坑热词里有个很有意思的词iap boot里面定义的变量复位后会怎样。这个问题跟 LoRa 自组网设备关系很大因为节点通常需要支持远程固件升级OTA而 OTA 的基础就是 IAPIn-Application Programming。先说 IAP 的基本结构MCU 的 Flash 分成 Bootloader 区和 Application 区。Bootloader 负责接收新固件、校验、写入 Application 区然后跳转。Application 区就是正常运行的业务代码。这里有个经典坑Bootloader 里定义的全局变量在跳转到 Application 之后如果发生复位这些变量的值会怎样答案是取决于复位类型和变量存储位置。如果变量在 RAM 里普通复位看门狗、软件复位不会清 RAM值可能保留但上电复位会清 RAM值丢失。如果变量在 Flash 里比如用const或者指定到特定段复位后值保留但要注意 Flash 写入次数限制。如果变量在备份寄存器Backup Register里只要 VBAT 供电不断复位后值保留。我实际做 OTA 时会在 Bootloader 里用一个备份寄存器存升级标志。Application 收到升级命令后写标志、复位Bootloader 启动时读标志如果标志有效就进入升级模式否则跳转 Application。这样即使中途断电标志也不会丢只要 VBAT 有电。另一个坑是中断向量表的偏移。Application 区的起始地址不是 0x08000000而是 Bootloader 之后比如 0x08008000。这时候 Application 里必须设置SCB-VTOR 0x08008000否则中断会跳到 Bootloader 的向量表直接跑飞。这个坑我踩过不止一次尤其是用 HAL 库的时候SystemInit里默认设的是 0x08000000需要手动改。对于 LoRa 节点来说OTA 还有个特殊问题LoRa 速率低固件大。一个 100KB 的固件用 SF10、BW125 传空中速率大概 1kbps理论上要 800 秒实际加上协议开销和重传可能要 20 分钟以上。所以 LoRa OTA 通常采用分片传输 断点续传而且要在节点供电充足的时候做。我一般会把 OTA 设计成网关主动推送 节点确认的模式而不是节点主动拉取这样网关可以控制升级节奏避免所有节点同时升级把信道占满。3.2 RS485与LoRa的配合为什么很多设备要带485接口热词里 RS485 出现的频率极高rs485组网、rs485电路、rs485自动换向电路、rs485与rs232协议详解及modbus通信指南说明很多人关心的不是纯 LoRa而是LoRa RS485 的组合设备。这个组合的逻辑很清晰工业现场大量传感器、PLC、仪表都是 RS485 接口走 Modbus RTU 协议。LoRa 自组网设备如果带一路 RS485就可以直接接这些设备把 Modbus 数据透传或者解析后通过 LoRa 发出去。这样既不用改原有设备又能实现无线化。RS485 电路设计有几个关键点收发切换RS485 是半双工发送和接收不能同时。传统方案用 MCU 的 GPIO 控制 DE/RE 引脚但这样软件开销大时序容易出错。现在常用自动换向电路用三极管或者专用芯片根据 TX 信号自动控制 DEMCU 只管发数据就行。保护电路现场环境恶劣RS485 总线容易受浪涌、静电、共模电压影响。TVS 管、共模电感、自恢复保险丝是标配。我见过没加保护的板子雷雨天一打就烧一片。终端电阻RS485 总线两端要接 120 欧姆终端电阻中间节点不接。很多人忘记这个导致通信距离短、误码率高。AB 线极性热词里有人问rs485的ab波形哪种才是正确的。标准定义是 A 线比 B 线高时表示逻辑 1但实际芯片标注可能相反接线前一定要看手册或者用示波器确认。LoRa 设备接 RS485 传感器时典型流程是MCU 通过 RS485 发 Modbus 查询帧等传感器回复解析数据打包成 LoRa 帧发出去。这里要注意超时设置Modbus 回复有延迟如果超时设太短会误判传感器离线设太长又影响 LoRa 上报周期。我一般设 200ms 到 500ms根据传感器手册调整。3.3 低功耗设计节点怎么做到电池撑几年LoRa 节点很多是电池供电低功耗是核心指标。一个设计良好的节点平均电流可以做到几十微安用 2000mAh 的锂亚电池能撑 3 到 5 年。低功耗的关键是让 MCU 和射频大部分时间都在睡。典型的工作周期是这样的MCU 定时器唤醒比如每 5 分钟一次。采集传感器数据如果是 RS485 传感器还要给传感器供电、等预热。打开 LoRa 射频发送数据。等待网关确认如果需要确认。关闭射频和传感器电源MCU 进入 STOP 或 STANDBY 模式。这里面每个环节都有优化空间传感器供电很多传感器静态电流不小不能一直供电。用 MOS 管控制传感器电源只在采集时打开。LoRa 发射功率发射功率越大电流越大。20dBm 发射时电流可能 120mA而 14dBm 只有 40mA 左右。如果距离够没必要用最大功率。唤醒周期这是最大的变量。5 分钟一次和 1 小时一次平均电流差 10 倍以上。要根据实际需求定不要盲目追求实时。STANDBY 模式STM32 的 STANDBY 模式电流只有几微安但唤醒后相当于复位所有 RAM 丢失。STOP 模式电流几十微安但 RAM 保留。我一般用 STOP 模式因为唤醒后不用重新初始化。实测数据一个 STM32WLE5 节点每 5 分钟采集一次 RS485 传感器并上报发射功率 14dBm平均电流大约 80 微安。2000mAh 电池理论寿命 2000/0.08 25000 小时约 2.8 年。如果改成 15 分钟一次平均电流降到 30 微安左右寿命能到 7 年以上。4. 实操过程与核心环节实现4.1 硬件选型与最小系统搭建先列一下我做 LoRa 自组网设备时的典型物料清单部件选型说明主控射频STM32WLE5JC内置 LoRa 射频省一颗芯片适合节点网关主控STM32F407 或 Linux 方案需要处理多节点数据性能要够射频前端SX1262 或内置网关可用外置 PA 提升功率电源锂亚电池 LDO节点用注意 LDO 静态电流RS485SP3485 或 MAX3485带自动换向天线470MHz 弹簧天线或外置网关用高增益节点用小型最小系统搭建步骤供电检查先用稳压电源给板子供电测各路电压是否正常尤其是射频部分的 3.3V 要干净。晶振起振STM32WLE5 需要 32MHz 和 32.768kHz 晶振用示波器确认起振。SWD 连接确认能下载程序读到芯片 ID。射频校准用官方工具或者自己写代码校准射频的频偏和功率。点对点通信先让两个节点互相发数据确认射频链路通。这一步最容易出问题的是射频部分。LoRa 的射频电路对布局很敏感尤其是匹配网络。如果匹配没做好发射功率上不去接收灵敏度也差。我一般会先用频谱仪测发射频谱确认功率和频偏正常再测接收灵敏度。4.2 私有协议帧格式设计私有协议的核心是帧格式。我一般这样设计| 前导码 | 同步字 | 帧头 | 载荷 | CRC | | 8字节 | 2字节 | 4字节| N字节| 2字节|帧头里包含源地址2字节节点地址入网时分配。目的地址2字节网关地址通常是 0x0000。帧类型1字节入网请求、数据上报、确认、升级等。序列号1字节用于去重和确认。载荷根据帧类型不同而不同。数据上报帧的载荷就是传感器数据入网请求帧的载荷是节点唯一 ID比如 MCU 的 UID。入网流程节点上电发入网请求载荷带 UID。网关收到检查 UID 是否已注册。如果已注册回复入网成功带分配的短地址如果未注册根据策略决定是否允许。节点收到回复保存短地址进入正常上报模式。如果节点没收到回复随机延迟后重试避免所有节点同时入网。这里有个细节入网请求要用较低的 SF 和较高的功率因为节点还不知道自己离网关多远。入网成功后网关可以根据收到的信号质量指示节点调整 SF 和功率。4.3 网关数据汇聚与上行网关收到节点数据后要做几件事去重同一个序列号的数据只处理一次。时间戳给数据打上网关本地时间。缓存如果上行链路4G/以太网断了数据要缓存恢复后补传。上行通过 MQTT、Modbus TCP 或者自定义协议发给服务器。网关的缓存策略很重要。我一般用环形缓冲区存最近 10000 条数据。如果上行断了超过缓冲区容量最老的数据会被覆盖。对于关键数据可以加一个重要标志重要数据不覆盖。网关的另一个功能是下行控制。服务器可以通过网关给节点发命令比如修改上报周期、触发采集、启动 OTA。下行帧和上行帧用同样的格式只是方向相反。4.4 现场部署与信号测试设备做好了现场部署才是真正的考验。我的标准流程是现场勘测先带一个网关和一个节点到现场测信号。网关放在预定位置节点拿到各个角落记录 RSSI 和 SNR。确定网关位置网关尽量放高避开金属遮挡。如果现场有多个建筑可能需要多个网关或者中继。节点安装节点安装位置要避开金属、电机、变频器。天线尽量竖直不要贴着墙面。全网测试所有节点装好后观察一段时间的数据看有没有丢包、延迟异常。参数微调根据实测数据调整节点的 SF 和发射功率。这里有个经验RSSI 大于 -100dBm、SNR 大于 0dB 的链路基本能稳定通信。如果 RSSI 在 -110 到 -120 之间SNR 为负就要考虑加中继或者调整天线。5. 常见问题与排查技巧实录5.1 通信距离不达标怎么排查这是最常见的问题。排查顺序现象可能原因排查方法近距离能通远距离不通天线匹配差、功率不足频谱仪测发射功率白天通晚上不通干扰源变化扫频看背景噪声晴天通雨天不通湿度影响、天线进水检查天线密封某些节点不通遮挡、金属反射换位置测试全部不通网关故障、频点错误检查网关和频点配置我遇到过一个案例节点装在金属配电箱里信号出不来。后来把天线用馈线引到箱外问题解决。所以金属遮挡是 LoRa 最大的敌人比距离本身影响还大。5.2 丢包率高怎么办丢包率高通常是信道冲突或者链路质量差。解决思路降低上报频率如果所有节点都 1 分钟上报一次信道肯定挤。改成 5 分钟或者 10 分钟。错开上报时间给每个节点加一个随机延迟避免同时上报。调整 SF近的节点用低 SF减少空中时间。加确认重传重要数据加 ACK没收到就重传。但重传会增加信道负担要权衡。换频点如果现场有同频干扰换个频点试试。5.3 节点功耗异常怎么查功耗异常一般是某个环节没关干净。排查方法用高精度电流表比如 uCurrent测不同状态下的电流。确认 MCU 进入了低功耗模式。确认射频进入了 Sleep。确认传感器电源被切断。检查有没有悬空的 GPIO悬空引脚会漏电。我踩过一个坑某个 GPIO 配置成输入但没上拉浮空状态下电流多了几十微安。后来全部改成模拟输入或者输出低功耗才降下来。5.4 OTA升级失败怎么恢复OTA 失败最怕的是节点变砖。我的做法是Bootloader 永远不升级只升级 Application。Application 升级前先写一个升级中标志到备份寄存器。升级完成后清除标志。Bootloader 启动时如果发现升级中标志还在说明上次升级失败回滚到旧固件或者重新进入升级模式。这样即使升级中途断电节点也能恢复。另外Bootloader 要留一个串口或者 LoRa 的强制升级入口万一标志逻辑出问题还能手动救回来。6. 一些实际项目中的经验体会做 LoRa 自组网设备最深的体会是射频这东西理论是一回事现场是另一回事。你在实验室里调好的参数到现场可能完全不是那么回事。所以我的习惯是任何新方案先做小批量现场测试跑至少两周看数据稳定性再批量部署。另一个体会是不要过度设计。我见过有人非要在 LoRa 上跑 Mesh结果复杂度爆炸维护成本极高。其实大多数场景星型加中继就够了。把简单的事情做稳定比把复杂的事情做出来更有价值。最后分享一个小技巧网关加一个 RSSI 日志功能。每个节点每次上报网关都记录 RSSI 和 SNR。这样运行一段时间后你就能看到哪些节点链路质量在下降提前发现天线老化、遮挡物增加等问题。这个功能实现很简单但运维价值很大。这个内容后续还可以这样扩展如果你要做的是带定位功能的 LoRa 设备可以研究一下 LoRa 的到达时间差TDOA定位虽然精度不如 GPS但在室内或者 GPS 信号差的地方能派上用场。另外LoRa 和蓝牙、WiFi 的共存问题也值得关注尤其是网关同时带多种无线的时候射频干扰要提前规划。
