LoRa应急灯无线改造：从选型到低功耗设计实践

上个月刚把手头那批地下车库的应急灯LoRa改造项目收尾。这批灯没有做任何额外布线，全靠每盏灯里那颗 LoRa1276-C1-915 模块，把电池电压、灯具状态、告警信息从负一层停车场传到地面值班室的网关，再由网关走4G汇总到平台。这套系统解决的实际问题很简单：应急灯平时没人管，等真停电或者出状况那天，它能不能亮、能亮多久，完全靠日常状态数据来判断。LoRa 这种通信方式在这个场景里确实合适，距离够、能穿楼板、单盏灯功耗低，后续维护不用频繁换电池。这篇文章我就把通信、状态监测、低功耗设计这三块的核心做法和经验梳理一遍。

1. 为什么选 LoRa1276-C1-915：应急灯无线化绕不开的选型逻辑

1.1 先搞清楚应急灯到底需要什么样的通信

应急灯这种设备，通信需求跟家里音箱、门铃完全不是一回事。一盏应急灯的点位很固定，分布范围却很散，一栋楼几十到几百个，分散在楼梯间、走廊、地下车库、设备层。这些位置有一个共同特点：钢筋混凝土的楼板和墙体特别多，2.4G的 WiFi 和 BLE 穿两层楼板基本就没戏了，实测在地下室隔一道剪力墙，蓝牙信号能直接掉到-90dBm以下，连广播包都收不全。

如果改用有线方案，比如 RS-485 或者 CAN 总线，单灯成本不高，但布线成本和施工周期会翻好几倍。地下车库这种地方，桥架、穿管、接线井，每一项都是实打实的钱。更麻烦的是后期维护，一根线断了，整条链路都瘫痪，排查起来极其痛苦。

LoRa 的优势恰好踩在这个场景的需求点上。它传输的数据量很小，一帧几十字节就够用，和 WiFi 视频流这种大带宽需求完全不同。换句话说，应急灯要的不是“高速公路”，而是一条窄但稳的“电报线”。LoRa 对穿墙、绕射、距离的容忍度远高于2.4G，单颗模块加根几十块钱的天线，在车库环境里跑几百米没压力，这在2.4G方案里几乎不可想象。

你可能会问，那 NB-IoT 或者 Cat-M 呢？这两个也好，但每盏灯一张SIM卡，运营费是长期成本，而且在地下室这种信号死角，蜂窝网络未必覆盖得到。相比之下，LoRa 网关部署在项目现场，整个链路自己可控，没有月租，通信链路独立于外部网络，断电时只要网关有备用电源，应急灯照样能上报状态。

1.2 LoRa1276-C1-915 模块本身有哪些底子

LoRa1276-C1-915 这颗模块，核心方案是基于 Semtech 的 SX1276 射频芯片，频段在915MHz附近，属于国际通用的ISM频段。SX1276 是市面上资料最多、应用最广的 LoRa 芯片之一，从十几块的抄表模块到上万台的运营商级网关，底层都能看到它的影子，选它最大的好处是踩坑成本低，官方驱动、参考设计、各种论坛案例一抓一大把。

下面这个表是这颗模块的典型参数，方便你有个直观印象。

915MHz 比 2.4GHz 的物理优势在于波长更长，同距离下绕射能力更强，穿过普通混凝土楼板的损耗相对更小。跟 433MHz 比，915MHz 的频段带宽更宽，也少了很多对讲机、遥控器之类的干扰源，在工业、建筑场景里反而更干净。

这里有一点必须提醒：不同地区的无线电频段规划不一样，这个频率在国际市场是常规选择。如果你做的项目面向国内，要确认模块是否有对应频段版本，晶振、滤波器、射频匹配网络都会不同，不能直接照搬 915 的参考设计。

2. 通信链路搭建：从硬件接线到LoRa协议帧

2.1 SPI 接线与GPIO配置：比串口模块更可控

很多做物联网的工程师习惯用串口LoRa模块，AT指令一发就能跑。但我这回想多说一句：做应急灯这种对功耗和状态要求很细的产品，直接上SPI接口的 SX1276 方案更可控。串口模块的固件是别人封装好的，你没法精细控制射频参数、DIO中断和休眠时序，而SPI层级的设计，所有寄存器都在你手里。

