1. 项目源起为什么一个边缘设备要叫“colibri”先说结论这个项目跟鸟没直接关系但跟蜂鸟有间接关系。“colibri”是法语里“蜂鸟”的意思。我之所以拿它当这个项目的名字是因为蜂鸟身上有三个特征恰好是我做这个边缘计算微型设备时最想实现的极小体积、极高频率、极致能效。蜂鸟每秒扇翅能到80次能在空中定点悬停但代谢效率却是鸟类里顶尖的。反过来看我当时手里的需求——做一个体积尽量小、能够高频采集传感器数据、本地做轻量级推理、还得靠电池撑住长时间待机的物联网设备——这不就是电子领域的蜂鸟吗。这个项目的原始需求说起来不复杂。我在做一套室内环境监测系统点位分散在十几个房间每个点位需要监测温度、湿度、光照、CO₂浓度数据采集频率要求不低但又不能给每个点位配一根电源线所以需要设备自带电池、体积小、能贴墙放。最开始接触到的方案有两个方向一是直接用现成的商业传感器节点但协议封闭、数据拿不干净、电池续航也一般二是自己用开发板拼但大多数开箱即用的开发板体积太大功耗控制也谈不上精细。两头都不满意干脆自己从芯片级开始做一个。于是“colibri”这个项目就这么定的方向一块不到名片三分之一大小的板子双核处理器支持Wi-Fi和低功耗蓝牙挂4到6种传感器软件上做一套事件驱动的低功耗调度逻辑平时睡眠、有事件才唤醒采集上报目标是单节18650电池扛到半年以上。这个定位决定了后面所有技术选型的方向。再说清楚一点这不是一个追求性能天花板的项目它是一个在体积、功耗、实用性之间找平衡的项目。这也就意味着很多取舍在项目初期就要想明白比如芯片选哪个级别、传感器走数字接口还是模拟接口、要不要上实时操作系统、上报协议用MQTT还是CoAP。下面我按实际推进的顺序把这些环节逐一拆开讲。2. 硬件底座的决策过程芯片、传感器、供电三者如何互相牵制2.1 主控芯片选型的关键不在于算力而在于“睡得好不好”很多爱好者做这类设备第一步会陷入CPU性能焦虑恨不得上树莓派Zero但我权衡了一圈最后选了乐鑫ESP32-S3。原因不复杂。首先要Wi-Fi而且要做本地轻量级AI推理哪怕只是简单的异常检测所以芯片得带向量指令扩展ESP32-S3在这点上正好合适双核240MHz带SIMD指令单芯片集成Wi-Fi和BLE一堆外设接口其次要有成熟的低功耗模式ESP32的light sleep和deep sleep机制在开源社区里被磨得很成熟可以做到微安级待机再次是开发资源ESP-IDF加Arduino双轨支持遇到问题不太可能卡死。对比一下另外两个候选方案候选方案优势劣势为什么最终没选RP2040树莓派Pico价格低、体积小、生态热闹没有Wi-Fi/蓝牙需要外挂模块外挂无线模块会让体积和功耗双双失控nRF52840蓝牙低功耗无敌、待机功耗极低Wi-Fi需要外挂开发门槛高项目需要Wi-Fi直连上报不想绕一圈走BLE网关ESP32-S3Wi-Fi/BLE集成、有向量指令、低功耗模式完善待机功耗不如nRF系列极致综合平衡下来最合适顺带说一句如果你只做BLE采集器不太需要Wi-Fi直连那nRF52840是更好的选择。但我的场景是点位少、没有现成网关每个设备要直接连路由器上报所以Wi-Fi是刚需。选型时还有一个容易被忽视的细节PCB天线的净空区。ESP32-S3模组板载天线下方的PCB区域需要挖空周围不能铺铜这个在Layout时就要提前规划。否则天线性能下降后续可能要加钱上外部天线座体积就上去了。2.2 传感器组合能走数字总线就别碰模拟口我最初规划的监测项是温湿度、光照、气压、CO₂和空气质量最终确定的传感器清单如下温湿度SHT40I²C接口精度±0.2℃体积极小功耗极低光照OPT3001I²C接口动态范围大带自动量程切换气压BMP390I²C接口也是低功耗的典型选手空气质量SGP40I²C接口VOC指数输出有内置算法CO₂SCD40I²C接口基于光声传感原理精度能到±40ppm5%整套传感器全部走I²C总线好处很明显布线简单、代码通用、传感器之间可以共用总线且地址不冲突。为什么这么执着于I²C因为之前我做过一版带模拟输出的传感器比如老款的模拟湿度传感器遇到两个麻烦——一是ESP32-S3的ADC线性度一般需要自己做校准曲线不然数据漂得你怀疑人生二是模拟信号线在PCB上走长了容易受到板内电源纹波干扰查起来非常费劲。数字总线把校准和噪声这部分工作转移给了传感器内部代价是贵一点但对于做产品原型来说省下的调试时间非常可观。2.3 供电链路一块18650打底的学问电池部分我选了18650单节加TP4056充电模块的方案。这听起来一点不新鲜但电网设计上有几个细节值得单独说。第一DC-DC的输出纹波会直接影响传感器数据质量。我一开始用的是普通的AMS1117线性稳压器功耗低但发热可控但它的压差要求输入至少比输出高1V18650截止电压是2.8V到3.0V降到3.3V就力不从心了。后来换成了XC6220低压差LDO压差只有160mV这样电池快耗尽时还能稳定输出3.3V。如果用DC-DC比如TPS62740效率会更高但纹波比较大注意传感器电源脚需加LC滤波。实测下来SGP40的VOC读数对电源噪声比较敏感纹波大了数据会周期性跳变。第二必须给传感器单独做电源开关。采集频率高不高先不说传感器挂在总线上一直供电待机电流直接从微安级涨到毫安级。我加了一个P-MOSFET做负载开关平时把所有传感器电源切断只有采集前100ms才给传感器上电上电后等传感器稳定再读数据。这一条对低功耗贡献显著。第三ADC采集电池电压要分压电阻。这看起来是基本功但我见过很多项目把分压电阻阻值选得过大导致ADC源阻抗太高、采样值严重失真。我选了100k100k的分压然后采集时开启ESP32-S3 ADC的衰减模式和多次采样取中位数的滤波电池电量曲线读出来平滑且基本无跳变。3. 软件架构FreeRTOS任务划分与事件驱动状态机3.1 任务划分的核心原则能睡就睡别轮询软件层面我基于ESP-IDF开发套了一层FreeRTOS。这个操作看起来是常规选择但任务怎么划分直接决定了整个系统的功耗基线。我一开始的设计是“采集任务每10秒醒一次读一轮传感器然后上报”但实测下来功耗感人。10秒一次的采集频率意味着Wi-Fi也基本保持长连接电流维持在50mA以上电池根本撑不住。后来我把思路从“定时采集”改成“事件驱动采集”这是这个项目低功耗策略的分水岭。最终的任务划分如下环境事件任务监听传感器中断引脚比如光照突增、温湿度越限由硬件中断唤醒系统定时兜底任务无论如何每5分钟强制采集一次并上报防止事件漏报上报任务负责Wi-Fi连接和数据推送封装成队列其他任务把数据丢进队列就回去睡诊断任务权限很低定期读电池电压、信号强度、Wi-Fi重连次数用于远程排查设备状态这套设计里最关键的一点是没有一个任务在轮询。每个任务要么被事件唤醒、要么在队列里等数据没有数据的时候系统进入esp_pm锁控制的状态CPU降频到最低甚至进入light sleep。3.2 状态机比想象中更重要采集、上报、睡眠三个状态要能平滑切换低功耗设计的难点不是“知道要睡眠”而是“怎么安全地进入睡眠、怎么干净地醒过来”。我在代码里实现了三个主要状态STATE_SENSE上电给传感器供电延时等传感器稳定后读数据每类传感器都有自己的power-on稳定时间比如SGP40需要30秒预热这是个大坑后面细说SHT40只需要10msSTATE_REPORT打开Wi-Fi连路由器MQTT推数据推完立刻断开连接STATE_SLEEP关传感器电源、关Wi-Fi、配置唤醒源定时器RTC GPIO进入light sleep状态机切换的触发条件要明确。比如温湿度越限是事件触发立即从睡眠唤醒来一轮采集上报但VOC读数只有在设备空闲时才触发因为SGP40上电后需要长时间稳定频繁启停反而数据不准。切换延迟方面light sleep唤醒系统本身要花费几十毫秒这是固定开销需要接受。Wi-Fi断开到重连的功耗曲线是梯形的不是直线的所以在低功耗状态下不要保持长连接而是采用“采集完、立刻连、立刻推、立刻断”的策略这样实际算下来比长连接能省40%以上的电量。3.3 MQTT不是唯一选择但确实是最省事的数据上报协议我最终用了MQTT over TCP。选它的理由不是性能最优而是生态和调试便利。Broker用的Mosquitto客户端用ESP-MQTT库基本是ESP-IDF的标配。不过用MQTT时有个容易被忽略的地方KeepAlive时长和会话清理策略。因为我是“断开再连接”的策略MQTT客户端每次都要重新建立TCP连接和MQTT会话所以必须把Clean Session设为1让broker不要保留离线消息否则下次上线会收到一堆积压消息白白耗电。QoS设到0就行环境数据丢了下一轮补上不需要可靠传输。另外上报的数据结构我定义成JSON虽然解析开销和体积都比二进制大但胜在后续接任何物联网平台都不用改设备端代码。如果哪天想接Home Assistant只要往MQTT topic里推相同的JSON就行不用动嵌入式这边。4. 真机调试踩坑实录三个问题每个都花掉了我半个周末4.1 第一坑Wi-Fi开启时ADC读数周期性跳变现象是这样的设备裸跑传感器采集时数据很平滑但只要一打开Wi-Fi电池电压的ADC读数就会在几个固定数值之间反复横跳幅度最大到0.15V。我一开始怀疑是电源被Wi-Fi发射瞬间的大电流拉垮了于是用示波器测3.3V rail发现纹波确实明显但幅度只有几十毫伏不至于导致0.15V的读数跳变。后来仔细查了ESP32-S3的TRM和乐鑫的勘误记录发现这属于ADC采样值与射频开关切换的耦合问题Wi-Fi发射时射频前端工作会引入共模噪声而ADC的采样保持电容对这种噪声比较敏感。更麻烦的是S3的ADC在某些增益配置下还存在死区和非线性低电压段表现尤其不稳定。最终的解决方案分三层改用多次采样取中位数同时开启ADC的硬件滤波选项调整采样时机避开Wi-Fi发射窗口具体做法是Wi-Fi连接建立之前采一次电池电压上报完成之后再采一次两次数据做加权平均把分压电阻的输出端加一个1uF电容砍掉部分射频干扰处理完之后连续72小时的电压监测读数波动稳定在±0.01V以内。4.2 第二坑light sleep唤醒后Wi-Fi反复重连最多的一次连了7次才连上这是个非常隐蔽的问题坑了我很久。现象是设备从light sleep唤醒后Wi-Fi连接经常不稳定表现为连接、断开、重连、再断开循环几次后最终成功最坏情况白白多了十几秒的高功耗状态。排查链路是这样的先怀疑是路由器设备数量限制排除了其他设备都正常再怀疑是Wi-Fi信道被干扰换信道也不行仔细翻了ESP-IDF的Wi-Fi低功耗实现发现问题出在beacon监听和modem sleep的配置配合上。设备在light sleep期间Wi-Fi模块也进入modem sleep只周期性监听beacon。唤醒后重新连接时如果modem sleep配置不一致驱动会认为AP同步丢失触发多次重连解决办法是在配置阶段把Wi-Fi的power_save_mode设为WIFI_PS_MIN_MODEM并且在唤醒后的连接流程里增加主动信道扫描esp_wifi_set_channel让驱动重新快速同步。改完这个问题后唤醒后的首次重连时间从10到15秒降到了2秒以内。4.3 第三坑SGP40的“假预热”问题——刚上电的读数根本不能信SGP40这颗VOC传感器数据手册上写的是“power-on ready time 10s”但实际上它的内部算法需要更长的稳定时间尤其是它内部的加热元件需要把敏感层加热到工作温度这个加热过程受环境温度影响很大。我出现的问题是设备从睡眠中唤醒采集时SGP40刚上电就读数结果VOC指数在第一分钟从几千一路跌到几百看起来就像是空气质量突然崩溃然后快速恢复其实是传感器还没热透基线根本没建立。这个问题不能靠延时几分钟解决因为事件驱动的采集场景不允许每次采集都等这么久。我的处理方案是SGP40不上电睡眠而是保持持续供电因为它的工作电流只有约2.6mA相比温度传感器高一些但还在可控范围。设备进入light sleep前把SGP40留在低功耗测量模式每秒钟测一次但不开数据上报唤醒时直接读最近一次稳定值。这样牺牲了一点待机功耗但数据质量大幅提升。这个案例给一个经验数字传感器也不是开箱即用的每个传感器都有自己独特的预热、稳定、基线逻辑设计采集策略前务必要把时序图和数据手册里的应用笔记读透。5. 实测数据续航、精度、稳定性到底怎么样5.1 功耗实测——低功耗策略是否达标的检验下面是colibri在几种典型工作模式下的实测电流工作状态实测电流说明deep sleep所有传感器断电RTC定时唤醒38uA这是电池电压监测和RTC计时状态light sleepSGP40保持低功耗测量110uA这是大多数空闲时间的状态事件采集上报Wi-Fi关断前45mA持续1.5sSHT40/OPT3001读数MQTT推送后立即断开Wi-Fi连接上报周期平均85mA持续2-3s包含连接路由器、MQTT握手、数据推送电量计算5分钟一报平均约0.48mA折算下来一颗3000mAh的18650理论上可续航260天左右实测中一颗标称3000mAh的18650在5分钟一报的频率下跑了大概7个月跟理论值相当接近。如果改成10分钟一报理论续航能到400天以上。5.2 数据质量与系统稳定性采集精度方面SHT40的温湿度读数和旁边放的一台商业级传感器对比连续48小时的温差在±0.3℃以内湿度在±2%RH以内。CO₂读数与一台NDIR原理的校准仪表对比偏差在±30ppm左右符合预期。系统稳定性方面最长连续运行记录是43天没重启期间远程通过MQTT监控数据没有断档。Wi-Fi重连成功率从前面优化的99.6%还是有极少数卡死提升到了99.95%以上只有一次设备在路由器重启后没有自动重连最后靠看门狗兜底复位恢复。6. 还能怎么玩colibri的下一步演进思路这套硬件和软件架构已经跑通了但它还留了几个我接下来想动刀的方向顺便给打算照着做的人指个路。第一加LoRa扩展。Wi-Fi覆盖不了的地方比如地下室、户外菜园Colibri可以通过SPI接口外挂SX1262 LoRa模块把数据传到几公里外的LoRa网关再转MQTT。这样做之后设备脱离了路由器依赖应用场景一下子从室内环境监测扩展到农业、户外气象站这些方向。注意SX1262的射频部分对PCB布局要求不低热风枪焊接时要控制好焊接温度建议直接用现成的模组。第二本地异常检测的轻量模型。ESP32-S3的向量指令不是摆设我已经在测试把一个小型AutoEncoder模型部署到设备上输入是多个传感器的时序窗口输出是重构误差当误差超过阈值时就认为出现异常。这样设备不需要把每一帧原始数据都传回服务器减少了上报频率又进一步降功耗。模型大小可以控制在200KB以内推理时间在50ms左右。第三设备固件的OTA升级。我在第二版固件里加入了基于MQTT的OTA通道通过发布一条特定的topic触发设备下载固件并升级。这里有个坑是ESP32在OTA期间不能断电所以代码里要挂ESP32的硬件看门狗并在关键步骤喂狗否则下载过程中发生阻塞会导致超时重启固件写一半变砖。就着这些方向往后走colibri从一块“能用的开发板”变成“能长期部署的传感节点”基本没有障碍。我做这个项目最大的体会是这类设备的成功不是看单项指标多强而是看整合度多高——芯片、传感器、电源、通信、软件策略任何一个环节掉链子整个系统的体验就会崩。宁可每个环节只做到80分也不要某个环节做到120分而其他环节不及格。