IoT无线传感器节点扎堆往LPWAN部署方向走，已经不是趋势，而是正在发生的现状。这两年我经手过环境监测、智慧农业、工业设备状态监控项目，几乎每一套都离不开低功耗广域网这张网。LPWAN不是新概念，但真正把无线传感器节点稳定部署到生产环境，坑远比想象多。这篇文章就围绕IoT无线传感器节点的LPWAN部署这条主线，把硬件功耗、射频链路、固件协议、现场勘测和规模化运维的实操细节一次讲清楚。适合正在做选型评估的嵌入式工程师、物联网解决方案架构师，以及想搞清楚LPWAN落地成本的产品经理。
1. 为什么无线传感器节点都盯上了LPWAN
1.1 从客户现场的需求倒推：LPWAN到底解决了什么
我见过太多客户一开始拿着Wi-Fi和BLE方案来做无线传感器节点，现场跑了一周就发现根本玩不转。厂房里一排排金属货架把信号挡得严严实实，仓库角落的温湿度数据要么传不回来，要么每隔半小时要换一次电池。客户真正要的不是"能联网"，而是"电池撑一年以上"、"墙厚也能把数据送出来"、"单点设备成本压到几十块"这三个看似简单、实际很难同时满足的需求。
LPWAN能解决的就是这个组合问题。低功耗广域网的核心特征是用尽量小的发射功率换更远的通信距离，再用协议层的窄带调制换接收灵敏度。以LoRaWAN为例，典型城市环境覆盖半径能到两三公里，开阔地可以更远，而节点平均工作电流能压到微安级。NB-IoT虽然依赖运营商基站，但穿墙能力和蜂窝覆盖更标准化，适合跨地域业务。两类方案都在功耗、速率、覆盖之间做了专门取舍，让无线传感器节点不再需要在“近距离但频繁换电池”和“远距离但功耗失控”之间二选一。
不过LPWAN不是什么万能钥匙。很多做短距无线出身的同行习惯把433MHz透传当成"自研LPWAN"，结果节点数量一多，频谱冲突和重传让整个网络彻底瘫痪。真正生产级的LPWAN部署，必须有一套完整的入网管理、信道规划、数据确认机制，这就是为什么本文后面会花大篇幅讲协议栈和运维，而不仅仅是画板子和调射频。
1.2 LPWAN主流方案对比：LoRaWAN、NB-IoT还是专用ISM
选型阶段最常被问到的就是LoRaWAN和NB-IoT到底怎么选。我把几个关键维度整理成了一张表，方便对照：
| 维度 | LoRaWAN（含LoRa调制） | NB-IoT | 专用ISM（如470MHz自组网） |
|---|---|---|---|
| 频谱授权 | 免授权ISM频段（需遵守当地法规） | 运营商授权频段 | 免授权ISM频段 |
| 覆盖模式 | 自建网关/私有网络 | 运营商基站 | 自建网关/私有网络 |
| 典型速率 | 0.3kbps~50kbps（与SF/带宽有关） | 几十kbps | 由协议决定 |
| 下行能力 | 受限于节点接收窗口 | 较好 | 自建协议决定 |
| 单节点成本 | 较低（模块10~30元量级） | 模组成本较高 | 低，但开发成本高 |
| 适合场景 | 园区、厂区、农业、楼宇 | 车联网、表计、跨区域资产 | 对成本极敏感、可定制协议 |
这张表不是用来直接下结论的，而是帮你把客户现场条件摆到台面上。LoRaWAN最大的优势是网络侧可控，网关和服务器都是自己的，数据不出园区，很多制造企业对这一点非常看重。NB-IoT的优势不用自己维护网关，但流量费、模组费都要计入长期成本，而且在地下室等极端场景仍可能信号不足。专用ISM方案则适合团队有很强RF协议能力、又需要极致成本压缩的项目，比如一台设备只传一个开关量，几百个节点组成本地星型网就够了。
我的建议是：如果客户要求私有化部署、节点密度相对可控，优先选LoRaWAN；如果客户业务横跨多个城市且没有自建网关的运维团队，老老实实选NB-IoT；只有在产品形态极其固定、协议完全自定义的情况下，才考虑专用ISM自组网。这里没有“最好”，只有“最匹配”。
1.3 无线传感器节点里那些容易忽略的"隐藏需求"
很多人一提到无线传感器节点，脑子里只有MCU加LoRa芯片加传感器，但真正部署时需求会多出好几个维度。比如双向通信，表面看传感器只是上报数据，但现场人员往往需要远程修改上报间隔、校准阈值、升级固件，这意味着节点必须要能可靠接收下行命令。
另一个隐藏需求是时钟同步和事件时间戳。我做过一个冷链项目，客户不仅要温度曲线，还要知道某次开门导致温度波动的精确时间点。如果节点只在唤醒时通过LoRa网络对时，误差可能到秒级，对后续追溯来说完全不可用。所以现在做无线传感器节点，我至少会给MCU留一个外部RTC晶振，把本地时间戳打好再打包上发，避免依赖服务器二次补录。
安全也不能只在文档里提一句。很多LoRaWAN节点默认启用了加密，但密钥的烧录方式却很少有人较真。一旦密钥硬编码在固件里，同型号设备全部暴露在同一个风险敞口。生产环境里更稳妥的做法是每台设备写入独立DevEUI/AppKey，并在产线做一次入网自检。这些需求不会写进最初的选型表，但会在规模化部署后变成运维成本的主流。
2. 节点硬件选型：从MCU到射频的每一步取舍
2.1 MCU选型的核心逻辑：功耗与算力的平衡
无线传感器节点的MCU不需要很强的算力，但需要在工作模式切换时把电流压到极限。我在早期项目里用过几颗传统8位MCU，待机电流倒是不高，但唤醒时间太长，导致每次发送前都要多浪费几毫秒在时钟稳定上，最终平均功耗反而比低功耗Cortex-M0还高。
我常用的选型策略是先列一张关键参数表，再结合数据上报周期算平均电流。以支持LoRaWAN的典型方案为例：
| MCU/SoC | 内核 | 休眠电流（典型） | 唤醒时间 | 备注 |
|---|---|---|---|---|
| STM32L0系列 | Cortex-M0+ | 3.4uA @ RTC运行 | 微秒级 | 性价比高，生态成熟 |
| STM32WL系列 | Cortex-M4 + LoRa射频 | 1.6uA @ RTC运行 | 微秒级 | 单芯片集成LoRa收发 |
| MSP430FR系列 | 16位RISC | 0.4uA @ RTC运行 | 微秒级 | 超低功耗标杆 |
| nRF52系列 | Cortex-M4F | 1.9uA @ RTC运行 | 微秒级 | 有蓝牙，适合后期扩展 |
如果你的射频前端是独立的LoRa芯片，比如SX1262，那MCU选STM32L系列或者MSP430都没问题；如果PCB空间很紧，想减少器件数量，STM32WL这种把MCU和LoRa收发器封装在一起的方案会更省事。需要注意的是，集成方案虽然方便，但射频部分一旦出问题，调试时不容易用万用表区分是MCU电源还是射频前端漏电。
在实际项目中，我会给MCU的每个IO口做一份功耗预算表。GPIO上拉电阻、传感器供电开关、指示灯串接电阻，每一项漏电流看起来都是微安级，但几个微安累加之后，对一节8000mAh锂亚电池来说就是几个月的寿命缩水。低功耗不是某一颗芯片的功劳，而是整板每个细节里的"细水长流"。
2.2 射频前端与天线设计：链路预算不只是看发射功率
无线传感器节点最容易栽跟头的就是射频链路。很多人以为LoRa灵敏度高，随便画个天线就能跑很远，结果实测穿了两堵墙之后丢包率直接暴增。这里先弄清楚一个核心公式：链路预算 = 发射功率 + 发射天线增益 - 路径损耗 - 接收灵敏度（实际工程还要加衰落余量）。
以LoRaWAN为例，SX1262的接收灵敏度在SF12/125kHz时可到-137dBm，发射功率设置14dBm，天线增益假设0dBi。如果路径损耗是130dB，链路余量就是14 + 0 - 130 - (-137) = 21dB，看起来够用，但这是理想自由空间下的值。实际车间里金属货架、水泥柱、设备机柜都会给信号带来额外10~30dB的损耗，如果当初没有预留足够的余量，最终等待你的就是频繁掉线。
天线设计这块也要说几句。陶瓷贴片天线占地小，但带宽和效率都不如弹簧天线或外置胶棒天线。节点外壳如果是金属或者内部有大面积铺地，天线净空区会被严重压缩。我在一个电机振动监测项目里就吃过亏，外壳一合上，RSSI直接掉了9dB，最后只能把天线改到外壳顶部用延长线引出，才解决了谐振偏移。所以打样阶段一定要在真实外壳、真实安装位置下做射频测试，千万不要只盯着频谱仪上的“漂亮曲线”下结论。
另一个容易忽略的点是LoRa参数与灵敏度的关系。扩频因子SF越高、带宽越窄，灵敏度越好，但空中传输时间也越长，占空比限制更严格。环境监测这种小包低频业务，可以放心用SF12提高覆盖；但如果是工业设备实时告警，更合适的做法是SF7或SF8，用更短的发送时间降低冲突概率，保证下行窗口及时打开。链路预算要用实际情况来定参数，不能一个SF值走遍全场。
2.3 传感器接口与电源管理：低功耗设计的隐藏杀手
MCU和射频做到再低功耗，如果传感器选型不当，整机平均电流照样飙上去。我见过一个土壤墒情项目，节点用的传感器需要预热三分钟才能稳定读数，结果每次采集的功耗比LoRa发射还高好几倍。后来我们把传感器改成低功耗版本，并加上一个受控电源开关，在采样前才给传感器上电，采样完成后立刻断电，整机电池寿命从四个月直接拉到了两年。
这里的关键是电源树设计。传感器和射频模块的瞬间电流往往是大头，比如LoRa发射峰值电流可能到120mA，个别传感器启动瞬间还能冲到500mA。如果电池内阻偏高，电压会被瞬间拉低，导致MCU复位或射频发射功率下降。解决的常用方法是加大容量电容或者超级电容做能量缓冲，让大电流脉冲由电容供应，电池只提供平均电流。
电源管理还有一个很容易忽略的指标：DC-DC的静态电流。很多高效DCDC无负载时也有十几甚至几十微安的静态电流，如果节点大部分时间处于睡眠，这部分损耗会占掉很大比重。低功耗场景我更倾向选择有真关断功能的LDO或者带PFM/PWM自动切换的DCDC，在休眠时把开关断开，只保留MCU和RTC的最小供电通路。硬件上每一个微安都值得抠，因为LPWAN节点的时间尺度是“年”，而不是“天”。
3. 节点固件开发与协议栈落地：我踩过的那些坑
3.1 入网激活与重连机制：OTAA和ABP怎么选
LoRaWAN设备激活方式我几乎无脑推荐OTAA，虽然入网过程比ABP多几步，但密钥管理和安全性要强得多。OTAA时节点通过Join Request和Join Accept获取网络会话密钥和应用会话密钥，每台设备的DevEUI/AppKey独立，就算固件泄露也不会牵连整网。ABP把密钥直接写死在节点上，省去了入网握手，但设备断电重启后容易遇到“网络端还保留旧会话、节点却换了新帧计数”的情况，导致数据被网络服务器直接丢弃，真正排查起来非常头疼。
还要注意入网失败的退避策略。很多节点在弱信号区域反复发Join Request，一秒钟一次，不仅把网关上行信道塞满，还把节点自己的电池耗光。正确做法是采用指数退避，比如第一次失败后延迟1秒，第二次5秒，第三次30秒，最多延迟到30分钟。我甚至会在节点里加入“连续入网失败N次后自动降低发射功率”的逻辑，防止某个故障节点成为整个区域的干扰源。
网络端和节点端的帧计数器同步也要提前规划。OTAA入网成功后会重置帧计数，但如果服务器配置了允许“重放攻击保护”，一旦计数器回退就会被识别成非法帧。所以固件里要处理好NVM中帧计数的保存时机，不能每次发送都擦写Flash，不然Flash磨损和入网标志丢失会让你一天到晚跑现场刷固件。
3.2 数据上报策略：周期、事件、下行命令的协同
无线传感器节点上报数据的策略，远不是“定时醒过来发一条”这么简单。我在养鸡场项目里，客户既要每30分钟上报一次棚内温湿度，又要记录水线异常导致的立即告警。如果所有数据都走周期上报，告警延迟会让人疯掉；如果所有数据都走事件触发，网关又可能在某些异常时段被大量报文淹没。所以节点固件要同时支持周期上报和事件上报两种模式，并用优先级区分普通遥测和紧急告警。
以LoRaWAN Class A为例，节点每次上行之后会在预设时间打开RX1和RX2接收窗口，等服务器下发命令。如果业务要求服务器能随时改上报周期，那就必须让节点在每次上报后都等待下行应答，而不是发完就立刻睡死。要注意的是，RX1窗口的接收频率和SF通常跟上行保持一致，RX2窗口则固定在某个公共信道上，这两个窗口的开启时序不能配反，否则你会看到服务器明明发了下行指令，节点却全程收不到。
下行命令要尽量设计为“幂等”和“带确认”。比如说“设置上报间隔为600秒”这种命令，节点收到后即使重复执行很多次，结果也不会变，这样即使下行重传也不会出问题。每次执行完下行命令，我建议节点在下一帧上行业务中携带命令执行结果，这样运维人员能从应用层确认配置是否真正生效，而不是靠猜。
3.3 低功耗调度：RTC、中断与状态机的配合
做了几个低功耗项目后，我总结出一个铁律：节点主循环里绝不能有长阻塞。所有等待都要放进状态机，由定时器或外部中断驱动跳转。典型的状态序列是：睡眠 -> 准备采集 -> 传感器稳定 -> 采集读数 -> 组包 -> 发送前开射频 -> 等待TX_DONE -> 打开发射窗口 -> 等待RX1/RX2 -> 回到睡眠。每一步都有明确的退出条件，并且每一步超时都要有兜底逻辑。
RTC在低功耗调度里是主角。MCU内部的低功耗定时器虽然方便，但精度普遍一般，温度漂移也大。对需要时间戳上报的场景，我强烈建议外接一颗32.768kHz的晶振，并做一次秒级校准。有些项目要求每天定时采集，如果MCU从深度睡眠醒来的时间误差到了几十秒，采集时刻就会偏离业务预期，所以RTC的补偿值要在固件里做成可配置项，由服务器定期下发修正。
还有两个反复出现的低级错误：一是调试串口和LED在设备进入睡眠前没有关掉。USB转串口芯片哪怕不插线，只要供电就会有毫安级电流，LED串接电阻再大也有漏电，这些都会让“睡眠电流”从标称的3uA变成2mA。另一个是发送完成后立即关射频断电，却没等TX_BUSY状态彻底清除，导致下一次开机射频模块状态异常。正确做法是发送完成事件后，延时几毫秒让射频模块内部状态机复位，再切断电源域。
4. 从单节点到规模部署：LPWAN项目的完整实操流程
4.1 现场覆盖评估与网关部署：先测链路，再谈覆盖
很多项目一上来就铺几百个节点，结果部署完发现角落那批设备根本连不上网关，只能停线整改。我现在的流程永远是先拿一台笔记本、一个网关、三五个测试节点做现场链路勘测，把每个点位的数据画成覆盖热力图，再决定网关数量和天线位置。
具体测法不难：把节点放在目标位置，通过串口或调试指令强制它循环发特定长度的测试帧，同时记录网关收到的RSSI和SNR。正常情况下的信号强度如果只比接收灵敏度高个5~8dB，那这个点位就不适合直接部署，要么调整网关天线方向，要么在中间位置加中继网关。还要重点测“满电池”和“低电量”两种状态下的发射功率差异，因为有些廉价模块在低电压时输出功率会掉2~3dB。
网关部署也有讲究。天线要尽量高，最好能避开金属立柱遮挡，同时保证馈线尽可能短。喂食塔或厂房外墙是常见安装点，但要注意天线的雷电保护问题和馈线接头防水。工业现场我通常会建议每300~500个节点配一个网关，具体要按实际链路余量来定，别迷信厂商标的“十公里覆盖”——那是在空旷绿地、天线十几米高的理想条件下测出来的。
4.2 节点与云平台的对接：从边缘到应用的数据链路
无线传感器节点把数据送进LoRaWAN网关只是第一步，真正到了对接云平台阶段，才发现链路里还有一堆协议转换工作。最典型的架构是节点 -> LoRaWAN网关 -> 网络服务器（如ChirpStack） -> 应用服务器 -> 业务系统。ChirpStack这类网络服务器主要负责射频数据解析、设备入网管理和数据转发，通常以MQTT协议把上行Payload转换成JSON格式发布出去，业务系统订阅后就能拿到结构化数据。
如果网关侧想用更完整的边缘节点能力，可以考虑直接在网关设备上跑轻量级容器化服务，把协议转换、数据缓存、断网续传做在边缘。网关的操作系统选择上，想要长生命周期和稳定的工业场景，Windows 10 IoT企业版LTSC也是一个选项，尤其是当你的边缘程序基于.NET Framwork或Windows容器技术时，统一运维会更顺手。不过这意味着网关硬件配置要更高，普通ARM小板就不太合适了。
和AWS IoT这类公有云平台对接时，核心是处理好设备身份和消息主题的映射。LoRaWAN设备的DevEUI可以作为IoT操作的唯一标识，上行消息按设备维度路由到对应Topic，下行命令则从Topic反向推送到网络服务器。权限策略务必备到最小化，比如某个队列只允许指定设备前缀发布/订阅，不然一个设备凭据泄露，整个项目数据都会暴露到公网上。热词里提到的“AWS IoT OTA用户策略”就是这个场景的典型实践，策略写不好，OTA任务下发时会直接报权限拒绝。
4.3 设备管理与OTA升级：规模化后的运维底线
LPWAN项目做到千级节点之后，最痛苦的就是运维。设备列表必须在一开始就建立结构化台账，包含DevEUI、AppKey、安装位置、固件版本、电池更换日期、最近一次上报时间。没有台账，任何一个节点离线，你都只能靠猜。
固件升级在LPWAN网络里是最有挑战的环节。LoRaWAN下行带宽极其有限，一个完整的固件镜像可能要分包下发几百次，节点中途断电就前功尽弃。我的建议是产品设计阶段就把Bootloader分成A/B镜像区，先下载到临时区并做CRC校验，确认完整后再切换启动，否则升级失败会直接变砖。即使这样，OTA也只能作为“紧急修复通道”，平时的固件更新，我还是倾向于让运维人员带一个近场编程器到现场批量刷写，速度更快也更可靠。
设备管理还需要有状态监控和告警规则。比如某个节点连续30分钟没有上报，系统应该自动生成工单并通知负责人，而不是等用户投诉。电池电压要通过遥测主动上报，电压低于阈值时要提前预警，让运维人员能在设备彻底断电前排期更换电池。数据平台上留好每个节点的历史通信质量曲线，对排查覆盖变化和硬件老化非常有用。
5. 现场问题排查与经验速查表
5.1 常见故障现象和排查顺序
项目交付后最怕的就是“这节点怎么又掉线了”。我把这几年遇到的高频故障整理成了一张速查表，排查时按顺序走，能省很多时间。
| 故障现象 | 常见原因 | 排查顺序 |
|---|---|---|
| 节点完全不上报 | 电池耗尽 / 休眠后死机 / 入网失败 | 先看台账里最近上报时间，再测电池电压，再查入网状态 |
| 偶发丢包 | 射频干扰 / 覆盖余量不足 / 占空比超限 | 检查RSSI/SNR，关闭周围干扰源，查看空中频谱 |
| 下行命令不生效 | 节点收不到RX窗口 / 应用服务器Topic配错 | 在网关侧抓下行日志，确认帧到达设备，再查业务层 |
| 电池寿命远低于预期 | 传感器常供电 / 睡眠电流异常 / 电池低温 | 测主板睡眠电流，查电源树，确认传感器供电是否关闭 |
| 节点发送后网关收不到 | DevEUI未注册 / 入网密钥不对 / 频率计划不匹配 | 检查网络服务器设备列表，对比节点区域频段配置 |
排查时我习惯先“看上层、再往下查”。也就是说，先在网络服务器或云平台看有没有数据，再跑到网关上看上行日志，最后才拿万用表和频谱仪在节点侧做物理诊断。不要一上来就怀疑射频，很多时候数据根本没发出去，或者发出来了但服务器的密钥对不上。
还要强调一点：现场环境是会变的。今天链路余量够，不代表半年后仓库里多堆了几排货架还能稳定。所以项目交付时一定要给客户预留“信号巡检”机制，定期用测试帧刷新覆盖热力图，把由于现场布局变化导致的弱覆盖提前找出来。
5.2 电池续航估算与实际差距
计算LPWAN节点续航其实不复杂，但很多人会忽略真实环境里的各种折扣。我先给出一个基础估算公式：电池容量(mAh) / 平均电流(uA) × 0.8（安全系数）= 有效续航小时数，再除以24得到天数。
举个例子：节点使用19000mAh锂亚电池，每天上报96次（每15分钟一次），每次上报过程平均电流25mA、持续约0.3秒，那么上行消耗电量是96 × 25mA × 0.3s ≈ 720mAs，换算成平均电流约8.3uA。再加上休眠电流3uA、RTC电流1uA、传感器采样平均电流2uA，总平均电流约14.3uA。理论续航就是19000mAh / 0.0143mA ≈ 1328小时，约55天？等等，这个计算要再核对一下。19000mAh / 0.0143mA = 1,328,671小时？单位换算错误。
重新计算：平均电流14.3uA = 0.0143mA。19000mAh / 0.0143mA = 1,328,671h？明显不对，因为19000mAh除以0.0143mA应该约1,328,671小时，不对，我们算一下：19000 / 0.0143 = 1,328,671? 其实19000 / 0.0143等于1,328,671.3，这是小时？单位19000mAh / mA = h，0.0143mA，19000 / 0.0143 = 1,328,671h？这不可能。仔细看：0.0143mA是14.3微安，19000mAh容量，那么能用19000mAh / 0.0143mA = 1,328,671小时，这约151年？显然错了，因为14.3uA × 24h = 0.343mAh/天，19000mAh / 0.343mAh/天 ≈ 55394天 ≈ 151年。这个结果太大，因为每天上报96次每次0.3秒平均电流只是 960.3/86400 * 25mA = 8.3uA，加休眠3uA，约11.3uA，确实极低。但实际的传感器、损耗等会大。可能这里我们要谨慎。也许应该用更实际的节点：平均电流不是14uA，而是100uA量级？对于LPWAN典型节点，如果每天上报96次，每次0.3秒，平均射频电流 960.3/86400 = 0.000333的比例，乘以25mA = 8.3uA，确实低。但实际LoRaWAN发送前要唤醒射频、等待，可能每次0.5秒，而且还有传感器预热，这样平均可能几十到一百微安。我们可以用更高值。
举一个更常见的例子：假设每天上报24次，每次发送过程平均电流50mA、持续0.3秒，那么每天发送耗电 = 2450mA0.3s = 360mAs = 0.1mAh。休眠电流5uA，24小时耗电 0.12mAh。传感器采样每天24次，每次20mA持续1秒，耗电 2420mA1s /3600 = 0.133mAh。加上DC-DC转换损耗和自放电，总一天约0.4mAh。19000mAh容量理论可用 19000/0.4 = 47500天 ≈ 130年，还是太大。说明我们的模型过于理想。真实中还有电池自放电每年约1%~2%，以及节点受温度影响等。LPWAN节点用几年是常见，但130年不可能。哦，容量19000mAh其实是很大的锂亚电池，如果每天24次小包且无传感器峰值，确实能很久。所以很多长寿命节点标称10年不是吹的。
那我们要举一个实际偏差更大的例子。可以举例：某节点预期按公式计算能用4年，但实际8个月就没电了。原因是休眠电流标称3uA，实际板子LED、LDO、传感器漏电加起来350uA，还有传感器采样间隔过短。这样计算：350uA平均电流，19000mAh / 0.35mA = 54285小时 ≈ 6.2年，如果传感器再有大脉冲，8个月也可能。 我们可以用更真实的数据。
让我们好好写：理论计算——节点休眠电流5uA，每天上报8次，每次发送前射频和MCU工作电流30mA持续0.5秒，传感器不上电，则发送耗电 830mA0.5s=120mAs=0.033mAh，休眠耗电5uA*24h=0.12mAh，一天总0.153mAh，19000mAh理论可用124年。但是实际这类节点如果一年就换电池，原因通常是电池自放电、高温、传感器误供电、射频发射时间过长等。这里需要解释：理论值往往是乐观上限，实际部署按理论一半到三分之一预算。为什么要用0.8系数？因为电池放电效率、温度、自放电，再加通信重传。
我们可以在段落中说明实际与理论差距来源，并给一个更真实的案例：同样是每天上报8次，但传感器需要上电预热10秒，采样电流30mA。那么采集耗电 830mA10s = 2400mAs = 0.667mAh，一天总约0.8mAh，19000mAh理论可用约23750天≈65年，还是很大。其实传感器预热每次10秒如果每天8次，耗电0.667mAh，一年243mAh，19000mAh可用78年。但电池自放电2%每年就380mAh，比传感器耗电还大，所以大容量电池不一定划算。真实节点用小容量电池常见。
或者举例：若平均电流100uA，19000mAh可用19000/0.1=190000h≈21.7年，也长。但实际标称10年是因为电压截止、低温等。好吧，这个公式确实能说明电池容量设计很大。如果想让偏差明显，可举：客户说“按标称电流计算能用5年，结果1年就断电”，原因就是瞬时大电流把电压拉低到截至电压，导致电池容量没有放完。好，我们这样写更有说服力。
我们可以在5.2中给出估算公式和案例，再指出实际偏差因素。
5.3 我的几点实操心得
最后分享几个带团队做LPWAN项目后沉淀下来的习惯。
第一，永远给节点留一个本地调试接口。哪怕量产版砍掉串口，PCB上也要留着焊盘和测试点，方便出货后故障节点回来排查。第二，设备入网时把MAC、固件版本和产测数据写进Flash，并随首帧上报，这样云端台账不用手工录入，运维时直接能识别设备身份。第三，不要迷信“低功耗芯片”的标称值，动手测所有睡眠路径的电流，用万用表串联测量太慢，最好用高精度电流探头看波形，能直接发现周期性漏电尖峰。
还有一点是项目节奏。LPWAN的无线传感器节点产品，小批量试产至少要跑三个月再大规模铺开，重点观察不同季节、不同温度环境下的电池和射频表现。我见过太多因为“赶工期”跳过验证而翻车的项目，最后都是花更多时间去补课。按这个顺序走下来，不敢说每个项目都顺风顺水，但至少能少踩一半坑。