我用的主控是 STM32L071 系列，LoRa1276-C1-915 的接线方式如下。

SPI 时钟频率建议不要超过 8MHz，SX1276 手册标称最高10MHz，但留点裕量更稳，发射和接收流程里大量读写 FIFO，8MHz 完全够用。

GPIO 配置有两个关键点。第一，进入休眠前，所有连到模块的 SPI 引脚要么保持空闲电平（SCK、MOSI、NSS 都拉高），要么直接切到模拟输入模式，不能让它们悬空或者半悬空，否则模块内部逻辑处于不定状态，睡都睡不踏实。第二，DIO0 必须配置成下降沿或上升沿触发的外部中断，取决于 TX Done 的标志行为，实际调过就知道，中断边沿配错会导致发送完成误判为超时。

还有个容易忽略的点，RST 引脚最好串联一个 1kΩ 电阻到 MCU 引脚。模块复位脉冲很短，直接连也能工作，但遇到上电时序竞争的时候，串电阻能避免模块内部电压还没稳住就被外部干扰拉复位。我不止一次遇到设备偶发性失联，最后就坏在复位引脚毛刺上。

2.2 星型组网与上行数据帧设计

LoRa 在这个项目里用的是最简单的星型网络：每盏灯都是节点，网关做汇聚，节点之间不互相通信。这符合应急灯的业务属性，灯具之间不需要协同，只要每个人都能被网关“看见”就行。

一个网关带多少个节点，取决于上报周期和单包空中时间。我用 SF10、125kHz 带宽、4/5 编码率，发射一包 15 到 20 字节的数据，空中时间大概在 300ms 左右。如果 200 盏灯在 10 分钟内上报完，每秒钟只需要容纳几十个包，信道压力很小。真正要防的是多盏灯同时上报导致碰撞。解决手段很朴素：每盏灯随机延时 0 到 5 秒；如果第一次没等到 ACK，下一轮把随机窗口扩大到 0 到 20 秒。

协议帧我自己重新定义了一套简短的固定格式，方便网关解析。

LoRa 协议本身有 CRC 校验，但我还是加了应用层 CRC，原因是 LoRa 的 CRC 只能保证物理层帧没错，不能保证帧内容语义对，双保险更放心。

发送数据时，流程可以简化成这么几步。

