1. 从机械水表到智能水表这个项目要解决的四个核心痛点去年我们接了一个小项目要求给某小区做一批智能水表终端主控指定用STM32。接到需求的时候我第一反应是水表这东西机械式的用了上百年凭什么要换等我把现场跑了一圈才明白传统抄表模式的痛远比想象中严重。先说最直观的人工抄表。物业或者供水公司每个月要派人挨家挨户敲门看表盘记住小数点后两位的数字再录入系统。高层住宅一栋楼几十户一天能跑三四栋就算效率高的赶上住户不在家还得贴条子等下次补抄。我们当时统计过一个中型小区大约六百户抄表员每月至少要投入四个人天误差率在百分之二左右碰上估抄的月份误差更没谱。然后是漏损问题。机械水表只能感知用户侧有没有用水管道老化漏水、表后长时间细流、马桶水箱慢性渗漏这些情况表是转的但人在抄表周期内根本发现不了。等到月底对账发现总表和分表对不上再去逐户排查黄花菜都凉了。第三个痛点是阶梯水价。很多城市已经实行阶梯计价同一个用户用水量跨过阶梯线单价要跳档。机械表的机械齿轮只记累计流量档位切换判断、剩余额度计算都要靠后台人工完成时效性很差用户当天用得多了还是少了完全要靠自己心算。第四就是抄表账单的信任问题。用户怀疑你抄多了供水公司怀疑表走慢了最后还是得拆表送检。一天一报甚至实时上报的智能水表这些问题基本都能化解掉。所以这个项目要解决的就是四件事自动计量、定期上报、低功耗运行、异常监测。而STM32在整个系统里扮演的角色就是负责把这些事串起来的一块核心大脑。需要说明的是这个项目是我们做的一个通用性设计示例属于典型的模拟项目X。不过思路完全来自真实的产品化过程下面的选型、参数和代码片段都可以直接当作参考基线来用。2. 硬件选型逻辑主控、计量传感器、通讯模组的选择与取舍2.1 主控选型为什么是STM32L系列而不是F系列接到需求后第一个问题就是选哪颗片子。很多人一看项目标题里写着STM32单片机习惯性就想用STM32F103毕竟资料多、例程全、入门教程遍地都是。但我第一时间否掉了这个方案原因就两个字功耗。水表不是插着电源的设备它的工作环境决定了它必须用电池供电而且一挂就是五六年。普通碱性电池组或者锂亚电池组容量有限F103跑起来全速运行电流能到几十毫安就算只在抄表瞬间醒来工作待机时的漏电流也很难压到理想水平。智能水表行业里大家心照不宣的设计准则是整机静态电流必须压在微安级而且越低越好。所以我选的是STM32L071系列。这颗属于超低功耗L系列片上资源满足水表需求绰绰有余64KB Flash存固件和参数足够20KB RAM跑协议栈也够用内置12位ADC可以做电池电压监测和传感器信号判断RTC支持日历功能能实现精确的定时唤醒。最关键的是它支持多种低功耗模式Stop模式下整机电流可以做到3μA左右配合RTC闹钟可以做到周期性唤醒而不增加静态功耗。F103确实强但在这个项目里属于大马拉小车而且马自己还特别能吃草。低功耗场景里选型的第一性原理是够用刚好而不是性能越强越好。2.2 计量传感器霍尔脉冲传感 vs 干簧管水表计量有两条路线一是用干簧管二是用霍尔传感器。干簧管便宜很多老式远传水表都在用。原理是表内部有个磁钢指针每转一圈磁钢经过干簧管位置时让触点吸合一次产生一个脉冲。优点就是便宜、电路简单、无源输出不需要供电。但干簧管的缺点也很明显它是机械触点存在触点抖动和寿命问题。水表安装环境往往潮湿触点氧化之后接触电阻漂移实际运行中经常出现漏计或多计的情况。霍尔传感器是非接触式的用磁场感应产生电平变化没有机械磨损寿命长而且可以检测磁场的极性方向和强度这为我们后面做防磁攻击检测留下了伏笔。缺点是比干簧管贵一点、需要供电但对STM32系统来说供电根本不是事。我选的方案是霍尔传感器搭配一个受力结构固定的转盘支架转盘上装一块小磁钢每转动一圈霍尔输出两个脉冲。机械部分采用双脉冲逻辑也就是两个传感器错开九十度放置既能做到正反转识别也能通过两路信号的相位关系估算瞬时流速。这里提醒一句霍尔传感器的信号输出不是理想的方波磁钢靠近时信号边沿变化需要时间所以后端必须接比较器整形。如果图省事直接接MCU的GPIO中断频繁触发时很容易出问题。我们实际电路里用的是内置滞回比较器的霍尔开关芯片输出已经是干净的数字电平MCU这边只需要处理软件去抖。2.3 通讯模组NB-IoT是智能表计的当前最优解通讯方案是智能水表的关键分歧点。项目调研阶段比过三条路Wi-Fi、LoRa、NB-IoT。Wi-Fi方案的优点是带宽大、模块便宜缺点是功耗太高而且需要用户家里有路由器并且常开。水表装在楼道管井里信号穿墙衰减严重用户体验很不稳定。LoRa的优点是自组网、单点覆盖远、功耗低但问题是需要自己架网关一个小区要部署好几台集中器再想办法回传互联网前期投入和后期运维成本都不低小项目根本撑不起来。NB-IoT走运营商基站不需要自己建网关模组休眠电流可以做到微安级单次上报峰值电流也在可控范围内。水表装在管井里NB-IoT的低频段信号穿透力比LTE强不少地下室的成功率明显优于普通4G。虽然每个月的流量费是一笔成本但比起自建网关的维护开销这笔钱花得值。而且现在的NB-IoT模组已经支持了PSM省电模式和eDRX扩展非连续接收专门为这类低速、低频次、低功耗的物联网终端设计的简直就像为水表量身定做的。2.4 供电方案锂亚电池超级电容供电方案直接决定了电池能用多久。我们选的是锂亚硫酰氯电池也就是常说的锂亚电池这是智能表计行业的标准选择。这种电池的特点是能量密度极高自放电率低特别适合长时间小电流放电场景。但它有一个大缺点瞬时大电流放电能力弱而NB-IoT模块发射瞬间电流能冲上几百毫安甚至更高。解决方法就是给电池并联一个超级电容。平时电池以小电流给超级电容涓流充电通讯模组发射时由超级电容提供瞬时大电流。这样电池的放电电流被抹平了寿命能延长不少。超级电容容量选1F左右电压5.5V经过LDO后给系统供电。这套电源方案实测下来整机在完全没有用水、每天只上报一次的条件下静态电流维持在微安级别一节19000mAh的锂亚电池理论寿命可以做到六到八年具体计算思路在第四节展开。3. 计量精度与累计流量计算我把数据采集方案推倒重来了三次3.1 用外部中断计数脉冲但去抖不能省流量计量是整个系统的根本功能这一块做不靠谱后面通讯做得再漂亮也是白搭。第一次做原型的时候我想得比较简单两路霍尔信号分别接PB0、PB1配置成外部中断上升沿触发在中断回调里给计数器加一。跑了两天发现累计值总是比实际用水量偏大仔细查下来是信号抖动导致的重复计数。霍尔芯片输出的信号虽然有滞回但机械转盘的震动、水流冲击引起的抖振会让信号在临界位置附近反复跳变每次都触发中断计数自然就虚高了。解决方案分两层。硬件上霍尔输出到MCU之间串了一个RC低通滤波时间常数约5ms把窄脉冲毛刺滤掉。软件上中断触发后不是立刻计入总量而是启动一个10ms的定时窗口窗口结束再去读取电平状态做二次确认。确认有效之后才增加计数。这么做虽然牺牲了一点响应速度但换来的是计数的可靠性。水表计量场景里宁可丢一个边沿也不能把一次抖动计成三四个脉冲。这是整个项目里我学到的第一课真正的工程稳定不是靠某一个环节做得多么精巧而是靠每一层都做一点粗笨但有效的防护叠加出整体的可靠。3.2 双传感器相位识别与瞬时流量估算前面说的两路霍尔错开九十度安装除了防抖之外还有个重要用途判断水流方向。两路信号在正常情况下脉冲序列的相位关系是固定的。水流正向流动时A路上升沿比B路提前四分之一周期反向流动时则相反。在中断回调里记录两路信号的电平状态通过一个状态机就能判断当前是正转、反转还是不转。这个小功能在后续对接预付费模式的时候非常有用一旦用户试图倒装水表或者人为反接水路系统马上就能识别并标记异常事件上报后台。瞬时流量的估算就更有意思了。我们用的转盘每转一圈对应一个固定的容积假设是1升。只要测出两个脉冲之间的时间间隔用容积除以时间就是流速。考虑到MCU的定时器精度足够高单位时间内的脉冲频率乘以容积就是瞬时流量。算完瞬时流量再做一次低通滤波平抑掉水流扰动带来的噪声显示给用户看的读数就稳定多了。3.3 数据保存策略掉电不丢累计量累计用水量是水表的命根子绝不能因为掉电就归零。所以我们把累计流量存进了STM32L071的内部Flash分配了三个扇区做循环备份每个扇区存完整的数据帧累计脉冲数、累计标准升数、上次上报数值、时间戳、校验字。写入时先写备份扇区再更新主扇区。每次写入前检查校验如果主扇区校验失败就自动从备份恢复。这里多提一句Flash擦写次数有限所以不能每次脉冲变化都写也不能写得太频繁。我们把写入策略定为累计每增加10升或者距离上次写入超过24小时才触发一次Flash存储而且Flash写入期间中断优先级要处理好避免丢脉冲。这点在联调的时候确实踩到过坑后面专门用一节来讲。4. 低功耗设计是智能水表项目的成败关键4.1 先把功耗账算清楚一节电池到底能撑多久在开始低功耗编程之前我们先把设计指标写在纸上静态待机电流目标小于10μA每日定时上报次数默认1次可配置为最高6次单次上报唤醒工作时间小于2秒唤醒工作平均电流小于30mA电池容量19000mAh锂亚电池算一下一天只上报一次的场景每天平均耗电约等于24小时静态耗电加上一次上报耗电。 24小时静态耗电大概是10μA乘以24小时等于240μAh。 一次上报假设2秒、平均30mA等于60秒毫安换算成毫安时约16.7μAh。除以3.3V系统电压再折算升压损耗实际从电池侧的消耗大约在20到25μAh。 一天总耗电大约265μAh一年是96.7mAh六年大约580mAh。对比19000mAh的电池容量余量非常充裕。实际上最大的耗电项从来不是上报而是频繁唤醒、传感器供电、屏幕刷新这类容易被人忽视的点。低功耗设计的目标是把系统的平均电流压下去而不是单纯省掉某一次工作的电流。4.2 睡眠架构RTC周期唤醒加外部事件唤醒STM32L071的Stop模式是低功耗的主力CPU停转、时钟关掉、RAM和寄存器保持电流只有微安级。我们用RTC闹钟做周期唤醒到点之后系统自动醒来上报数据报完再睡。另外一个重要唤醒源就是计量脉冲的中断一旦有水流系统立即唤醒进入工作模式保证不丢脉冲。这里面的一个设计细节是**水表在用水期间的电流并不低因为要保持CPU运行去数脉冲。**如果用户一直开着水龙头系统就一直在运行状态。为了进一步压功耗我们设置了超时懒睡机制水流停止超过30秒系统进入低功耗模式保留外部中断唤醒通道水流再次开始时第一个脉冲立刻唤醒CPU。4.3 实测功耗数据和三条优化路径整个系统调试完成后我们用精密电流探头做了24小时实测。结果令人满意纯待机模式下整机静态电流稳定在8μA左右其中有将近2μA是电源LDO自耗属于硬开销省不掉。RTC闹钟触发到系统完成一次上报整个唤醒、采数、发数、入眠的完整周期约1.4秒全程平均电流46mA比理论值略高主要是模组发射时的瞬时电流算进去了。我们为了把静态电流从初始的18μA压到8μA做了三件事第一把GPIO模式全部过了一遍。未使用的引脚一律配置为模拟输入模式避免浮空输入造成额外电流。注意是模拟输入模式不是浮空输入浮空输入还会因为电平不确定导致漏电。第二关掉不用的外设时钟。STM32L的时钟树里每个外设都有独立的门控时钟。我们把SPI、USART这些用不到的外设时钟全部关掉用的时候再打开。这个小改动直接省掉了1.5μA。第三换成外部32.768kHz晶振给RTC计时关闭内部低速时钟。内部RC振荡器虽然省了晶振物料成本但静态功耗高一个量级而且时间精度差长期累计误差大。智能水表涉及到阶梯水价的日切换时间精度直接影响资费计算所以低功耗晶振的钱不能省。4.4 电源监测低电量报警是水表的最后防线电池总有耗尽的一天。我们在ADC上接了一个分压电阻网络每24小时唤醒时读一次电池电压。电压低于设定的阈值后系统在正常上报数据帧里增加一个低电量告警标志位提醒后台安排换表。阈值不能设得太死因为锂亚电池在低温环境电压会下降正常在零下十度时电压可能比常温低0.3V左右直接按常温阈值判断很容易误报。我们做的处理是把电池电压和环境温度同时上报后台结合温度曲线做综合判断。5. 通讯与数据链路NB-IoT上报、校时、OTA的协议设计5.1 传输层UDP还是TCP这是个问题NB-IoT模组本身支持TCP和UDP。TCP可靠但有连接维护的开销对低功耗终端不友好。UDP简单高效但丢包率高。我们最终选的是UDP加应用层确认机制终端发一帧数据服务器收到后回一个确认帧终端在规定时间内收到确认就认为发送成功收不到就退避重发。退避累计三次还没成功数据落本地待传队列等下个周期继续传。这样既避免了TCP的长连接开销又保证了关键数据的可达性。5.2 数据帧格式别把简单事情做复杂帧格式设计成定长紧凑型最大限度减少空中传输字节数。单帧内容包含设备ID、累计流量、瞬时流量、电池电压、设备状态、时间戳、校验值总共四十六个字节按十六进制编码后九十二个Hex字符。协议字段顺序固定服务器端解析简单调试也容易。一个关键经验时间戳不要主设备生成后直接发。水表内部RTC虽然校准过但长时间运行还是会有漂移。我们在帧里带的是本地时间服务器收到后比较自身时间如果偏差超过五分钟回复确认帧时顺带下发标准时间终端收到后自动校准RTC。这比单独做一次校时交互省电得多。5.3 上报策略周期上报加事件上报的组合拳每天固定周期上报一次给服务器这是最基本的。但在两种特殊情况下要立即上报第一种是流量异常。比如系统检测到连续四小时没有用水但累计脉冲仍在增长这通常意味着表后管道破裂或者水箱漏水系统要立即上报异常事件。第二种是磁干扰。有人在表附近放强磁铁试图让转盘停转霍尔传感器的磁感应强度检测就会发现磁场异常这时立即上报防磁告警。防拆开关被非法打开也是同理。事件上报的数据帧与周期上报的帧格式完全一致只是设备状态字段里加了事件标志。后台收到后可以立刻生成工单推给运维人员。这一套逻辑在整个项目联调时效果出奇地好某次测试我们故意放磁铁在水表上方不到三十秒后台就弹出了告警响应链路完全跑通。5.4 离线补传与本地缓存断网也不能丢数据再好的网络也保不齐基站故障或信号盲区。终端在连续三次上报失败后会把数据帧缓存到Flash缓存容量设计为能存九十天的日数据。等网络恢复终端在下一次定时唤醒时先清积压缓存再上报当日数据。这样即便通信中断三个月后台也能找到完整的记录对账时不会出现缺口。6. 系统联调中的三大坑和对应的排查方法6.1 坑一两个霍尔传感器抢中断导致计数错乱第一次联调功能板的时候正转测试计数正常反转测试却出现了诡异的现象计数器不仅减不对还偶尔多计。用示波器同时抓两路信号才看明白两路中断的回调里都调用了同一个计数函数函数内部没有做临界区保护A中断触发到一半被B中断打断两个中断同时修改计数变量数据就乱了。解决方案很直接在计数函数入口关中断操作完再开中断。M3/M0内核上直接用临界区加锁是最粗暴也是最有效的做法。处理完之后再跑一千次反转测试计数全部正确。6.2 坑二NB-IoT模块入网瞬间把系统拉垮这个坑差点把项目打回重做。模组上电入网瞬间发射电流达到峰值电源电压瞬间跌落MCU掉电复位然后模组重启再入网形成一个复位-入网-拉垮-复位的死循环。排查过程花了两天。先怀疑电池供电不足换了大容量电池还是复发。后来用示波器看电源轨发现模组发射时VCC纹波超过四百毫伏MCU复位阈值大约是2.8V电压跌落后直接触发BOR复位。问题出在超级电容容量选小了1F的电容在低温下容量衰减瞬时大电流支撑不住。处理方法是把超级电容加大到4F同时在模组和主控之间加了一个MOS管开关正常待机时模组完全断电只有需要上报时才给模组供电。这一改不仅解决了复位问题还把静态电流又压低了1.5μA。从那以后我养成了一个习惯所有低功耗项目里的通讯模组一律用MOS管做电源开关绝不让模组长期挂电。6.3 坑三校准时间后RTC反而越来越不准系统跑了一个月后发现上报时间戳偏差越来越大从最初的几秒漂到十几秒。打开RTC配置代码检查发现校准逻辑有问题服务器下发的标准时间在RTC事件中断服务函数里直接被写入但写入时没有考虑从读取到写入这一小段时间的累积每次校准都引入了几百毫秒的系统性误差。这个问题的正确做法是当校准事件发生时先读取RTC当前时间计算本次校准引入的偏差把偏差补偿值存入Flash每次时间戳输出时累加这个补偿量。虽然单次校准的误差不大但水表运行的周期是以年计的误差会逐日累积。想清楚这个逻辑之后RTC校时精度从原来的秒级提升到了毫秒级后台对账完全不再需要人工修正。7. 未来扩展方向远程阀控、预付费与管网监测7.1 加一个阀门控制模块就变成远程阀控水表硬件上只需要在出水管路上加装一个电机阀门MCU增加一路电机驱动和阀位反馈检测。后台下发指令终端执行开阀或关阀操作并反馈完成状态。配合预付费余额不足自动关阀、欠费复通开阀就构成了完整的远程阀控逻辑省去人工上门关阀的成本。阀控动作时电机瞬间电流大电源设计上要预留裕量或者采用先断水再低电压动作的慢速阀门方案。7.2 预付费与阶梯水价的实时计算有了每日上报和远程配置能力把费率表预下发到终端终端本地根据累计流量执行阶梯计价余额不足时提前预警甚至自动关阀这就是完整的预付费水表形态。终端本地计价的好处是不依赖网络实时在线哪怕通信中断一个月计费逻辑仍然在跑恢复联网后把账期数据补传上去即可。7.3 管网漏损监测从单表智能到系统智能当大量智能水表接入后台就不再是单台设备的问题了。把每个水表上报的瞬时流量按时段聚合建立小区日用水曲线通过总表和分表的数据比对就能定位漏损区域。再进一步用水曲线和人口流动、季节气温建立关联模型就能做到更精准的供水调度。这块内容已经不是当前STM32单片机范围内的实现问题但作为项目的自然延伸我在后续会专门写一篇基于后端数据平台的文章讲设备接入后如何做数据处理与异常识别。简单提一句是为了说明智能水表项目真正的价值点不只在一块电路板上而是设备和数据链路组成的整个闭环。如果此刻有人问我做这个项目最大的体会是什么我会说嵌入式项目做到的从来不是某一个惊艳的单点功能而是把计量、通讯、功耗、安全这些基础模块一个个做到扎实再把它们之间交叉影响的坑一个个填平。单片机代码本身不难难的是把每个细节都照顾到让整个系统像水表一样默默转上几年不出错。
1. 从机械水表到智能水表这个项目要解决的四个核心痛点去年我们接了一个小项目要求给某小区做一批智能水表终端主控指定用STM32。接到需求的时候我第一反应是水表这东西机械式的用了上百年凭什么要换等我把现场跑了一圈才明白传统抄表模式的痛远比想象中严重。先说最直观的人工抄表。物业或者供水公司每个月要派人挨家挨户敲门看表盘记住小数点后两位的数字再录入系统。高层住宅一栋楼几十户一天能跑三四栋就算效率高的赶上住户不在家还得贴条子等下次补抄。我们当时统计过一个中型小区大约六百户抄表员每月至少要投入四个人天误差率在百分之二左右碰上估抄的月份误差更没谱。然后是漏损问题。机械水表只能感知用户侧有没有用水管道老化漏水、表后长时间细流、马桶水箱慢性渗漏这些情况表是转的但人在抄表周期内根本发现不了。等到月底对账发现总表和分表对不上再去逐户排查黄花菜都凉了。第三个痛点是阶梯水价。很多城市已经实行阶梯计价同一个用户用水量跨过阶梯线单价要跳档。机械表的机械齿轮只记累计流量档位切换判断、剩余额度计算都要靠后台人工完成时效性很差用户当天用得多了还是少了完全要靠自己心算。第四就是抄表账单的信任问题。用户怀疑你抄多了供水公司怀疑表走慢了最后还是得拆表送检。一天一报甚至实时上报的智能水表这些问题基本都能化解掉。所以这个项目要解决的就是四件事自动计量、定期上报、低功耗运行、异常监测。而STM32在整个系统里扮演的角色就是负责把这些事串起来的一块核心大脑。需要说明的是这个项目是我们做的一个通用性设计示例属于典型的模拟项目X。不过思路完全来自真实的产品化过程下面的选型、参数和代码片段都可以直接当作参考基线来用。2. 硬件选型逻辑主控、计量传感器、通讯模组的选择与取舍2.1 主控选型为什么是STM32L系列而不是F系列接到需求后第一个问题就是选哪颗片子。很多人一看项目标题里写着STM32单片机习惯性就想用STM32F103毕竟资料多、例程全、入门教程遍地都是。但我第一时间否掉了这个方案原因就两个字功耗。水表不是插着电源的设备它的工作环境决定了它必须用电池供电而且一挂就是五六年。普通碱性电池组或者锂亚电池组容量有限F103跑起来全速运行电流能到几十毫安就算只在抄表瞬间醒来工作待机时的漏电流也很难压到理想水平。智能水表行业里大家心照不宣的设计准则是整机静态电流必须压在微安级而且越低越好。所以我选的是STM32L071系列。这颗属于超低功耗L系列片上资源满足水表需求绰绰有余64KB Flash存固件和参数足够20KB RAM跑协议栈也够用内置12位ADC可以做电池电压监测和传感器信号判断RTC支持日历功能能实现精确的定时唤醒。最关键的是它支持多种低功耗模式Stop模式下整机电流可以做到3μA左右配合RTC闹钟可以做到周期性唤醒而不增加静态功耗。F103确实强但在这个项目里属于大马拉小车而且马自己还特别能吃草。低功耗场景里选型的第一性原理是够用刚好而不是性能越强越好。2.2 计量传感器霍尔脉冲传感 vs 干簧管水表计量有两条路线一是用干簧管二是用霍尔传感器。干簧管便宜很多老式远传水表都在用。原理是表内部有个磁钢指针每转一圈磁钢经过干簧管位置时让触点吸合一次产生一个脉冲。优点就是便宜、电路简单、无源输出不需要供电。但干簧管的缺点也很明显它是机械触点存在触点抖动和寿命问题。水表安装环境往往潮湿触点氧化之后接触电阻漂移实际运行中经常出现漏计或多计的情况。霍尔传感器是非接触式的用磁场感应产生电平变化没有机械磨损寿命长而且可以检测磁场的极性方向和强度这为我们后面做防磁攻击检测留下了伏笔。缺点是比干簧管贵一点、需要供电但对STM32系统来说供电根本不是事。我选的方案是霍尔传感器搭配一个受力结构固定的转盘支架转盘上装一块小磁钢每转动一圈霍尔输出两个脉冲。机械部分采用双脉冲逻辑也就是两个传感器错开九十度放置既能做到正反转识别也能通过两路信号的相位关系估算瞬时流速。这里提醒一句霍尔传感器的信号输出不是理想的方波磁钢靠近时信号边沿变化需要时间所以后端必须接比较器整形。如果图省事直接接MCU的GPIO中断频繁触发时很容易出问题。我们实际电路里用的是内置滞回比较器的霍尔开关芯片输出已经是干净的数字电平MCU这边只需要处理软件去抖。2.3 通讯模组NB-IoT是智能表计的当前最优解通讯方案是智能水表的关键分歧点。项目调研阶段比过三条路Wi-Fi、LoRa、NB-IoT。Wi-Fi方案的优点是带宽大、模块便宜缺点是功耗太高而且需要用户家里有路由器并且常开。水表装在楼道管井里信号穿墙衰减严重用户体验很不稳定。LoRa的优点是自组网、单点覆盖远、功耗低但问题是需要自己架网关一个小区要部署好几台集中器再想办法回传互联网前期投入和后期运维成本都不低小项目根本撑不起来。NB-IoT走运营商基站不需要自己建网关模组休眠电流可以做到微安级单次上报峰值电流也在可控范围内。水表装在管井里NB-IoT的低频段信号穿透力比LTE强不少地下室的成功率明显优于普通4G。虽然每个月的流量费是一笔成本但比起自建网关的维护开销这笔钱花得值。而且现在的NB-IoT模组已经支持了PSM省电模式和eDRX扩展非连续接收专门为这类低速、低频次、低功耗的物联网终端设计的简直就像为水表量身定做的。2.4 供电方案锂亚电池超级电容供电方案直接决定了电池能用多久。我们选的是锂亚硫酰氯电池也就是常说的锂亚电池这是智能表计行业的标准选择。这种电池的特点是能量密度极高自放电率低特别适合长时间小电流放电场景。但它有一个大缺点瞬时大电流放电能力弱而NB-IoT模块发射瞬间电流能冲上几百毫安甚至更高。解决方法就是给电池并联一个超级电容。平时电池以小电流给超级电容涓流充电通讯模组发射时由超级电容提供瞬时大电流。这样电池的放电电流被抹平了寿命能延长不少。超级电容容量选1F左右电压5.5V经过LDO后给系统供电。这套电源方案实测下来整机在完全没有用水、每天只上报一次的条件下静态电流维持在微安级别一节19000mAh的锂亚电池理论寿命可以做到六到八年具体计算思路在第四节展开。3. 计量精度与累计流量计算我把数据采集方案推倒重来了三次3.1 用外部中断计数脉冲但去抖不能省流量计量是整个系统的根本功能这一块做不靠谱后面通讯做得再漂亮也是白搭。第一次做原型的时候我想得比较简单两路霍尔信号分别接PB0、PB1配置成外部中断上升沿触发在中断回调里给计数器加一。跑了两天发现累计值总是比实际用水量偏大仔细查下来是信号抖动导致的重复计数。霍尔芯片输出的信号虽然有滞回但机械转盘的震动、水流冲击引起的抖振会让信号在临界位置附近反复跳变每次都触发中断计数自然就虚高了。解决方案分两层。硬件上霍尔输出到MCU之间串了一个RC低通滤波时间常数约5ms把窄脉冲毛刺滤掉。软件上中断触发后不是立刻计入总量而是启动一个10ms的定时窗口窗口结束再去读取电平状态做二次确认。确认有效之后才增加计数。这么做虽然牺牲了一点响应速度但换来的是计数的可靠性。水表计量场景里宁可丢一个边沿也不能把一次抖动计成三四个脉冲。这是整个项目里我学到的第一课真正的工程稳定不是靠某一个环节做得多么精巧而是靠每一层都做一点粗笨但有效的防护叠加出整体的可靠。3.2 双传感器相位识别与瞬时流量估算前面说的两路霍尔错开九十度安装除了防抖之外还有个重要用途判断水流方向。两路信号在正常情况下脉冲序列的相位关系是固定的。水流正向流动时A路上升沿比B路提前四分之一周期反向流动时则相反。在中断回调里记录两路信号的电平状态通过一个状态机就能判断当前是正转、反转还是不转。这个小功能在后续对接预付费模式的时候非常有用一旦用户试图倒装水表或者人为反接水路系统马上就能识别并标记异常事件上报后台。瞬时流量的估算就更有意思了。我们用的转盘每转一圈对应一个固定的容积假设是1升。只要测出两个脉冲之间的时间间隔用容积除以时间就是流速。考虑到MCU的定时器精度足够高单位时间内的脉冲频率乘以容积就是瞬时流量。算完瞬时流量再做一次低通滤波平抑掉水流扰动带来的噪声显示给用户看的读数就稳定多了。3.3 数据保存策略掉电不丢累计量累计用水量是水表的命根子绝不能因为掉电就归零。所以我们把累计流量存进了STM32L071的内部Flash分配了三个扇区做循环备份每个扇区存完整的数据帧累计脉冲数、累计标准升数、上次上报数值、时间戳、校验字。写入时先写备份扇区再更新主扇区。每次写入前检查校验如果主扇区校验失败就自动从备份恢复。这里多提一句Flash擦写次数有限所以不能每次脉冲变化都写也不能写得太频繁。我们把写入策略定为累计每增加10升或者距离上次写入超过24小时才触发一次Flash存储而且Flash写入期间中断优先级要处理好避免丢脉冲。这点在联调的时候确实踩到过坑后面专门用一节来讲。4. 低功耗设计是智能水表项目的成败关键4.1 先把功耗账算清楚一节电池到底能撑多久在开始低功耗编程之前我们先把设计指标写在纸上静态待机电流目标小于10μA每日定时上报次数默认1次可配置为最高6次单次上报唤醒工作时间小于2秒唤醒工作平均电流小于30mA电池容量19000mAh锂亚电池算一下一天只上报一次的场景每天平均耗电约等于24小时静态耗电加上一次上报耗电。 24小时静态耗电大概是10μA乘以24小时等于240μAh。 一次上报假设2秒、平均30mA等于60秒毫安换算成毫安时约16.7μAh。除以3.3V系统电压再折算升压损耗实际从电池侧的消耗大约在20到25μAh。 一天总耗电大约265μAh一年是96.7mAh六年大约580mAh。对比19000mAh的电池容量余量非常充裕。实际上最大的耗电项从来不是上报而是频繁唤醒、传感器供电、屏幕刷新这类容易被人忽视的点。低功耗设计的目标是把系统的平均电流压下去而不是单纯省掉某一次工作的电流。4.2 睡眠架构RTC周期唤醒加外部事件唤醒STM32L071的Stop模式是低功耗的主力CPU停转、时钟关掉、RAM和寄存器保持电流只有微安级。我们用RTC闹钟做周期唤醒到点之后系统自动醒来上报数据报完再睡。另外一个重要唤醒源就是计量脉冲的中断一旦有水流系统立即唤醒进入工作模式保证不丢脉冲。这里面的一个设计细节是**水表在用水期间的电流并不低因为要保持CPU运行去数脉冲。**如果用户一直开着水龙头系统就一直在运行状态。为了进一步压功耗我们设置了超时懒睡机制水流停止超过30秒系统进入低功耗模式保留外部中断唤醒通道水流再次开始时第一个脉冲立刻唤醒CPU。4.3 实测功耗数据和三条优化路径整个系统调试完成后我们用精密电流探头做了24小时实测。结果令人满意纯待机模式下整机静态电流稳定在8μA左右其中有将近2μA是电源LDO自耗属于硬开销省不掉。RTC闹钟触发到系统完成一次上报整个唤醒、采数、发数、入眠的完整周期约1.4秒全程平均电流46mA比理论值略高主要是模组发射时的瞬时电流算进去了。我们为了把静态电流从初始的18μA压到8μA做了三件事第一把GPIO模式全部过了一遍。未使用的引脚一律配置为模拟输入模式避免浮空输入造成额外电流。注意是模拟输入模式不是浮空输入浮空输入还会因为电平不确定导致漏电。第二关掉不用的外设时钟。STM32L的时钟树里每个外设都有独立的门控时钟。我们把SPI、USART这些用不到的外设时钟全部关掉用的时候再打开。这个小改动直接省掉了1.5μA。第三换成外部32.768kHz晶振给RTC计时关闭内部低速时钟。内部RC振荡器虽然省了晶振物料成本但静态功耗高一个量级而且时间精度差长期累计误差大。智能水表涉及到阶梯水价的日切换时间精度直接影响资费计算所以低功耗晶振的钱不能省。4.4 电源监测低电量报警是水表的最后防线电池总有耗尽的一天。我们在ADC上接了一个分压电阻网络每24小时唤醒时读一次电池电压。电压低于设定的阈值后系统在正常上报数据帧里增加一个低电量告警标志位提醒后台安排换表。阈值不能设得太死因为锂亚电池在低温环境电压会下降正常在零下十度时电压可能比常温低0.3V左右直接按常温阈值判断很容易误报。我们做的处理是把电池电压和环境温度同时上报后台结合温度曲线做综合判断。5. 通讯与数据链路NB-IoT上报、校时、OTA的协议设计5.1 传输层UDP还是TCP这是个问题NB-IoT模组本身支持TCP和UDP。TCP可靠但有连接维护的开销对低功耗终端不友好。UDP简单高效但丢包率高。我们最终选的是UDP加应用层确认机制终端发一帧数据服务器收到后回一个确认帧终端在规定时间内收到确认就认为发送成功收不到就退避重发。退避累计三次还没成功数据落本地待传队列等下个周期继续传。这样既避免了TCP的长连接开销又保证了关键数据的可达性。5.2 数据帧格式别把简单事情做复杂帧格式设计成定长紧凑型最大限度减少空中传输字节数。单帧内容包含设备ID、累计流量、瞬时流量、电池电压、设备状态、时间戳、校验值总共四十六个字节按十六进制编码后九十二个Hex字符。协议字段顺序固定服务器端解析简单调试也容易。一个关键经验时间戳不要主设备生成后直接发。水表内部RTC虽然校准过但长时间运行还是会有漂移。我们在帧里带的是本地时间服务器收到后比较自身时间如果偏差超过五分钟回复确认帧时顺带下发标准时间终端收到后自动校准RTC。这比单独做一次校时交互省电得多。5.3 上报策略周期上报加事件上报的组合拳每天固定周期上报一次给服务器这是最基本的。但在两种特殊情况下要立即上报第一种是流量异常。比如系统检测到连续四小时没有用水但累计脉冲仍在增长这通常意味着表后管道破裂或者水箱漏水系统要立即上报异常事件。第二种是磁干扰。有人在表附近放强磁铁试图让转盘停转霍尔传感器的磁感应强度检测就会发现磁场异常这时立即上报防磁告警。防拆开关被非法打开也是同理。事件上报的数据帧与周期上报的帧格式完全一致只是设备状态字段里加了事件标志。后台收到后可以立刻生成工单推给运维人员。这一套逻辑在整个项目联调时效果出奇地好某次测试我们故意放磁铁在水表上方不到三十秒后台就弹出了告警响应链路完全跑通。5.4 离线补传与本地缓存断网也不能丢数据再好的网络也保不齐基站故障或信号盲区。终端在连续三次上报失败后会把数据帧缓存到Flash缓存容量设计为能存九十天的日数据。等网络恢复终端在下一次定时唤醒时先清积压缓存再上报当日数据。这样即便通信中断三个月后台也能找到完整的记录对账时不会出现缺口。6. 系统联调中的三大坑和对应的排查方法6.1 坑一两个霍尔传感器抢中断导致计数错乱第一次联调功能板的时候正转测试计数正常反转测试却出现了诡异的现象计数器不仅减不对还偶尔多计。用示波器同时抓两路信号才看明白两路中断的回调里都调用了同一个计数函数函数内部没有做临界区保护A中断触发到一半被B中断打断两个中断同时修改计数变量数据就乱了。解决方案很直接在计数函数入口关中断操作完再开中断。M3/M0内核上直接用临界区加锁是最粗暴也是最有效的做法。处理完之后再跑一千次反转测试计数全部正确。6.2 坑二NB-IoT模块入网瞬间把系统拉垮这个坑差点把项目打回重做。模组上电入网瞬间发射电流达到峰值电源电压瞬间跌落MCU掉电复位然后模组重启再入网形成一个复位-入网-拉垮-复位的死循环。排查过程花了两天。先怀疑电池供电不足换了大容量电池还是复发。后来用示波器看电源轨发现模组发射时VCC纹波超过四百毫伏MCU复位阈值大约是2.8V电压跌落后直接触发BOR复位。问题出在超级电容容量选小了1F的电容在低温下容量衰减瞬时大电流支撑不住。处理方法是把超级电容加大到4F同时在模组和主控之间加了一个MOS管开关正常待机时模组完全断电只有需要上报时才给模组供电。这一改不仅解决了复位问题还把静态电流又压低了1.5μA。从那以后我养成了一个习惯所有低功耗项目里的通讯模组一律用MOS管做电源开关绝不让模组长期挂电。6.3 坑三校准时间后RTC反而越来越不准系统跑了一个月后发现上报时间戳偏差越来越大从最初的几秒漂到十几秒。打开RTC配置代码检查发现校准逻辑有问题服务器下发的标准时间在RTC事件中断服务函数里直接被写入但写入时没有考虑从读取到写入这一小段时间的累积每次校准都引入了几百毫秒的系统性误差。这个问题的正确做法是当校准事件发生时先读取RTC当前时间计算本次校准引入的偏差把偏差补偿值存入Flash每次时间戳输出时累加这个补偿量。虽然单次校准的误差不大但水表运行的周期是以年计的误差会逐日累积。想清楚这个逻辑之后RTC校时精度从原来的秒级提升到了毫秒级后台对账完全不再需要人工修正。7. 未来扩展方向远程阀控、预付费与管网监测7.1 加一个阀门控制模块就变成远程阀控水表硬件上只需要在出水管路上加装一个电机阀门MCU增加一路电机驱动和阀位反馈检测。后台下发指令终端执行开阀或关阀操作并反馈完成状态。配合预付费余额不足自动关阀、欠费复通开阀就构成了完整的远程阀控逻辑省去人工上门关阀的成本。阀控动作时电机瞬间电流大电源设计上要预留裕量或者采用先断水再低电压动作的慢速阀门方案。7.2 预付费与阶梯水价的实时计算有了每日上报和远程配置能力把费率表预下发到终端终端本地根据累计流量执行阶梯计价余额不足时提前预警甚至自动关阀这就是完整的预付费水表形态。终端本地计价的好处是不依赖网络实时在线哪怕通信中断一个月计费逻辑仍然在跑恢复联网后把账期数据补传上去即可。7.3 管网漏损监测从单表智能到系统智能当大量智能水表接入后台就不再是单台设备的问题了。把每个水表上报的瞬时流量按时段聚合建立小区日用水曲线通过总表和分表的数据比对就能定位漏损区域。再进一步用水曲线和人口流动、季节气温建立关联模型就能做到更精准的供水调度。这块内容已经不是当前STM32单片机范围内的实现问题但作为项目的自然延伸我在后续会专门写一篇基于后端数据平台的文章讲设备接入后如何做数据处理与异常识别。简单提一句是为了说明智能水表项目真正的价值点不只在一块电路板上而是设备和数据链路组成的整个闭环。如果此刻有人问我做这个项目最大的体会是什么我会说嵌入式项目做到的从来不是某一个惊艳的单点功能而是把计量、通讯、功耗、安全这些基础模块一个个做到扎实再把它们之间交叉影响的坑一个个填平。单片机代码本身不难难的是把每个细节都照顾到让整个系统像水表一样默默转上几年不出错。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
