1. 预付费电表的真正难点钱、电和无线链路必须同时在线做智能电表项目这些年我最深的一个体会是预付费电能计量和普通远程抄表完全是两种难度。普通抄表只需要每天把用电量传回来一次数据晚半小时甚至晚一天问题不大但预付费电表不一样用户手机扫码充值的那一刻充值指令必须可靠到达电表电表验完要回执后台要入账余额耗尽还要远程拉闸。任何一个环节掉链子要么用户充了钱用不上电要么电表欠费了还在供电这两件事在运营方眼里都是事故等级的问题。我参与的这套预付费方案最终通信选型落在Semtech的LoRa器件上。项目组的判断依据很直接LoRa工作在Sub-GHz频段使用Chirp扩频调制城市环境单跳覆盖能做到一公里以上郊区开阔环境可以到几公里甚至十几公里单节点成本低非常适合电能表这种每天只传几十字节、但必须传得稳传得远的业务模型。而且LoRa可以自建网络数据链路完全握在自己手里不像蜂窝方案那样依赖运营商网络覆盖也不存在单卡流量费越用越心疼的问题。这里先打个岔因为最近总有人搜LoRa微调LoRa模型结果搜到了我的文章然后留言说完全看不懂。这两个名字纯属拼写撞车AI圈说的LoRA是Low-Rank Adaptation是机器学习里做模型微调的一种低秩适配方法而本文说的LoRa是Semtech公司推出的Chirp扩频调制技术解决的是无线传输问题。赛道完全不同不懂射频的人看到满天飞的lora模型还以为LoRa技术改行了实际两边代码都不互通别搞混。为什么预付费电表的通信比想象中苛刻因为它要求的不是高带宽而是极高可靠性下的低速率双向通信。余额扣减在电表本地执行通信链路负责把充值金额安全写进电表的ESAM安全模块把电表的冻结数据、事件记录、余额状态传回后台。链路一次失败可以重传但连续失败就会造成充值延迟所以整个系统必须围绕ACK确认、重传补偿、离线补发来设计LoRa的低速率特性反而倒逼我们把协议做得更严谨。1.1 预付费逻辑给电表硬件带来的额外负担普通电能表只要计量准确就行但预付费电表本质上是一个嵌在墙上的POS机。它至少得同时干三件事持续累计有功电能按照本地价目表把电能换算成金额并从余额中扣减在余额低于告警阈值或者归零时驱动磁保持继电器完成告警甚至分闸。这三件事全部在本地完成而且不能依赖网络。也就是说哪怕LoRa链路断了两天电表依然要按预付费规则正常扣费、正常跳闸。通信链路在预付费系统里的角色更像是一个对账通道而不是实时控制通道。这个定位决定了我们选用LoRa而不是4G或者Wi-Fi它不需要高吞吐需要的是广覆盖、低功耗、低成本以及不受运营商布网进度制约的自主可控性。1.2 LoRa技术在电能表场景的几项硬指标从实际项目角度看Semtech LoRa打动我们的几个点很具体。第一是灵敏度SX1262在SF12、125kHz带宽下接收灵敏度可以做到-137dBm左右意味着微弱的信号也能解调这对埋在表箱、地下室、楼道角落的电表非常关键。第二是抗干扰Chirp扩频对同频窄带干扰有天然抑制能力和FSK、GFSK方案比在复杂的城区电磁环境里通信成功率明显高。第三是免授权频段国内用470-510MHz欧洲用863-870MHz美洲用902-928MHz不需要给运营商交连接费集中器加几百个节点就构成一张私有抄表网。2. 三层系统架构电表计量、集中器汇聚与后台计费平台整套预付费计量系统的架构可以分成三层终端电表、集中器、后台平台。每一层都有自己独立的职责层与层之间用协议衔接。很多项目在实验室跑得好好的一到现场就出问题问题往往出在层与层之间的接口上而不是单层内部。2.1 终端电表侧计量芯片、MCU、LoRa模组和继电器的协作电表终端内部的关键器件有这么几类。计量芯片负责把电压电流采样换算成有功电能常用方案有钜泉的RN8302B、HLW8032这类专用计量芯片也有直接在MCU里用ADC采样的低成本方案。MCU负责跑预付费逻辑、协议栈和事件管理。LoRa模组负责无线收发常见的是集成Semtech SX1276/SX1262的模组通过SPI/UART和MCU对接。另外还有一颗ESAM安全芯片专门存密钥和做加密运算这是预付费电表区别于普通抄表终端的核心部件。继电器选择的是磁保持继电器因为普通继电器在通电保持时需要持续耗电几十台设备不明显但对于电表这种常年通电且可能被装在密闭表箱里的设备发热和功耗都不能接受。磁保持继电器只在动作瞬间给一个正脉冲或负脉冲平时不耗电触点状态保持。MCU必须在上电初始化时先读取继电器的实际状态再决定是否驱动合闸否则会出现在断电恢复后继电器意外合闸的隐患。2.2 集中器承上启下的数据枢纽集中器放在台区或者小区配电房向下通过LoRa和几百台电表通信向上通过网络和后台平台通信。它本质上是一个协议转换器和数据缓存器。LoRa链路是不稳定的后台不会直接去连每一块电表因为那样既慢又不可控。集中器负责维护一张节点设备列表定时轮询电表收集冻结数据、余额状态和事件记录然后打包通过4G或者以太网上传给后台。集中器的设计里最容易忽视的是本地存储。网络抖动导致后台暂时连不上时集中器至少需要缓存一周以上的采集数据否则后台一断数据就丢。我们现场遇到过集中器掉线三天恢复后大量补传数据拥塞上行通道的情况后来加了按优先级排队、先传事件后传冻结数据的策略才算理顺。2.3 后台平台计费引擎、密钥管理与运营可视化后台是整个系统的大脑。它维护用户账户、电价表、充值订单、电表档案以及各表的密钥分散因子。充值流程里后台收到用户支付成功后生成一个包含金额、电表地址、订单序号、时间戳的指令用该表独立的密钥加密后通过集中器下发。电表收到指令后内部解密验证更新安全模块里的余额再回传确认。后台只有在收到确认后才会把订单状态标记为完成。后台还有一个容易被忽略的工作密钥管理。如果所有电表都用同一把密钥一旦某台电表被攻击整个网络的通信加密就全废了。所以项目上用根密钥分散因子的方式每台电表按自己的地址分散出独立密钥后台只保存根密钥和分散算法具体密钥不落库即使数据库泄露也无法直接解密现场通信数据。3. Semtech LoRa器件选型与射频链路设计要点选LoRa器件的时候很多人第一反应是直接买SX1276模组就行了反正都兼容。实际上Semtech的产品线分成好几代选不对型号后面的功耗和灵敏度指标会差出一大截返工成本很高。3.1 SX1276/SX1262/LR1110怎么选型号核心优势典型应用场景注意事项SX1276/SX1278经典成熟成本低资料多水电气表、传感器对功耗不极端敏感出货量大但生产批次注意翻新料SX1261/SX1262功耗更低灵敏度更高支持TCXO电池供电表计、窄带广覆盖场景SX1261发射功率只有15dBmSX1262到22dBmLR1110内置GNSS和Wi-Fi扫描支持测向资产追踪、物流定位计量项目用不太上成本偏高我们的预付费电表项目用的是SX1262模组核心考量是接收灵敏度。电能表安装在铁皮表箱内、楼道角落天线环境差同样发射功率下灵敏度每高1dB边缘表计的通信成功率可能就差好几个百分点。SX1262在SF12/BW125kHz下接收灵敏度约-137dBm比第一代SX1276略好而且TCXO版频率稳定性更好对温度变化适应性更强。3.2 射频匹配、天线设计与链路预算计算射频部分是LoRa项目中最容易翻车但看起来最简单的环节。模组参考设计里通常有射频匹配网络但实际产品还要加SAW滤波器和天线匹配。SAW滤波器用来抑制带外干扰尤其在470-510MHz频段城市里可能混着其他无线设备的杂散信号不加滤波器接收机灵敏度会被压制得很惨。天线方面的经验是PCB天线适合空间紧凑的产品但增益和一致性都比较差弹簧天线成本低需要净空区外置胶棒天线性能最好适合集中器和需要外引的表计。电表装在铁皮箱里时内部天线几乎是被屏蔽的我们最终采用模组射频口引出一段同轴线把天线固定在表箱外侧的方案通信成功率从70%提升到98%以上。链路预算可以直接算一下。假设电表端发射功率14dBm天线增益2dBi集中器接收灵敏度-137dBm天线增益3dBi工作频率470MHz通信距离1km。自由空间路径损耗公式为L 32.4 20 * lg(距离km) 20 * lg(频率MHz)代入得到 L 32.4 0 2 * lg(470) × 10约等于85.8dB。链路余量 14 2 3 - 85.8 - (-137) 70.2dB。这意味着即使在雨衰、树叶遮挡、墙体穿透等多因素叠加下信号余量依然非常充裕。如果距离拉到5km路径损耗约99.8dB链路余量仍有56.2dB依然可用。3.3 LoRa参数配置扩频因子、带宽和编码率怎么定LoRa调制有四个核心参数扩频因子SF、信号带宽BW、编码率CR和中心频率。SF越高接收灵敏度越好但空中传输时间越长BW越宽速率越快但灵敏度会下降。常用组合和对应速率可以参考扩频因子带宽编码率大概速率灵敏度参考SF12125kHz4/5293bps-137dBmSF10125kHz4/5980bps-132dBmSF7125kHz4/55469bps-123dBmSF7250kHz4/510938bps-120dBm电能表的业务数据量很小充值命令加状态确认也就几十字节但如果集中器下面挂着500台电表每台都用SF12的话单次轮询的空中时间会非常长。我们的做法是下行命令用SF10上行数据用SF10/SF7自适应保证关键指令可靠同时让日常上报尽量快。现场还能根据信号强度远程调整某台表的扩频因子而不是统一烧死配置。4. 预付费计费协议与安全机制充值、扣费和拉闸怎么闭环预付费系统的协议设计核心不是数据怎么传而是钱怎么安全地动。充值指令一旦被伪造或重放损失是实打实的。所以协议层面必须把加密、防重放、确认、对账这些机制全部考虑进去。4.1 数据帧结构设计LoRa数据帧在应用层可以自己定义我们用的精简帧结构大致是同步字 目的地址 源地址 功能码 数据域 消息序号 校验MAC CRC。LoRa物理层本身有CRC校验但应用层还是保留了一个MAC字段用AES-128-CMAC对整帧签名防止中间人篡改。消息序号是单调递增的电表收到序号小于等于上次的帧直接丢弃这是防重放攻击的基础。功能码要覆盖的类型不多充值写余额、读取余额、读取冻结数据、远程合闸、远程拉闸、校时、透传升级。每种功能码的数据域结构必须固定方便集中器和电表都做严格的长度校验。协议字段里预留了扩展位方便后续增加阶梯电价参数下发、费率和时段切换等能力。4.2 充值指令的安全下发流程一次完整的远程充值时序是这样的用户支付成功后后台生成充值订单并把金额订单号时间戳用该表的分散密钥加密填充到指令里指令经集中器转发给电表电表收到后先验证MAC再检查序号是否大于当前值然后在ESAM安全模块内部完成指令解密和余额追加电表把新的余额哈希回传给后台后台验证后更新订单状态。关键点在于余额变更必须在安全模块内部完成。MCU只负责搬运数据不能参与金额计算否则攻击者只要用调试器把MCU程序改了就能无限充值。ESAM芯片里跑着固化的COS密钥无法读出指令解密和余额操作都在芯片内部进行从物理层面提高破解门槛。4.3 扣费逻辑与继电器控制扣费逻辑有两种常见实现。一种是定时扣费每隔一个固定周期读取计量芯片的电能累加值按当前电价折算成金额后从余额扣减另一种是阶梯扣费按累计用电量区间切换电价比如月用电100度以内一个价超过部分另一个价。电价表要支持后台远程下发因为现场改电价是常态不能每次都派工人上门换表或写卡。继电器控制上我们做了预跳闸流程当余额低于告警阈值时电表先通过本地蜂鸣器和短信通知用户余额归零后不在第一时间切断而是进入一个宽限期宽限期结束后才执行分闸。分闸动作前会先发一次即将拉闸的广播帧给集中器一个记录事件的时间窗口。执行分闸后MCU会回读继电器的辅助触点状态确认是否真正断开防止出现继电器触点粘连导致名义拉闸实际供电的风险。4.4 防篡改和现场安全LoRa链路本身是开放无线电波谁都能收到所以加密是必须的。但加密不等于安全还有几类攻击要防截获重放、伪造指令、替换终端。防重放靠序号递增防伪造靠CMAC签名防替换终端靠密钥分散和ESAM一表一密。此外电表还记录开盖事件、掉电事件、余额清零事件一旦外壳被打开电表就记录下事件并通过LoRa上报后台看到开盖事件后可以安排现场核查。5. 低功耗、时隙调度与现场覆盖优化电表通常是市电供电所以LoRa模组的功耗压力没有水表气表那么大但依然要设计到位。原因有两个一是停电时电表需要靠电池把停电事件上报出去这要求模组在这段时间内功耗极低二是如果产品出口到经常停电的地区电池供电时间直接决定了运维成本。5.1 常见功耗模式划分与CAD模式的价值LoRa模组的工作状态可以分成四种发射、接收、CAD检测、睡眠。发射电流最高根据发射功率不同几十毫安到一百多毫安都有接收模式电流在5-10mA量级睡眠模式在微安级。CAD模式是Semtech特有的信道活动检测模组只在极短时间里打开接收前端检测信道上有没有LoRa前导码如果检测到再切到完整接收模式。用CAD模式做低功耗监听的思路是模组大部分时间睡觉每隔一段时间醒来一次执行一次CAD检测如果发现信道上有发给自己的前导码就进入完整接收如果没发现立刻回到睡眠。这样可以把平均功耗压到很低。我们的集中器在下发数据前会先发送一段较长的前导码确保电表在CAD检测窗口能碰巧听到。5.2 集中器轮询策略与时隙规划几百台电表共用一个集中器时如果大家都随机上报碰撞率会很高。我们的方案是定时轮询为主事件上报优先抢占。集中器按设备地址顺序在每个时隙点召测某台电表电表只在被召测时回复或者在有紧急事件时主动发送。LoRa物理层是半双工相同频点上同一时刻只允许一台设备发所以时隙长度要按最差情况计算SF10、50字节载荷、125kHz带宽空中时间约300-400ms再留出一定保护间隔单时隙安排在800ms比较稳妥。频点规划上我们把上行和下行放在不同频点避免集中器发送过程中干扰其他电表的上行数据。现场如果存在同频干扰源还可以在集中器侧动态切换频点并在广播帧里通知所有电表跟随跳频类似简化的跳频通信。这套机制对城市里偶发的对讲机、无线麦克风干扰非常有效。5.3 现场覆盖优化的几个实操手段部署阶段我们会用频谱仪和LoRa分析工具对每个集中器覆盖区域做一轮摸底测试。测试不是简单看RSSI还要看信噪比SNR和误包率。RSSI很高但SNR很差说明有干扰源RSSI低但SNR正常说明是距离或遮挡问题处理方向完全不同。集中器天线的高度对覆盖影响极大。同一台集中器天线从离地3米移到10米边缘电表的RSSI能提升10dB以上。现场安装时集中器尽量往杆顶装天线和金属物体保持至少半米距离。电表侧如果有条件外置天线比PCB天线可靠得多特别是在铁皮表箱里内天线基本等于没有。6. 现场部署踩坑记录与排查方法项目上线阶段我们踩过的坑不少挑几个有代表性的复盘一下给后来人省点时间。6.1 通信成功率上不去先从天线位置找原因第一个项目试点实验室里通信成功率99%装到现场直接跌到70%左右。一开始怀疑是LoRa参数配置不对调了扩频因子和带宽效果不明显。后来发现电表全部装在铁皮表箱里天线被金属箱体屏蔽得严严实实。解决办法是给电表加外置天线引线在表箱面板上开一个天线孔用防水接头引出天线。改造后成功率回到98%以上。这个坑提醒我们实验室环境永远代表不了现场电表产品从设计阶段就要考虑表箱的屏蔽效应预留天线引出接口而不是等到现场再返工。6.2 集中器带载能力不足导致轮询时间过长有一批集中器挂了300台电表按SF10轮询理论上每台800ms时隙一轮需要240秒看起来还能接受。但现场有几十台表分布在边远位置通信质量差重传次数多一轮轮询经常超过10分钟。这会导致充值指令下发延迟用户充值后半小时电表才通电投诉电话不断。我们对策略做了调整把边缘设备切到SF7或者SF8提高通道速率对通信质量好的设备时隙压缩到400ms对重传超过3次的设备单独进入慢速重试队列不再占用正常轮询资源。调整后整轮轮询时间从10分钟压缩到4分钟以内。6.3 充值指令丢失的排查链路一次现场反馈某台电表充值后迟迟不通电。后台看订单状态是已下发但未确认。我们从三个方向排查先看集中器日志发现指令已经转发到射频口再看电表串口日志定位到电表收不到任何帧。最后怀疑是下行频点存在干扰。用频谱仪蹲守后发现干扰源来自附近一家工厂的设备频率正好落在下行频点上。切换到备用频点并通知电表跳频后问题解决。这次排查的教训是无线问题要用无线的手段查光看软件日志不够频谱仪和现场测试是必备工具。6.4 时钟同步与校时机制预付费电表涉及到阶梯电价的时段切换和事件时间戳如果RTC时钟漂移会导致费用计算错误。我们实测过普通晶振的RTC每天可能漂移几秒一个月下来就好几分钟。集中器每天校时一次电表收到校时帧后如果偏差超过阈值就立刻校准偏差小则缓慢调整避免电表时间忽前忽后。7. 给后来者的几点实用建议整套系统跑下来我最大的感受是预付费计量系统的技术难点不在单点而在端到端的可观测性。LoRa通信本身很成熟真正的坑都在设备安装环境、现场干扰、协议健壮性这些看似不起眼的地方。建议之一从项目一开始就给电表增加信号强度上报能力。电表定期把自己的RSSI、SNR、最近一次通信成功率上报给集中器后台能看到每台设备的通信质量分布。这样做的好处是运维人员不用扛着设备去现场测信号在后台就能直接判断哪些表处于弱覆盖区域提前处理。建议之二集中器要保留详细的通信日志尤其是每条下行指令的发送时间、重传次数、ACK结果。排查充值失败问题时这可能是唯一能还原现场真相的数据。建议之三所有现场调试接口都留一个LoRa透传测试通道。把射频模组切换成透传模式配合手机端的频谱分析工具现场工程师可以直接判断是天馈问题、频点干扰还是协议问题排查效率能提升一倍以上。最后再分享一个小技巧测试LoRa通信可靠性时不要只看成功率要看最差5%设备的成功率。预付费系统里越是边缘设备越需要充值如果边缘设备通信成功率只有80%那它每次充值都可能要折腾好几轮。把优化资源倾斜给最差的5%整体系统的满意度会大幅上升。智能电表这种产品用户不会因为99%的台区好用而夸你只会因为1%的表充不上电而投诉。所以边缘设备的体验才是项目真正的生死线。