void lora_send_status(uint8_t *buf, uint8_t len) { uint8_t reg; // 切换到 LoRa 模式并进入 Sleep spi_write_reg(REG_OP_MODE, 0x80); // 清空 FIFO 指针 spi_write_reg(REG_FIFO_ADDR_PTR, 0x00); for (uint8_t i = 0; i < len; i++) { spi_write_reg(REG_FIFO, buf[i]); } // 切换到 TX 模式 spi_write_reg(REG_OP_MODE, 0x83); // 等待 DIO0 中断 while (!dio0_flag) { } // 回到 Sleep，准备休眠 spi_write_reg(REG_OP_MODE, 0x80); }

这段代码是示意，实际工程里我会加超时看门狗，防止 DIO0 迟迟不来导致死循环。同时要注意模块电源。发射瞬间电流可能冲到 120mA 以上，如果电池或 LDO 撑不住，电压一跌，发射就失败，表现就是“发送功耗异常高但网关收不到包”。

3. 状态监测实现：电池电压、光源和故障一个都不能漏

3.1 需要监测的物理量和对应采样电路

应急灯的状态监测，核心是回答三个问题：电池有没有电？灯丝或者LED能不能亮？主电断电的时候系统能不能马上反应过来。围绕这三个问题，我在每盏灯上做了四路采集。

第一路是电池电压。电池电压不能直接进 ADC，要先分压。我用 100kΩ 和 20kΩ 电阻串联，把 4.2V 满电锂电池降到 0.7V 左右，刚好落在 MCU 参考电压范围内。分压电阻不能太小，太小了静态漏电流大，每路几百微安直接从电池上吃电；也不能太大，太大采样时信号源阻抗过高，ADC 读数会偏差。100k/20k 这个组合算比较平衡的点。

第二路是光源开路检测。LED 灯串平时是断开的，测试时我用一个小 MOS 管接通灯回路，同时串一个 2Ω 采样电阻，测流过灯的电流。正常灯串电流在 200mA 量级，如果哪颗 LED 虚焊或驱动坏了，电流明显偏低甚至为零。这个测试必须在主电有电、系统空闲时做，不能在应急点亮瞬间测，否则会和真正的点亮逻辑抢资源。

第三路是主电断电检测。我用一个光耦，输入侧接主电经过整流后的直流母线，输出侧接 MCU 的 EXTI 引脚。主电正常时光耦导通，信号为低；主电一断，光耦截止，信号被上拉电阻拉高，MCU 立刻中断唤醒，点亮应急灯并上报“主电失电”事件。这个响应速度能做到 10ms 以内，完全满足应急点亮的需求。

第四路是温度，电池旁边放一颗 NTC 热敏电阻。锂电池在低温下放电能力急剧下降，高温下又有热失控风险。温度数据不需要上报很频繁，一天两三次就够了，主要用于给电池电压做修正参考。

3.2 故障判定逻辑与上报时机

采集到数据只是第一步，怎么判定异常才是真正体现产品功力的地方。我做了一张故障判定表，每个故障都有明确条件，不搞模糊判断。

这里有个经验，电池电压不能单次采样就直接判定。充电阶段电池电压会缓慢上升，主电断电瞬间电压会有一个突降的冲击，如果阈值设得不合理，很容易误报欠压。我的做法是连续采样 3 次、每次间隔 100ms，取中值再判断，电压数据的可靠性比单次采样高得多。

上报时机也很有讲究。心跳包这种例行消息，我统一放低语时段，比如每小时随机上报一次，避免整点碰撞。故障信息则必须第一时间上报，并且连续发 3 遍，发送间隔 5 秒，直到收到网关 ACK 才停。为什么这么设计？因为 LoRa 是半双工的，没有 ACK 意味着你不知道包到底到没到，连续重发是性价比最高的确认手段。

4. 低功耗设计：把待机电流从毫安级压到微安级

4.1 功耗预算：先算账再谈低功耗

低功耗不是靠某一个小技巧实现的，而是账算明白之后，把每一路电流都抠到位的结果。我做了一个最简单的功耗模型，先列出所有组成项，再算平均电流。

把这些加起来算平均电流，大概是每天 0.4mAh 左右。如果配一块 2200mAh 的锂电池，理论数据是 2200 ÷ 0.4 ≈ 5500 天，约 15 年。再考虑电池自放电、温度影响、后期容量衰减，实际打个对折，也能撑 6 到 8 年，这个寿命对应急灯是合格的。

但注意，这个计算里有个非常敏感的参数：上报次数。如果把上报周期从 2 小时一次改成 10 分钟一次，发射消耗从 1.2 秒变成 14.4 秒，平均电流立刻跳到 120μA 量级，电池寿命缩水到两年左右。系统设计时一定要先定寿命目标，再反推上报周期，顺序反了功耗这关就过不了。

4.2 休眠唤醒机制与实测调优

低功耗机制设计上，我用了三层策略。

第一层是常态休眠。系统没有事件时，MCU 进 STOP 模式，LoRa 模块进 Sleep，统一由 RTC 定时唤醒。唤醒后先检查标志位，决定是发心跳、做光源测试，还是听网关有没有下行指令，处理完立刻回去睡。

第二层是 CAD 信道活动检测。SX1276 有个很省电的机制叫 CAD，它只检测信道里有没有 LoRa 前导码，不进入完整接收模式。完整 RX 模式电流 12mA，CAD 只有 4mA 左右，而且持续时间只有几十个符号，功耗低一个量级。网关要给灯具发下行指令时，先发一段长前导码，灯具定时做一次 CAD 检测，发现前导码再进入 RX 接收完整包。

第三层是事件唤醒。主电断电、温度超限这类事件，由外部中断直接拉醒 MCU，不走 RTC 轮询。这样既保证了应急点亮的响应速度，又不需要每时每刻都开着接收机。

我之前测量这套系统的时候，理论待机电流应该在 6~7μA，但实测老是在 40μA 左右下不来。查了半天，最后发现罪魁祸首是板子上一个电源指示灯。红色的 LED 限流电阻 10kΩ，看似电流很小，但它在电池供电回路里，点亮时差不多要 0.3mA，这个电流比我整个系统的预算高几十倍。拔掉这颗指示灯，电流马上回落到 8μA。所以低功耗项目里，每一颗元件都要问一句：它是否必须在电池回路上工作。

5. 调试现场：通信距离、误报与电流异常排查

5.1 距离不够和丢包率偏高的排查顺序

如果 LoRa 通信距离达不到预期，先别急着怀疑芯片型号，大多数情况下是天线和电源问题。我的排查顺序是固定的，先量天线驻波，再看供电波形，最后才调射频参数。

天线是最容易出问题的环节。915MHz 的四分之一波长单极子，理论长度约 8.2cm，但这是理想自由空间值。实际用的弹簧天线、PCB 天线都有各自的匹配电路，必须按模块参考设计原样抄，不能随便找根线当天线。我曾经试过把模块天线贴在金属桥架上测试，距离直接从 500 米掉到 50 米，金属导体对天线的影响就是这么夸张。

供电波形也不容忽视。发射瞬间电流 120mA，如果电源线细长、电容不足，PA 供电会被瞬间拉低，导致射频输出功率不足，表现为接收端 RSSI 低得离谱。我用示波器挂在模块电源引脚上，发射瞬间看有没有跌落，低于 3.0V 基本就是供给不行。

射频参数设置上，SF（扩频因子）和带宽是关键。提高 SF 能增加灵敏度，但空中时间会变长，数据速率降低。我的原则是：在满足吞吐量的前提下尽量用高 SF。应急灯这种低速率场景，SF11 甚至 SF12 都可以接受。带宽默认 125kHz 不用动，带宽越窄灵敏度越高，但抗频偏能力会下降。板子晶振误差大的话，还得额外开频偏补偿。

5.2 状态误报与电流异常的实战修复

状态误报是另一个高频问题，尤其是电池电压的误报。最早我把采样逻辑写得太“耿直”，单次 ADC 转换结果直接就拿来判断，结果主电波动时经常出现瞬时低压误报。后来改成连续采样取中值，误报率降到接近零，更稳的做法是 ADC 采样前延迟 10ms 等电源稳定，软件上再加一个小滤波。

电流异常的排查，我是用功耗分析仪直接串联在电池和系统之间看实时曲线。系统如果处于异常状态，电流曲线上会暴露三个典型特征：一是休眠时电流呈锯齿状，说明 MCU 没真正进 STOP，某些外设还开着；二是休眠电流周期性跳变，说明有定时器在偷偷唤醒系统；三是电流稳定偏高，说明某个外设一直处于工作态，不是 LD O 静态电流太大就是 GPIO 漏电。

GPIO 漏电这个问题，我接手的几个项目都遇到过。一些引脚在库函数初始化时默认是带上拉的，在低功耗模式下上拉电阻会持续灌电流，十几路 GPIO 加起来就是毫安级。解决方法是所有不用的引脚统一配置成模拟输入，或者确定电平后配置成输出低，总之不能让它处于不确定的浮动状态。

6. 最后聊一点实操体会

项目做完，我最大的体会是：LoRa 这套东西，协议和射频参数网上都有现成答案，真正拉开差距的是天线、电源和采集电路这些“笨功夫”。SX1276 标称 0.2μA 休眠电流是芯片理想值，你板子上任何一颗 LED、一个悬空 GPIO、一个静态电流大的 LDO，都会让整机永远徘徊在毫安级。

另外再分享一个我自己的习惯：做低功耗产品，先把功耗目标写进需求文档，再反推上报周期和唤醒策略，不要边做边优化。状态监测也一样，优先把电池电压和光源开路这两个最核心的故障项做扎实，比堆一堆花哨的高级功能实用得多。这套思路不只适用于无线应急灯，做抄表、传感器、工业采集类的 LoRa 项目，底层逻辑都是通的。