去年冬天实验室那台精密分析仪突然离线我赶过去才发现是给它的那路电源模块输出掉了却没有任何人收到过通知。更狼狈的是那次异常直到一周后翻记录时才被察觉白白损失了好几组实验数据。那次之后我下定决心不再依赖单一的成品电源而是自己动手搭了一套完整的 Power Supply Monitoring and Control System。现在这套系统已经在工位上稳定跑了半年多市电输入、各路输出电压电流、功率、温度、开关状态全部实时可见异常时能自动断电保护也能发告警到手机。这篇文章就把这大半年里从0到1的完整过程写出来包括硬件选型、采样电路设计、固件逻辑、校准方法以及实际部署中踩过的坑。如果你是电子工程师、嵌入式开发爱好者或者只是搞了几个外设想知道它们到底吃多少电这篇文章都值得花十分钟看完。1. 为什么放着现成的PDU/电源监控模块不用非要自己造一套市面上并非没有电源监控方案。网络机柜里常见的智能PDU可以测电流高端电源自带I2C/PMBus接口能回读电压电流还有一些带屏幕的数控电源模块也能做基本的监控。但真的用起来你会发现它们各自有各自的别扭。1.1 成品方案的三类痛点第一类是信息封闭。很多智能PDU回传的数据只有电流和总功率根本没有单路的电压数据和开关状态。你只知道这一路“还在跑”但不知道它是在12.1V还是10.8V这种危险边界上跑。对敏感负载来说电压偏离往往比过流更致命。第二类是可控性差。PDU能做的控制通常只是“远程开/关这一路”但做不到按阈值自动保护更别说把保护逻辑做成一套可配置的策略。第三类是协议绑定。设备本身的网管协议和云平台绑定得死死的想接入自己的监控面板、数据库需要逆向或者等官方API麻烦又被动。自己做一套的成本其实很低一块ESP32或STM32一个INA226电流/电压采集芯片一个固态继电器或MOSFET开关加上24V转5V的电源模块几十块钱就能把硬件打样出来。真正的工作量在固件逻辑和后期校准上但这部分恰恰是最能沉淀成经验的地方也是我最有收获的部分。1.2 确认自己的真实需求清单动工之前我花了一个晚上把需求写到纸上避免做成一个“什么都有但哪都不好用”的东西。我的需求清单大概是这样的监测范围6路独立负载输入每路支持0-30V/0-10A精度要求电压±0.05V、电流±0.05A采集刷新率1秒1次告警判定需要100ms内响应控制能力支持远程开/关每一路支持过压、欠压、过流、过温自动保护通信方式现场有局域网直接用WiFiMQTT方便和自建的Web面板集成可靠性一旦MCU死机或通信失效所有输出必须保持原状态不能直接断开造成负载丢失。如果你不需要多路只是想盯着某一台设备那可以砍到只有1路成本和复杂度都会低很多。这篇文章下面还是以6路为例讲因为单路系统的所有问题在这个方案里都会被放大能讲得更清楚。2. 系统架构选型传感器、主控、执行器怎么各司其职整个系统拆开看就是一条链路采样感知、主控决策、执行动作、通信上报、面板展示。链路不复杂但每一环的选型都会直接影响最终的效果。2.1 采样方案为什么我选了INA226而不是霍尔传感器电压电流采集有几种常见路线我在选型时认真对比过。用电阻分压加ADC比如STM32内置ADC最便宜但问题是采样精度受ADC参考电压漂移和PCB噪声影响很大要获得0.05V级别精度你得上低温漂基准源加差分放大复杂度反而上去了。霍尔电流传感器ACS712等适合大电流和隔离场景但小电流下线性度差10A量程测0.1A时误差能到百分之十几不适合需要精细读数的场景。最终我选的是TI的INA226一块既能测电压又能测电流的双向监控芯片。它的核心原理是让负载电流流过外部采样电阻通过内部差分放大器测量电阻两端压差来计算电流同时另一路ADC直接测量总线电压。芯片内置16位ADC精度很高而且通过I2C接口最多可以挂16个地址很适合做6路甚至更多路的扩展。INA226的另一个好处是自带电流/功率告警比较器和可配置的转换时间告警响应不用主控轮询。实际做下来这个芯片没有让我失望配合低温漂采样电阻全量程精度轻松达到需求。如果预算再紧张点也可以用INA219但注意INA219只有12位ADC电流分辨率略低长期稳定性也不如INA226。2.2 主控选型与通信协议ESP32的取舍主控我直接用了ESP32-WROOM-32E。选择它有几个非常现实的原因第一自带WiFi和蓝牙通信不需要再加模块第二I2C硬件接口够稳能够承载6路INA226的轮询第三社区资料多写代码遇到问题几乎都能搜到答案。不过ESP32也有一个明显的短板长期工业级可靠性不如STM32特别是WiFi协议栈出问题时容易死机。我在系统里加了一个硬件看门狗一旦主控失联输出状态保持原值并且通过LED和蜂鸣器本地告警。关于看门狗的具体做法后面有专门的章节讲。通信协议我在Modbus RTU和MQTT之间选了MQTT。原因很简单我的上位机是Web面板而MQTT走局域网非常方便配合Eclipse Mosquitto做Broker几十毫秒就能完成一次状态推送。Modbus RTU如果走RS485需要额外芯片且和Web面板对接要自己写TCP网关明显更折腾。如果未来要接入PLC等工业系统再挂一个Modbus RTU从机也不难但现阶段MQTT足够好用了。系统整体架构可以概括成一句话INA226负责感知ESP32负责决策MOSFET负责执行MQTT负责传递Web面板负责呈现。2.3 控制执行器MOSFET和继电器各用对场合每一路的通断控制我对比了继电器和MOSFET两种方案。继电器有明显的机械触点声抗过载能力好导通电阻几乎为零但问题是寿命有限开关次数最多几十万次而且线圈需要驱动电路响应速度是毫秒级。MOSFET没有机械结构响应微秒级寿命几乎无限但需要注意散热和导通关断时的浪涌。我最终选择的是P沟道MOSFET做高边开关型号是AO3401A负载电流最大4A对这个场景足够了。如果是更大电流10A以上可能要考虑N沟道MOSFET配电荷泵驱动或者直接上固态继电器。这里有个很关键的细节MOSFET关断时如果负载是感性或容性负载会产生反电动势或浪涌电流。后者在上电瞬间特别明显因为电容充电瞬间相当于短路。我处理的办法是在每一路输出并联一个预充电电阻回路上电时先通过电阻给电容充电200ms之后再旁路掉这样能避免大部分MOSFET被浪涌击穿的情况。3. 硬件核心设计采样电阻、电源树和PCB布局的细节很多初做电源监控的人容易忽略硬件细节认为“芯片选好了接线就完事”。实际上采样精度和长期稳定性很大程度都取决于这里的硬件功夫。3.1 采样电阻的选用散热和温度系数需要同时关心INA226再准如果采样电阻不准一切白搭。我用的是2mΩ的合金电阻封装2512额定功率1W温漂系数50ppm/°C以内。这组参数怎么定的举个例子当电流为10A时采样电阻上的压降为20mV功率为0.2W虽然距离额定1W还有余量但考虑到PCB上紧挨着其他发热元件温度可能上升20°C2mΩ带来的阻值偏差约为2mΩ × 50ppm × 20 2μΩ反映到电流读数上大约是1mA完全可接受。但如果用了廉价碳膜电阻温漂可能到几百ppm那就成了误差的主要来源。采样电阻的layout也非常重要它必须使用四线开尔文连接两线给电流通路两线给INA226的差分采样。如果直接拿一根长走线串联采样铜线本身的电阻变化会混进读数误差会非常随机。我第一版PCB就没做开尔文连接结果同一路电流在冷机热机时能偏出0.3A后来改版后才稳定下来。3.2 电源树设计独立模拟供电是精度保障6路INA226的数字部分由ESP32的3.3V供电模拟参考电压部分我单独用了一个低噪声LDOAMS1117-3.3供电和主控的数字电源做了磁珠隔离。原因很简单ESP32的WiFi发射瞬间电流可达几百毫安会拉低数字电源电压即使在I2C通信里不产生协议错误但INA226的参考电压如果和数字电源共享采样值会出现几十毫伏的跳动。隔离之后实测WiFi广播时电压读数纹波从±0.12V降到了±0.01V以内效果非常显著。主电源树的结构是外部24V输入 - DC-DC降压到5V给MOSFET驱动和蜂鸣器- LDO降到3.3V给ESP32和INA226模拟部分。每一级的电容选型也很关键DC-DC输出端要低ESR的固态电容而LDO输入输出端分别加上10μF和22μF陶瓷电容避免高频振荡。3.3 PCB布局的几条硬性经验因为这是一个小规模系统我没有用四层板两层板就能搞定。但两点经验必须提醒第一INA226的采样电阻要靠近输入端远端负载线缆尽量短减少长线电阻的干扰第二MOSFET的漏源极走线要走宽至少2mm不然大电流下铜箔会发热甚至烧断。另外所有地平面最后用单点汇聚到电源输入端避免模拟地和数字地在多个点混合连接形成地环路。这一点在开始布线时就要规划好如果第一版图没考虑后面调试时容易遇见莫名其妙的数据跳动而改成单点接地后我的系统所有通道的底噪都降到了1mV以下。4. 固件逻辑状态机、滤波算法和EEPROM存储固件是这套系统里工作量最大、也最能折腾人的部分。它的核心不只是“读芯片、发数据”更重要的是如何让数据稳定、保护逻辑可靠、故障时行为可预测。4.1 I2C轮询与数据滤波不能直接拿原始值用ESP32作为I2C主机需要以1秒周期轮询6个INA226地址。每轮读取需要约10ms所以CPU占用很低。但INA226的原始读数是有噪声的特别是电流在小电流段时噪声比例会比较高。我第一版直接显示原始值结果待机电流0.3A时读数在0.1A到0.5A之间跳非常难看。后来加了滑动窗口滤波每路维护一个长度为10的环形缓冲区每秒钟更新一个值计算平均值作为显示值。同时保留原始的瞬时值用于告警判定。这个设计是有意的显示值要平稳告警值要灵敏。如果告警也用滤波后的平均值那响应时间会被拉到最长10秒当发生短路或过流时这10秒可能就够设备烧坏了。INA226还有个配置项是ADC转换时间和采样平均数。我把电压和电流的ADC转换时间都设为588μs采样平均数为8次。这样每次测量大约4.7ms对1秒轮询完全够用同时能显著压低噪声。如果对实时性要求更高可以减少平均次数但噪声相应会变大。4.2 保护逻辑状态机从正常到故障再到恢复保护逻辑我用状态机实现状态包括NORMAL、WARNING和FAULT。NORMAL状态下每路实时检查电压、电流、功率和温度四个维度一旦某个指标超过阈值就进入WARNING此时不会立即断电而是先触发告警并等待一个可配置的延时默认2秒如果2秒后还在异常区间才进入FAULT状态并关断对应通道。这个“先告警再动作”的设计很重要。有些负载启动瞬间电流会短时超过额定值例如电机或者有大电解电容的DC-DC模块如果刚观察到过流就立刻切断会导致系统频繁误动作。我在实际测试中发现某种工业触摸屏上电瞬间电流会跳到额定值的3倍持续约150ms如果设了瞬时保护它永远开不了机。所以阈值和延时需要针对每路负载个性化配置。FAULT状态一旦进入这一路必须通过手动远程复位或者本地按键才能重新上电不允许软件自动恢复。这个选择是吸取了群里一位朋友的经验他的系统在晚上因为某路负载瞬间过流被保护但第二天负载恢复正常如果自动恢复会导致冲击更大结果过热烧坏了电源。自动恢复看似方便在保护场景里却可能放大故障。以下是保护逻辑的简化伪代码enum State { NORMAL, WARNING, FAULT }; void loop() { for (int i 0; i CHANNEL_COUNT; i) { sample readINA226(i); switch (state[i]) { case NORMAL: if (isOverThreshold(sample)) { state[i] WARNING; warningTimer[i] millis(); sendAlarm(i, warning); } break; case WARNING: if (!isOverThreshold(sample)) { state[i] NORMAL; break; } if (millis() - warningTimer[i] WARNING_DELAY_MS) { channelOff(i); state[i] FAULT; sendAlarm(i, fault); } break; case FAULT: // 等待远程或本地复位 break; } } }4.3 看门狗与断线策略死机时不能丢输出前面提到ESP32可能在WiFi协议栈异常时死机因此我在固件里加了两种看门狗内部任务看门狗和外部硬件看门狗。内部看门狗依靠FreeRTOS的任务通知来实现如果主任务超过3秒没喂狗就强制重启外部硬件看门狗用一个独立的555定时器电路实现主控正常时定期输出一个高电平脉冲如果超过5秒没有脉冲输出控制锁存器就会保持最后的电平状态。这里必须强调当主控死机时所有通道必须保持通电前的状态不能直接关闭。我一开始用的是在死机时把输出全断掉的逻辑想着“安全第一”。但后来发现这对无人值守的负载来说反而是灾难如果某路正在跑一个需要连续运行24小时的电机设备监控系统死机一次就把它停了这个损失比监控系统本身的价值还大。正确的做法是让输出状态完全由锁存器保存主控只是负责“改变”它而不是通过持续控制来“维持”它。同时通信断开也要有策略。我配置了MQTT的Last Will和遗嘱消息当ESP32和Broker断开连接时Broker会自动发布一条离线消息上位机收到后立即在面板上显示告警。这样即使设备本身没有感知到任何电气异常运维人员至少知道“监控系统失联了”而不是傻等。4.4 关键参数存储EEPROM里存什么校准后的电压/电流偏置、各路负载的路由名称比如“LED灯带”“工控主机”、过压欠压过流阈值、告警延时统统存在NVS非易失存储里。NVS的好处是掉电不丢、支持键值对读写不用自己设计存储格式。一个重要的细节是修改阈值时不能直接写入要写入后重启并回读验证。我之前遇到过在运行中频繁写NVS导致存储区损坏的情况后来在每次写操作前增加写入校验和并在重启后打印参数对比确保没有问题再继续运行。如果你只是玩玩不搞这些也能跑但如果是长期运行的系统这点成本绝不能省。5. 上位机和远程监控数据要变成能看懂的告警才有价值硬件和固件都通了之后真正让这套系统“好用”的是上位机和告警链路。我不建议一上来就搞复杂的App一个Web面板加一个告警机器人就能覆盖90%的需求。5.1 MQTT主题设计和JSON消息格式MQTT主题我按“层级清晰、便于通配订阅”的规则设计powermonitor/{device_id}/status # 周期上报1秒一次 powermonitor/{device_id}/alarm # 告警消息 powermonitor/{device_id}/command # 下发控制指令周期上报的消息体用JSON内容格式如下{ ts: 1710000000, channels: { 0: {voltage: 12.03, current: 0.45, power: 5.41, state: on}, 1: {voltage: 5.02, current: 1.10, power: 5.52, state: on} } }注意这里我把功率值也直接算好发出来而不是让上位机拿电压乘电流。原因是电压和电流本身有采样时间差直接相乘会引入一定的瞬时误差在INA226固件侧直接用芯片内部的功率寄存器读取精度更高也减少上位机计算负担。命令消息设计成如下格式并带上一个递增的序列号以处理重发{ cmd: set_channel, channel: 0, state: off, token: 1001 }上位机收到后解析执行并返回一条ACK如果主控没有收到ACK会重试3次。这套机制虽然简单但避免了“命令丢了导致负载没关掉”的隐患。5.2 Web面板不非得用重型框架Web面板我直接用Node-REDInfluxDBGrafana的组合。Node-RED订阅MQTT把数据写入InfluxDB时序数据库Grafana负责展示和告警配置。很多人一提物联网监控就想到用复杂的云端平台但局域网里这套组合完全够用而且都是开源免费的。Grafana里我建了两类dashboard总览页展示所有6路的状态卡片每一路显示实时电压、电流、功率和运行时长颜色编码标记正常/预警/故障详情页展示某一路的历史曲线这样能看出一台设备的用电规律比如夜间待机电流是否异常升高某个时间段是不是峰值功率突刺。另外一个很有用的功能是历史回放。我在InfluxDB里保存了30天数据出现故障后可以直接拖动时间轴回溯故障发生前后几秒的电压电流曲线比只看瞬时值更容易定位根因。这个能力让我在排查一次“某路电压跌落”问题时直接锁定了是外部DC-DC模块老化导致的纹波超标而不是监控系统本身的问题。5.3 告警通知接telegram/钉钉/邮件都行告警我不推荐只依赖面板上的红黄绿颜色因为人不可能一直盯着屏幕。我自己接入了钉钉机器人Webhook当MQTT收到alarm主题消息时Node-RED通过HTTP POST把告警内容推送到钉钉群标题带上设备名和通道号。如果你用其他的IM逻辑一样都是HTTP回调照葫芦画瓢就行。告警内容要比“某路电压异常”这种空话强得多。我的告警模板包括通道编号、负载名称、触发的指标、实测值、阈值、时间戳。比如【电源监控告警】 设备bench-psu-01 通道2工控主机 指标电压过低 实测10.82 V 阈值11.00 V 时间2025-06-01 14:22:33这样运维人员不用登录面板就能判断问题的严重程度是立刻去机柜处理还是先观察几分钟。6. 校准与精度验证不校准的电源监控系统都是“仅供参考”我以为焊好板子、烧好固件就能用了结果一测就傻眼INA226读到的电压比万用表低了0.25V电流在小负载档差了0.08A。这个教训让我明白任何ADC系统都必须校准尤其是电流采样还要考虑线性度而不是一个零漂偏置。6.1 校准步骤硬件基准和线性点电压校准不需要高级设备一个3位半的万用表就够用。分别在空载和带载时用万用表测输出端实际电压同时记录INA226的读数计算偏差值把这个偏差作为每路电压的固定偏置保存。电流校准稍微麻烦点需要可调电子负载来设定不同电流点。至少选0A、1A、2A、5A、10A五个点记录实测值和芯片读数的对应关系用最小二乘法拟合出一个一次函数 y a*x b然后把这个线性校正系数存入NVS。不要只做单点校准因为不同电流段的误差不是固定平移很多时候是斜率偏差。我记得第一路通道在校准前10A档偏差是-0.23A校准后全量程误差控制在±0.02A以内对监控来说已经绰绰有余。6.2 校准后的精度验证跑一组对比数据我整理了一组校准后10A量程的数据对比以电流为例电子负载设定万用表实测INA226读数误差0.00A0.000A0.001A1mA1.00A1.008A1.004A-4mA2.50A2.512A2.509A-3mA5.00A5.021A5.018A-3mA8.00A8.034A8.031A-3mA10.00A10.050A10.046A-4mA这个结果验证了一个重要规律误差在大电流段基本恒定说明前期温漂和layout措施是有效的剩下的误差主要来自采样电阻本身的绝对精度和万用表引入的系统偏差。6.3 长期稳定性与温漂实测我还特意做过一次烤机测试系统带2A假负载连续运行12小时每隔30分钟记录一次读数。结果电压读数漂移只有±0.02V电流读数漂移±0.03A大部分变化其实来自负载本身发热导致的电流变化而不是采样链路引入的。这算是比较理想的结果主要归功于采样电阻和LDO独立供电的设计。如果你发现读数随时间明显缓慢漂移优先怀疑采样电阻温漂和电源基准不稳定不要急着怀疑芯片。7. 部署半年后复盘最值得记住的几个坑与经验最后这部分不是教程里能学到的是我这套系统从第一版到现在迭代了4版后踩出来的经验。如果你准备自己也做一套这些坑能帮你少走很多弯路。7.1 坑一MOSFET关断瞬间的电压尖峰把主控吓了一跳第一次测试关断带感性的小风扇负载时示波器捕捉到输出端出现了负向30V的尖峰持续时间约200ns。这个尖峰虽然不会直接损坏MOSFET但通过寄生电容耦合到I2C线上导致ESP32的I2C总线上出现了连续的总线错误。解决办法是在每一路输出端并联一个TVS管SMBJ24A同时把MOSFET的栅极驱动电阻从10Ω提高到47Ω减缓开关速度。这不是玄学开关速度慢一点尖峰能量就被冲散了很多。7.2 坑二远程复位逻辑变成了误操作源头我给上位机加了“一键复位所有故障通道”的按钮看起来很方便但有一次本来只有通道3保护跳闸我误点成了全部复位结果所有通道重新上电正在测试的设备全部重启。后来我把复位逻辑改成“必须逐通道点击复位”并在面板上增加二次确认弹窗才算终结这个隐患。监控系统里的权限和确认机制看着是小事关键时刻能决定一次运维事故是否发生。7.3 坑三WiFi信号不稳定导致状态上报间隔忽长忽短ESP32放在金属机柜里WiFi信号差的时候MQTT消息可能积压几秒才发出去。这在面板上看起来就是曲线断断续续。我的处理方式是把上报逻辑改成“在WiFi连通时才发布不重连不阻塞主逻辑”同时把MQTT的KeepAlive调成30秒避免频繁掉线重连。更重要的是在机柜外接了一个带3米延长线的WiFi天线信号强度从-70dBm提升到-45dBm问题基本消失。7.4 坑四过度设计让人疲惫刚做完时我一度想加入LCD显示屏、按键菜单、多级权限管理还想过对每路做独立PID稳压输出。后来冷静下来砍掉了这些需求因为这套系统的定位是“监控和开关控制”而不是“高精度可调电源”。如果你需要可调输出去用成品数控电源模块就好硬把两者揉在一起只会让电路和固件的复杂度指数上升维护成本远大于收益。产品化和自动化之间有一个度我的体会是先跑起来再根据实际使用场景去迭代。像现在这样每个月看看Grafana面板上的趋势偶尔看一眼告警推送它已经成为了实验室里一个沉默但可靠的助手。整套系统成本不到200元但我学到的东西和获得的踏实感远超这个数字。