1. 智能表计为什么偏偏选中LoRa，而不是Wi-Fi或者NB-IoT
这些年我做智能表计相关的无线通信方案，接触过不少做水表、电表、燃气表的厂商。每次聊到通信选型，开场基本都是同一个问题：为什么不能用Wi-Fi，或者直接上运营商的NB-IoT？这问题很合理，毕竟Wi-Fi便宜、NB-IoT有运营商背书，看起来都不差。但真正把表计装到现场跑一轮，你就会发现LoRa在“无人值守、电池供电、海量节点、深覆盖”这四个维度上，恰好卡在了一个别人够不着的位置。
先看Wi-Fi。Wi-Fi的优点是速率高、模组便宜、生态成熟，但它的致命伤是依赖本地网络基础设施。智能表计安装的位置往往在地下管井、楼道强电井、户外表箱，这些地方要么完全没有Wi-Fi信号，要么信号弱到没法稳定连接。就算家里有路由器，一旦用户重启路由、换密码、开了访客隔离，表计就掉线了。你总不能派人工挨家挨户去重新配网，那跟人工抄表没有本质区别。Wi-Fi在智能家居设备上能用，是因为那些设备本身就在室内、插座供电、断网了影响不大；但表计不一样，它的安装环境和供电方式决定了它必须走一条更“野”的路线。
再看NB-IoT。NB-IoT确实是运营商级LPWAN技术，覆盖好、安全性高，我承认它在很多场景下是优解。但问题在于，表计厂商对它的态度一直是“又爱又怕”。爱的是它背靠运营商基站，信号覆盖不用自己操心；怕的是资费成本和网络主动权不在自己手里。每一块表计都需要一张SIM卡，哪怕每月只传几十KB数据，也要按连接数收费。大规模部署的时候，这笔费用会直接吃掉整个项目的利润空间。更麻烦的是，项目如果部署在偏远地区，比如山区水源地、郊区的农业灌溉监测点，运营商的NB-IoT网络可能压根就没覆盖到，你想用都用不了。
LoRa的定位恰好避开了这两个极端。它不需要Wi-Fi那样的本地宽带环境，也不需要运营商基站，用的是ISM免授权频段，在中国是470-510MHz。你只需要自己部署几台网关，就能覆盖几平方公里的城区范围。表计端用的是低功耗射频芯片，一颗电池可以撑五到十年。对表计行业来说，这意味着两件事：第一，网络在自己手里，不受运营商信号覆盖的制约；第二，单点通信几乎零边际成本，规模越大优势越明显。
我记得2023年接手过一个北方城市的二级供水管网监测项目，现场有将近四千块远传水表，分散在三个城区和一个工业开发区。第一轮方案会上，运营商给出的NB-IoT报价算下来每块表每年要额外付几十块连接费，再加上表计模组本身的成本差异，整体预算立刻上浮了六位数。后来我们把方案切到LoRaWAN，用12台室外网关覆盖全部区域，网关和表计全部走私有网络，三年下来通信这一块的边际成本基本就是电费和维护人工。这就是LoRa在智能表计项目里最打动人的地方——它是一种“资产化”的网络，而不是“租赁式”的网络。
如果你正在做表计相关的产品规划，我的建议是不要一上来就纠结协议细节，先想清楚三件事：你的表计装在什么环境（地下还是室外）、你的网络是自建还是依赖运营商、你的产品生命周期打算做几年。这三个问题答完，选型方向基本就出来了。后面我会把LoRa从物理层到网络层的核心逻辑拆开讲，然后再进入实际部署里那些文档上不写的细节。
2. LoRa物理层到底强在哪：灵敏度、链路预算与抗干扰机制
很多刚接触LoRa的工程师容易把它理解成“就是FSK换了种调制方式”，这个认知偏差会直接影响后续的系统设计。实际上，LoRa用的是Chirp扩频调制，它跟传统FSK最大的区别在于：FSK靠频率偏移携带信息，而LoRa把信息编码到线性调频信号的起始频率变化里。这个看起来不起眼的差异，带来了一系列射频性能上的根本性提升。
2.1 接收灵敏度和扩频增益是怎么换算的
LoRa最常被引用的指标是接收灵敏度。SX1262在SF12带宽125kHz的条件下，典型灵敏度能做到-137dBm左右，而普通FSK接收机做到-110dBm已经算不错了。这中间将近27dB的差距，本质上就是扩频增益换来的。扩频增益的公式很简单：Gain = 10 * log10(码片速率 / 符号速率)，或者直接用扩频因子近似，每增大一个SF值，灵敏度大约提升2-3dB。
但这里有个容易忽略的权衡：SF越高，空中传输时间越长。SF12比SF7慢将近4倍，意味着同一个节点发同一包数据，占用信道的时间大幅增加。在表计场景里，数据包本身很小（几十字节），真正决定系统容量的不是数据量，而是“每个节点占据信道的时间片”。所以实际部署里，我不会让所有节点都无脑用SF12，而是根据距离和链路质量动态分配SF7到SF11，这样既保证覆盖，又让网关的空中容量不至于被少数远距离节点耗尽。
回到链路预算上，一个典型的城区LoRa链路可以这样估算：发射功率按法规上限14dBm（通常我们按中国470MHz频段的无线电管理要求配置），发射端天线增益0dBi，接收端网关天线增益3-6dBi，路径损耗模型用Okumura-Hata或者更保守的COST-231。以2公里视距计算，自由空间路径损耗大约是82dB；城区环境下加上阴影衰落余量15-20dB，总损耗大约100dB左右。算下来链路余量依然有30dB以上，这就是为什么LoRa号称“一瓦不到的功耗覆盖几公里”的底气来源。
2.2 抗干扰特性不是玄学，是扩频机制的自然结果
LoRa还有一个经常被忽视的优点：它可以跟窄带干扰共存。因为LoRa信号本身是宽带扩频信号，当窄带干扰信号落在接收频带内时，解调器会把干扰能量摊到整个扩频带宽里，对信噪比的影响远小于FSK。这就是为什么在470-510MHz这个频段上，即便存在其他无线设备，LoRa网络依然能保持较高上报成功率的原因。
不过要注意，LoRa抗的是“窄带干扰”，不是“同频同参数干扰”。如果两片LoRa网络工作在完全相同的频率和扩频参数上，节点之间的碰撞依然是致命的。我在后续部署章节里会专门讲频率规划，这里先记住一个原则：用SF和频率两个维度去隔离不同网络，远比单纯加发射功率有效。
另外还有一个工程细节：LoRa解调是“捕获效应”主导的，也就是在接收窗口内，最先到达且信号强度足够的包会被锁定，后续同频包即使功率更强也可能被丢弃。这个特性在网关侧表现为“丢包不一定是因为信号差，而是因为碰撞窗口被占用了”。因此，AS923或者CN470频段下的终端上报策略，不能所有节点都整点上报，必须做随机化延时，这个在后面会展开。
2.3 四代LoRa芯片的演进差异
Semtech这些年发布的LoRa芯片，从SX1276/1278，到SX1261/1262，再到SX1268，以及新一代的LR1120/LR1121，内部架构和外围配套变化不小。对表计厂商来说，最关心的其实是SX1262和SX1276的差异。
SX1276是LoRa时代的“老黄牛”，性能稳定，但外围匹配电路复杂，静态电流偏高，而且由于是2013年前后的设计，很多指标在现在看来偏保守。SX1262/1268系列则把功耗和集成度往前推了一大步：发射电流降低了大概25%，接收电流从10mA以上降到5mA左右，还加入了DIO2作为RF switch控制和TCXO电源管理，外部BOM明显简化。更关键的是，SX126x在CAD（Channel Activity Detection）模式下功耗只有几微安级别，这对电池供电的表计来说意义重大。
如果你现在做新产品选型，我建议直接跳过SX1276，从SX1262或者SX1268起步。SX1262是Sub-GHz全频段，SX1268是专为470-510MHz优化的中国市场版本，后者在射频匹配上更省事。新一代LR1120还能同时支持2.4GHz频段以及卫星S频段，但目前表计行业主战场还在Sub-GHz，除非你有跨境物流追踪这种特殊需求，否则没必要现在就上LR1120。
3. 从一颗芯片到一块表计：LoRa模组选型与CAD模式的功耗实战
芯片是LoRa方案的“心脏”，但表计产品不是把芯片焊上去就能跑。从芯片到模组再到整机，中间隔着天线匹配、功耗管理、协议栈移植、认证测试四道坎。这一节我把选型和功耗设计的实战经验拆开讲，重点说说很多人一上来就会踩的CAD模式坑。
3.1 模组选型：自己设计还是直接买模组
表计厂商通常面临三选一：直接用Semtech原厂参考设计自己做模组、买第三方模组（比如亿佰特、安信可、USR等）、或者用内置LoRa的SoC方案。我的看法是：
- 如果年出货量在十万片以下，直接买成熟模组。自己做模组省下的那几块钱成本，摊不过射频调试的人力成本。
- 如果年出货量百万级，且团队里有至少一个懂射频的硬件工程师，可以基于SX1268做定制模组，核心原因是能省掉模组厂商的利润空间，并且在天线和结构上做更深的耦合设计。
- 如果产品是电池供电的燃气表、水表，建议考虑瑞萨、ST等厂商集成LoRa的SoC平台，比如STM32WL系列。这类芯片把MCU和LoRa射频集成到一颗芯片里，整体休眠电流可以做得更低，整机生产也好管控。
我自己做过的两个表计项目分别走了买模组和SoC两条路。前期量不大的时候买模组确实省心，SX1268模组的参考设计资料和量产经验都很成熟，直接拿来做FCC/CE/SRRC认证问题不大。后来量上去了，我们改用STM32WL55，整机功耗又降了一截，因为SI446x时代的分离方案里，MCU和射频芯片之间的SPI唤醒、状态切换都需要额外计时和电流开销，集成方案在这块确实有优势。
3.2 实测CAD模式的功耗波形
这里我要专门讲一下CAD模式，因为这是个“看起来简单、实测全是坑”的功能。
LoRa的CAD模式本质是让接收机以极低功耗周期性地监听信道上的前导码。如果检测到有效LoRa前导码，芯片就唤醒MCU进入完整接收；如果没检测到，芯片继续睡。对下行指令不频繁的智能表计来说，这是最省电的“准实时”监听方案。没有CAD的话，你要么让表计一直开着接收机（电流5-10mA，电池撑不了多久），要么只能等节点主动上报时顺带收下行数据（延迟不可控）。
我在实测中抓过SX1268在CAD模式下的电流波形，整个CAD周期大致分三段。第一段是射频前端上电和PLL锁定，电流会从睡眠态的1uA左右跃升到3-4mA，持续大概1ms；第二段是真正的信道检测，接收机打开，电流约4.5-5.5mA，持续一个符号周期（带宽125kHz、SF7约1ms，SF10约8ms）；第三段是检测结果输出和芯片自动回落睡眠（如果没检测到前导码），电流迅速回到uA级。整体算下来，一次CAD操作的平均功耗大约在几十微瓦秒级别，每秒钟做一次CAD，等效平均电流大约只有十几微安，对两节锂亚电池串联的表计来说完全可以忽略。
但这里有几个坑必须注意。第一，CAD检测的前导码长度要足够，LoRaWAN标准里前导码默认是8个符号，这是够的；但如果你用的是自组网私有协议，把前导码缩短到4个符号以下，CAD很可能会漏检。第二，CAD检测期间的接收窗口必须完整覆盖前导码符号，如果调度时机不对，比如前导码已经发了一半才开启CAD，芯片也能检测到，但留给MAC层解析的时间就变短了，极端情况会丢包。第三，CAD的周期和功耗是线性关系，建议在真实电池供电环境里用示波器或者功耗分析仪抓一整天的电流波形，而不是只看Datasheet上的典型值，因为实际电流还会被MCU唤醒、RTC走时、通信结束后电容放电这些因素污染。
3.3 一次完整的表计上报功耗拆解
我实际测试过一块基于SX1268模组的远传水表，整机上报流程是这样的：MCU从Stop模式唤醒（约3uA），读取流量传感器数据并计算（耗时约20ms，MCU核心电流约10mA），组装LoRa数据包（约5ms），开启SX1268发射（发射电流约45mA@14dBm，空中传输时间SF10/125kHz下约100ms），发送完成进入接收窗口待命（接收电流约5mA，持续1秒），最后关射频、MCU回到Stop模式。这一轮下来，总耗电量折合到容量单位大约是0.03mAh左右。如果这块表每天上报4次，加上CAD监听的消耗，全年总功耗大约在40-50mAh。一颗19000mAh的锂亚电池理论上可以用几十年，但实际要打折，因为电池自放电、极端低温容量衰减、电容漏电这些因素都在。现在的行业惯例是按十年寿命设计，留足余量。
4. 城区部署最坑的三件事：上行链路预算、网关布点策略和同频干扰
前面讲的都是单点设备的维度，真正让LoRa项目从Demo走向稳定运行，考验的是网络规划和部署。智能表计项目跟消费级产品最大的区别是：你没有第二次机会去现场改配置，四五千块表装进井盖下面，再想升级固件或者调参数，人力成本极其高昂。所以前期网络规划一定要做扎实。下面是我踩过坑之后总结出的三个关键点。
4.1 上行链路预算要按“最差节点”算，不要按“平均节点”算
很多人做覆盖规划时习惯取链路预算的中位数，然后画一个圆形的覆盖范围。这个做法在开阔的农业监测场景勉强能用，但在城区做表计根本行不通。城区表计的安装位置五花八门：有的在路面下的水表井里，金属井盖一盖，信号直接衰减15-20dB；有的在楼道强电井，周围全是钢筋混凝土；有的在小区绿化带的不锈钢表箱里，箱体本身又是一个衰减源。如果按平均值计算，你规划出来的覆盖半径至少有一半节点达不到网关灵敏度。
正确做法是先做现场抽样测试：在目标区域内选10%的节点位置，用便携式LoRa测试终端实测每种安装场景下的RSSI和SNR。然后取最差场景（通常是地下井盖+旁边停着车）的链路余量作为规划基准。如果最差场景的链路余量能保持10dB以上，整个网络的稳定性基本就有保障。如果实测下来最差场景余量不足，优先考虑调整网关位置或者增加网关数量，而不是单纯提高节点发射功率——法规对最大发射功率有硬性限制，而且提高功率会加剧同频干扰。
我经手的一个园区项目，最初的覆盖方案只在园区中心布了一台网关，理论计算覆盖3公里没问题。实测下来，园区边缘一处地下车库的表计上报成功率只有62%，原因就是地下车库入口的斜坡、混凝土顶板和停在车库入口的车辆三重衰减叠加，RSSI已经到了-132dBm，几乎贴着灵敏度极限。后来我们在车库出口附近加了一台小型吸顶网关，走有线回传，问题立刻解决，上报率回到99.7%。这个加网关的成本，比后期派人去现场逐一调整表计天线位置低得多。
4.2 网关布点不是画圆，要顺着表计密度和遮挡物走
网关布点的经验口诀，我总结成一句话：“宁密勿疏，宁低勿高，贴边不贴心”。
“宁密勿疏”是指在节点密度高的区域，网关数量不要卡着理论覆盖上限来。LoRa网关虽然是八通道并行接收，但当大量节点同时上报时，空中时隙依然会被占满。网关多一点，每个网关服务的节点数就少一点，碰撞概率天然下降。
“宁低勿高”有点反直觉。城区场景里，很多人觉得天线架得越高，看得越远，覆盖越好。实际上在470MHz频段，信号传播以地波和绕射为主，天线太高反而可能跨过节点所在的高度层，陷入“看得见但收不到”的尴尬。更常见的坑是天线与金属遮挡物之间的耦合衰减。我实测过，天线旁边半米内有一根垂直金属水管，RSSI会掉6-8dB。所以网关天线位置要选在空旷、无大面积金属遮挡的制高点，比如楼顶女儿墙或者路灯杆顶端，而不是随便绑在金属配电箱旁边。
“贴边不贴心”是网格规划的实操技巧。如果一个小区的表计分布在四周楼栋，而小区中心是大面积空地，网关应该贴着边缘节点密度的方向偏移，而不是放在几何中心。原因是节点上报的路径损耗主要受楼栋遮挡影响，顺着楼栋间隙布置网关，信号能通过“波导效应”传得更远；放在中心空地反而被四面楼栋围住，信号每个方向都要穿墙。
4.3 同频干扰：私有协议比LoRaWAN更容易踩的雷
国内470-510MHz频段是免授权频段，意味着除了你自己部署的LoRa网络，还有可能存在其他无线设备（比如一些远传抄表的老式FSK方案、无线摄像头的控制信道等）。同频干扰是城区部署绕不开的话题。
这里先说一个区分：LoRaWAN虽然是标准协议，但它的频段规划是按区域来的，CN470频段支持多信道跳频，抗干扰能力在线；而很多厂商自研的私有LoRa协议为了省事，往往是“固定频率+固定SF”，全网所有节点都在同一载频上工作。这种情况下，只要有一台外部设备在这个频率上发出信号，整个网络的丢包率就会明显上升。
应对策略分三层。第一层是部署前做频谱普查：用手持频谱仪或者SX1268的空闲信道检测功能，在目标区域扫一遍470-510MHz的频段占用情况，避开被持续占用的频点。第二层是网络规划时不要把频率和SF全部押在同一组参数上，可以按区域把节点划分为几个逻辑子网，分别使用不同的频率和扩频因子，让节点间碰撞概率大幅下降。第三层是持续监测：网关后台定期统计各频点的误包率和RSSI底噪，一旦发现某个频点被外部信号持续污染，需要及时调整该子网的频率配置。
我见过一个比较极端的案例：某小区物业在同一个频段装了几十台FSK制式的远传水表集中器，正好压在我们LoRa网络的一个固定频点上，结果我们那些使用该频点的表计上报成功率从98%跌到71%。后来我们改了频率规划，把受影响的子网整体搬迁到另一个空闲频点，上报率才恢复。这个教训说明，私有协议的频率规划不能“一次定终身”，要留出动态调整的机制。
5. 抄表数据上报链路：从传感器到平台的全流程时延与可靠性分析
搞定了无线链路，还要搞定“数据从哪来、到哪去”的问题。智能表计虽然叫“智能”，但它本质上还是一个数据采集终端，整个上报链路涉及传感器读取、本地处理、射频发送、网关接收、网络回传、平台解析六个环节。任何一个环节掉链子，都会表现为“抄表失败”。
5.1 上报成功率不是单一指标，要拆开看
很多项目经理只盯一个“上报成功率”，但上报成功率98%和98%之间的差距很大。我把上报失败拆成三类。
第一类是物理层失败，表现为节点发完包但网关没收到，或者收到后CRC校验失败。原因通常是信号弱、碰撞、干扰。这类问题靠调整发射功率、频率规划、网关布点解决。
第二类是协议层失败，最典型的场景是LoRaWAN里的确认帧丢失。节点发了数据，等着收网关的ACK，结果ACK没收到，节点按规则重传。重传本身不丢数据，但会占用信道，导致更多碰撞。在密集部署场景下，这种“ACK风暴”会把网络容量吃掉一大块。我们后来在一部分项目里干脆关掉了逐包确认，改成“批量确认+平台侧查漏补缺”，网络容量反而上来了。
第三类是平台侧失败，比如数据包到了网关，但回传链路（以太网、4G、光纤）抖动，或者平台解析程序有bug，导致数据没有入库。这类问题容易被归咎于“无线不稳定”，实际上根子在IT侧。所以排查抄表成功率异常时，一定要先确认网关到平台的链路是否通畅，再查无线侧。
5.2 时延不是越大越好，但也不是越小越好
LoRaWAN上报链路里，空中传输时间是纯物理开销：一个20字节的数据包在SF10/125kHz下大约耗时120ms，SF7下大约30ms。如果每个节点都独立上报，网关侧并发处理能力有限，大量节点集中在同一时刻上报就会出现排队。排队产生的时延不是固定的，取决于信道占用状态，可能从几十毫秒到几秒不等。
工程上，我会让上报策略做“时段离散化”：把一天划分为若干个上报窗口，每个窗口内每个节点的上报时刻由一个随机数决定。典型的做法是：设每日上报一次，节点在凌晨两点到五点之间随机选择一个时刻上报，这样全网节点的上报时延分布均匀，网关不会在某个瞬间被并发请求打满。对于需要在固定时间抄表的场景，比如阶梯电价需要的0点冻结数据，可以让节点在冻结时刻之后随机延迟30秒到5分钟上报，既满足业务要求，又避免全网并发。
5.3 重传机制的取舍：重传几次才合理
重传是把双刃剑。重传能提高单包成功率，但每多一次重传，就多占用一次信道资源。在LoRaWAN标准里，确认模式默认重传次数是7次，逐次递增的退避时间让节点在信道拥塞时能自然错开。但实测下来，表计这种小数据包场景，第三到第五次重传的边际增益已经很小，反而会因为挤占信道导致其他节点丢包。
我在自组网协议里会把重传次数限制在2-3次，并且开启“感知重传”机制：节点在重传前先做一次CAD，只有信道空闲才发，否则再退避。这套机制在密集城区部署中显著降低了碰撞率，整体上报成功率从96.4%提升到了99.1%。代价是重传引入的额外功耗略有增加，但对电池寿命的影响在可接受范围内。
6. 我踩过的三个典型坑：天线匹配、频段合规和固件升级
最后一部分，我讲三个不是靠看Datasheet能学会的实战教训。这三个坑我都在真实项目里踩过，写出来给后来者提个醒。
6.1 天线匹配：不要以为天线是“随便接上就能用”
LoRa模组的天线匹配是整个射频链路里最容易被低估的环节。拿SX1268来说，芯片的RFIO引脚输出阻抗是50欧姆，但实际天线在不同频点、不同环境下的阻抗会有偏移。如果天线与板子的匹配网络设计不当，驻波比偏高，发射效率会大幅下降。我在实验室里测过同一块板子换了两根不同的弹簧天线，同样设置为14dBm发射功率，实际辐射功率可以差到4-5dB。4-5dB意味着覆盖半径缩小将近三分之一。
所以，无论是买模组还是自己做板子，一定要做传导测试和辐射测试两件事。传导测试看发射功率是否真的达到标称值；辐射测试要在屏蔽室里或开阔场测EIRP，确认天线与整机的谐振点落在工作频段内。如果发现辐射功率偏低，通常不是芯片的问题，而是天线附近的地平面、金属结构件或者外壳影响了辐射效率。
6.2 频段合规：发射功率不是你想设多少就设多少
国内Sub-GHz免授权频段有明确的无线电管理要求，470-510MHz虽然开放，但发射功率和占空比都有严格限制。很多工程师习惯把LoRa发射功率直接拉满，觉得“功率大就是好”。但法规层面，超功率发射一旦被无线电管理机构测到，轻则整改，重则影响整个产品型号的核准证书。更实际的风险是，发射功率过大导致信号覆盖超出预期范围，与邻近区域的同频网络产生冲突，引发不必要的干扰投诉。
我的做法是：在产品配置工具里把发射功率做成“按地区预设”的选项，国内项目默认14dBm，并且加上软件限制，不允许用户随意调高。同时，在网关侧开启占空比限制算法，确保单台网关的发射占比不会触发法规红线。毕竟，一个项目跑三五年，如果中途因为合规问题被要求停网整改，损失远大于那一点点功率带来的覆盖增益。
6.3 固件升级：OTA是刚需，但别把网络容量搭进去
表计项目的固件升级是个容易被忽略的“隐形杀手”。项目上线后，算法要调参、协议要升级、安全补丁要打，如果每块表都需要人工到现场用烧录器升级，那运维成本会直接吞掉项目的利润。所以现在绝大部分LoRa表计产品都会做OTA固件升级。
但OTA升级对LoRa网络来说是个沉重的负担：一个完整的固件包哪怕做了差分压缩，也有几KB到几十KB，而LoRa单包有效载荷通常只有几十字节，意味着要传几十个甚至几百个分包。如果全网几千块表同时升级，网络容量瞬间耗尽，正常抄表业务都会受影响。
我的经验是给OTA升级设计独立的“升级窗口”和“分批策略”。比如选定凌晨抄表低峰时段，把节点按MAC地址分成20个批次，每批次只升级一部分，且升级期间暂停该批次的周期性抄表上报。这样虽然整体升级周期拉长到几天，但不会对主业务产生冲击。另外，升级过程中一定要设计断点续传和版本回滚机制，否则一旦升级包中途丢失导致节点变砖，跑现场救砖的成本远高于升级本身带来的收益。
7. 用实测数据说话：一个4800节点项目的网络容量与长期稳定性
前面讲了不少经验和理论，最后用一组真实项目的长期运行数据来收尾。这个项目是某市的地下水务监测网络，一共4800个LoRa节点，覆盖约18平方公里，核心业务是每30分钟上报一次水压、流量和电池电压数据。网络采用Semtech SX1268节点模组，搭配12台八通道网关，自建私有LoRa协议，频率规划为三组不同频点，扩频因子按区域动态配置。
先看网络容量。LoRaWAN的理论容量计算涉及信道占用时间、占空比、节点数、上报频率等多个参数。我们按实际参数测算：每个节点半小时上报一次，每次空中传输时间约180ms（SF10/125kHz），单通道的日占用时间约为节点数×次数×单次时长/86400秒。4800个节点、每天48次上报，算下来单通道占用率大约为5.8%，即便考虑重传和网关命令下发，整体信道负载依然控制在20%以内，这是LoRa网络能长时间稳定运行的安全区。
再看长期稳定性。我把系统连续运行12个月的数据拉出来：月平均上报成功率99.21%，最低的一个月是98.74%，出现在夏季雷雨多发的时段——那几天的强降雨导致部分井盖下的节点天线进水，信号衰减明显增加。排查后更换了防水等级更高的天线座，数据随即恢复。另一个有意思的发现是，电池电压的下降曲线比预期更平缓，按当前斜率估算，节点电池寿命可以达到9年，超过了设计指标。
我自己在这个项目里最大的体会是：LoRa从物理层到应用层，每一个环节的优化空间都比想象中大。芯片的灵敏度只有那么多，但链路预算怎么留、信道怎么规划、上报策略怎么设计、异常怎么排查，这些工程层面的功夫，才是决定一个LoRa网络到底能不能长期稳定运行的关键。回过头来看标题里那句话说得很准确——“Smart Metering Gear Taps Semtech LoRa Tech”，智能表计行业不是单纯“用”LoRa，而是把LoRa的物理特性和工程细节消化进产品的整个生命周期里。这也是我写这篇文章的初衷：希望后来者不要在同一个坑里再摔一次。
