STM32F103智能井盖：低功耗数据采集与上报实践-平芜编程栈

先说结论：智能井盖这类题目，看着像智慧城市的大概念，落到单片机开发上就是一个非常典型的低功耗采集终端。核心工作不是写多复杂的算法，而是把倾角、水位、气体浓度、井盖位移这类物理状态变成稳定可上报的数据。用普中STM32F103开发板来做原型验证，硬件门槛很低，但真正决定项目质量的往往是电源设计、低功耗处理、通信协议容错和后期的掉电保存策略，这正是这个题目最有练手价值的地方。

这次我们围绕“普中STM32F103智能井盖”这个综合实践项目，把系统拆开看：需要什么硬件、环境怎么准备、数据怎么采集、上报格式怎么定、低功耗怎么做、掉电怎么保数据、最后怎么从开发板原型过渡到可用方案。代码层面我会给的是通用模板和逻辑骨架，具体库函数版本、引脚接线会因开发板和传感器型号不同而需要你自己微调，思路和排查顺序是通用的。

1. 项目定位与核心能力速览

智能井盖本质上是一个分布式物联网节点，放在井盖下面的设备需要做几件事：感知井盖有没有被打开、有没有位移倾斜、井内有没有积水、有没有可燃或有毒气体，再把这些状态通过无线网络传给平台，必要时本地声光报警。

用STM32F103做主控是完全够用的。F103是Cortex-M3内核，主频最高72MHz，Flash和RAM虽然不算大，但处理传感器采集、状态判断、AT指令解析、定时上报这类任务很从容。整个系统通常也不会跑复杂的算法，不需要高算力芯片。

能力项	说明
主控平台	普中STM32F103学习板或STM32F103C8T6最小系统板
核心功能	井盖位移/倾斜检测、井内水位检测、气体浓度检测、本地报警、状态上报
通信方式	优先考虑NB-IoT、4G模块，也可用LoRa或ESP8266做局域网原型验证
低功耗设计	停机模式/待机模式、RTC定时唤醒、外部中断唤醒
数据保存	备份寄存器、Flash或外部EEPROM保存掉电前的状态
开发方式	STM32CubeMX初始化 + Keil MDK或STM32CubeIDE编写逻辑
适合场景	课程设计、毕业设计、嵌入式综合实践、智慧城市原型验证

这个项目的关键点不是学某个具体外设，而是学会怎么把一个“真实产品需求”映射到MCU资源上：哪些信号给中断、哪些信号给ADC、哪些信号要进低功耗、数据包的格式怎么组织。

2. 智能井盖系统架构与使用边界

先画清楚一个比较常规的智能井盖系统分几层。

应用层：云端平台或本地监控中心，接收井盖状态 网络层：NB-IoT / 4G / LoRa / WiFi，完成数据回传 感知层：主控 MCU + 传感器 + 电源系统 + 执行器

感知层设计通常分成四个模块：

状态感知模块：检测井盖打开、倾斜、位移。最常见的是倾角传感器，也可以用加速度计计算姿态角，另外加一个常闭行程开关或干簧管检测井盖抬起。
环境感知模块：检测井内水位、可燃气体、硫化氢等。水位可以用电极式液位开关或模拟量水位传感器，气体传感器通常输出模拟电压，需要接ADC采集。
通信报警模块：无线模块负责上报，声光报警器负责本地提醒。很多人会把WS2812B灯带当作井盖异常指示灯挂在这里，用PWM加DMA控制，也有人在入口侧加红外传感器做闯入监测。这些都可以归到执行和报警链路。
电源管理模块：电池供电时，低功耗设计是核心。如果直接用普中开发板做完整低功耗验证会有限制，因为开发板上有电源指示灯、USB转串口、稳压电路等，整板待机电流很难降下来。更合理的流程是先用开发板把传感器逻辑跑通，再做一块基于STM32F103最小系统的低功耗样板。

使用边界要提前说清楚。智能井盖一旦落到真实城市环境，涉及井下安装和有毒性气体风险，只能在具备工程资质、做好安全防护的前提下由专业人员操作。开发板验证阶段不要直接在交通道路上的真实井盖下随意测试。涉及采集井盖位置、状态、环境数据的系统，使用前要遵守城市公共设施管理规范和数据安全要求，远程控制、报警联动都应该有授权边界。

另外，这个题目不是“把Web界面做得好看”的项目，重点在端侧数据质量和功耗。如果你后续是为了竞赛或毕业设计答辩，建议把设计重点放在数据可靠性、低功耗策略、通信失败重传上，这些比堆功能更能体现工程能力。

3. 环境准备与前置条件

开始动手前，先把工具链和验证环境准备好。

3.1 开发环境与硬件清单

最基础的硬件配置是一块普中STM32F103开发板、一个USB转串口调试线、一个ST-Link或者板载下载器。然后根据你希望实现的功能，增选传感器模块：

模块	用途	典型输出
倾斜/加速度模块	检测井盖是否倾斜或位移	I2C或SPI或ADC
干簧管或行程开关	检测井盖是否被打开	开关量
水位传感器或液位开关	检测井内积水是否超限	模拟量或开关量
气体传感器模块	检测可燃气体/有毒气体	模拟量，内部或外部ADC
红外模块	检测井口附近是否有人或障碍物	开关量
继电器或蜂鸣器	本地报警输出	开关量控制
WS2812B灯带	状态指示或夜间警示	单总线时序驱动

软件方面建议直接用STM32CubeMX生成初始化代码，再用Keil MDK或STM32CubeIDE编写应用逻辑。不要手写时钟树配置，CubeMX对初学者更友好，而且后面重新调整引脚和时钟比较快。如果你用的是老版本的固件包，ADC、低功耗接口的名称会有差异，但配置思路一致。

3.2 时钟与引脚规划

做工程前先规划引脚，不要写代码写到一半才发现引脚冲突。规划时按功能分组：

ADC组：分配给气体传感器、水位模拟量传感器。
中断组：分配给倾角报警输出、红外检测、井盖打开开关。用外部中断能配合低功耗唤醒。
UART组：一路连接调试串口打印日志，一路连接NB-IoT或WiFi模块，两路串口如果都用中断收发，要特别注意中断优先级。
控制组：蜂鸣器、继电器、WS2812B数据线。
低功耗唤醒：RTC闹钟唤醒、外部中断唤醒、或者两者同时用。

在CubeMX里把这些引脚配置好，生成工程后再补业务代码。下面是CubeMX中需要留意的几个点：

如果是ADC采集气体传感器，采样时间要设置足够长，保证信号稳定。
外部中断引脚要开启上拉或下拉，实际取决于传感器输出和模块电路。
串口波特率建议调试口用115200或9600，通信模块则按模块规格确认。
如果使用FreeRTOS，建议把RTC和外部中断唤醒逻辑放到独立任务中管理，不要把所有事情都堆在中断回调里。

3.3 开发板的原型验证边界

用普中开发板做原型验证时，最容易踩的坑是低功耗。开发板整板供电链路设计了稳压芯片、串口芯片、LED指示电路，想要让整板进入几微安到几十微安级别的待机电流，基本不可能。不要认为程序写了停机模式，电流就一定能降下来。

所以建议分两个阶段：

第一阶段：用开发板验证功能和代码逻辑。接好各种传感器，日志通过串口直接打印，看到数据能采能报，这段流程就跑通了。
第二阶段：用STM32F103最小系统板或自己画的板子做低功耗和数据保存验证。把不必要的板载外设去掉，只保留最小系统、传感器接口和通信模块电源控制。

4. 硬件连接与电平匹配设计

STM32F103是3.3V供电，而很多传感器模块和通信模块可能工作在5V。很多人会问“STM32F103的GPIO作为输入能不能承受5V电压”，这个问题没有统一答案，必须查数据手册。

STM32F103的大多数I/O引脚是FT引脚，标称兼容5V输入，但并不是所有引脚都支持，像部分与模拟功能、复位、启动模式相关的引脚并不都是FT。设计时不要凭经验把所有引脚都直接接5V信号，正确做法是：

查你所用型号的数据手册，找到引脚定义表，确认引脚表格中对应引脚是否有FT标识。
如果是推挽输出驱动5V设备或模块数据线，除了查看引脚标称，还要确认模块端逻辑电平门槛。
如果没有把握，最简单可靠的办法是使用逻辑电平转换模块，双向I2C和单方向串口电平转换都有现成的模块。

实际项目中常用的电平匹配建议：

场景	推荐做法
3.3V MCU 输出控制5V继电器	使用三极管或MOS管驱动，或使用5V继电器模块
5V传感器模拟量输出接入MCU的ADC	如果传感器输出最高超过3.3V，先分压，再加跟随器
5V UART模块和3.3V UART互联	确认双方逻辑电平，必要时使用电平转换模块
I2C总线混合3.3V和5V器件	使用电平转换模块，或选用工作电压一致的传感器
开关量输入	确认传感器是开漏输出还是推挽输出，合理配置上下拉

还有一类容易忽略的问题：很多气体传感器模块的加热丝需要5V供电，虽然信号输出可能已经是3.3V兼容，但系统供电功率会明显上升。用电池供电时，气体传感器长时间上电并不现实，更合理的做法是定时上电检测，或者等平台下发指令后再启动气体传感器检测，测完立即断电。

5. 传感器数据采集与原型验证

下面按智能井盖最常见的几个功能，给出一套可以在开发板上逐步验证的操作流程。

5.1 倾斜与位移检测

井盖被恶意打开或异常移动时，倾角传感器会发生变化。你可以用倾角模块或加速度计模块来做。加速度计可以输出X、Y、Z轴加速度数据，通过计算角度判断是否发生倾斜。

测试流程：

给模块通电，先读取模块输出的角度值或原始加速度值。
把模块平放，记录基准角度；把模块倾斜到预计报警角度，记录阈值。
编程设定一个阈值。实际项目中还要设置持续时间和连续判断逻辑，防止车辆压过井盖瞬间振动造成误报。
也可以用干簧管和磁铁组合做简单的开盖检测，把磁铁装在井盖上，干簧管装在井座侧，井盖打开时磁铁远离，干簧管状态跳变。

误报是智能井盖项目中很实际的问题。车辆反复碾压井盖是必然工况，如果稍微震动就上报“井盖打开”，后台会被大量误报淹没。所以阈值判断不能只看单次数据，要结合连续几次采样结果和延时确认逻辑。

5.2 水位检测

井内积水是常见异常，尤其暴雨天气下，水位超过警戒值需要及时预警。水位检测可以使用分立的水位开关，也可以使用连续液位传感器读取相对水位高度。

如果使用开关量水位传感器：

传感器放在需要报警的低水位和高水位两处。
高水位检测点触发后认为井内积水超标。
需要注意液体中的传感器容易出现电极氧化或接触不良，需要定期校准。

如果使用模拟量液位传感器：

传感器输出接到ADC引脚。
在CubeMX中配置ADC通道。
读取到的ADC原始值要经过多次采集中间值或者均值滤波后再参与阈值判断。

下面给一个ADC均值滤波的核心逻辑示意，代码用到的库函数请对照你自己的工程修改。

// ADC均值滤波示例，函数名以实际固件库为准 #define ADC_SAMPLE_COUNT 16 uint16_t Read_ADC_Average(void) { uint32_t sum = 0; uint16_t i = 0; for (i = 0; i < ADC_SAMPLE_COUNT; i++) { sum += MCU_ADC_ReadSingle(); // 读取一次ADC原始值 } return (uint16_t)(sum / ADC_SAMPLE_COUNT); }

实际选取阈值时，先通过串口打印不同水位下多次采样得到的ADC值，观察波动范围，再在程序里设置报警阈值和恢复阈值。不要用一个固定值硬编码，建议在调试阶段把阈值定义为宏或配置变量，方便后面标定。

5.3 气体浓度检测

可燃气体或有毒气体检测模块通常由检测元件和信号处理电路组成，输出的是模拟电压。这类模块需要在井盖下面真实环境测试才有意义，在开发板阶段可以通过给传感器通断电、改变传感器朝向或使用标定气体观察输出电压变化来验证ADC链路是否正常。

气敏传感器的特点是上电初期输出不稳定，很多模块需要预热一段时间。如果在电池供电系统里使用，建议采用“定时上电、等待模块预热、采样完立即断电”的顺序。这样虽然不能保证24小时连续监测，但能满足低功耗需求。

// 气体传感器采样流程伪代码 void GasSensor_CheckPeriodic(void) { Gas_Heater_Power_ON(); // 加热供电，如果是5V模块需要外部电源控制 MCU_Delay(30000); // 等待预热，时间以传感器手册为准 uint16_t adcValue = Read_ADC_Average(); Gas_Heater_Power_OFF(); // 采样完成后关断供电，降低功耗 if (adcValue > GAS_ALARM_THRESHOLD) { Local_Alarm_Trigger(); Report_Event("gas_high", adcValue); } }

这段逻辑的要点是加热控制尽量用单独的GPIO控制MOS管或负载开关，而不是直接由MCU引脚给传感器大电流供电。

5.4 红外监测与本地报警

红外模块在井盖项目中常用来检测井口附近是否有人或物体，也可以作为井盖被打开后的二次确认条件。如果设备发现井盖被打开，同时红外检测到有人靠近或进入，就需要触发本地声光报警。

本地报警输出有几种实现：

蜂鸣器驱动：用GPIO控制三极管或直接驱动蜂鸣器模块。
继电器输出：控制声光报警器电源。
WS2812B灯带做亮色警示：灯带需要严格的一线时序，驱动时建议关中断或使用DMA方式，否则在无线模块串口中断频繁时，容易产生颜色闪烁误差。

WS2812B的时序很敏感，STM32F103主频72MHz下可以用定时器PWM加DMA来模拟，也可以直接采用位操作加关中断的方式发送。但关中断时间不宜过长，否则会影响串口通信和RTC中断响应。一个务实的做法是使用定时器+DMA方案，避免长时间关闭全局中断。

5.5 串口日志联调

所有传感器逻辑调试阶段，都建议先把关键信息通过调试串口打印出来。日志格式尽量规范，方便写脚本分析。下面是一个很轻量的日志组织方式：

// 通过调试串口输出结构化日志 void Debug_PrintF(const char *tag, const char *key, uint32_t value) { // 示例输出: [STATE] key=value // 具体实现根据你的串口printf重定向方案调整 }

建议先确认开发板的printf重定向。普中开发板的调试方式通常是板载CH340串口芯片，用USB线连接电脑就能看到串口日志，这一点对原型验证非常方便。

6. 智能井盖状态机与事件上报逻辑

不要一开始就写一堆散乱的if else来判断各种情况。建议把井盖系统抽象成一个简单的状态机，至少包含以下几种状态：

正常状态：设备待机，周期性采集或RTC唤醒采集。
报警状态：发生倾斜、开盖、气体异常、水位超限中的任何一项。
通信状态：正在上报数据或处于重试中。
维护状态：检修人员打开井盖时，设备进入维护模式，不要频繁上报误报警。

在正常状态下，MCU的大部分时间可以休眠，由RTC周期唤醒或外部中断唤醒。唤醒后先读传感器，把采集结果与阈值比较。如果没有任何异常，也不需要每次唤醒都上报，可以采用定时上报策略，例如每30分钟上报一次心跳数据。如果发现异常，立刻上报事件。

事件上报格式建议统一：

{ "device_id": "cover-2024-001", "ts": 1735123456, "report_type": "event", "event": "cover_open", "battery": 3.72, "signal": 21, "values": { "angle": 35 } }

如果是周期上报，可以把事件字段换成心跳类型，并携带所有采集到的环境数据。无论是哪种情况，尽量统一JSON格式，减少平台端解析难度。当然，NB-IoT模块如果走非IP数据或私有协议，不一定要用JSON，需要按你所用模块的协议格式适配。

状态机实现的伪代码：

typedef enum { STATE_NORMAL, STATE_ALARM, STATE_REPORTING, STATE_MAINTENANCE } CoverState; void SmartCover_Task(void) { switch (currentState) { case STATE_NORMAL: if (CheckAlarmCondition()) { currentState = STATE_ALARM; } break; case STATE_ALARM: ReportEvent("alarm"); LocalAlarm_On(); currentState = STATE_REPORTING; break; case STATE_REPORTING: if (ReportDoneOrTimeout()) { currentState = STATE_NORMAL; Cover_SleepUntilNextEvent(); } break; case STATE_MAINTENANCE: // 检修模式，降低上报频率，避免干扰维护工作 break; default: // 复位到安全状态 break; } }

状态机的好处是后期加逻辑不容易把代码写乱。比如要加一个“连续30秒倾斜后进入报警状态”的条件，只需要在状态迁移前做条件判断，不需要改采样代码。

7. 低功耗设计与掉电数据保护

对于电池供电的智能井盖，低功耗是决定项目能否实际使用的关键。STM32F103支持睡眠模式、停机模式和待机模式。对智能井盖来说，通常选择停机模式加RTC唤醒，或者待机模式加外部中断唤醒。

停机模式下，内核时钟停止，但SRAM和寄存器内容保留，唤醒后程序可以从原来位置继续执行。待机模式功耗更低，但唤醒相当于复位，RAM内容不保留，需要保存的数据必须放到备份寄存器或外部非易失存储器里。

两种模式的特点对比：

功耗模式	唤醒方式	RAM是否保留	适用场景
睡眠模式	任意中断	保留	实时性要求较高的短时等待
停机模式	外部中断、RTC闹钟等	保留	周期性采集上报
待机模式	RTC闹钟、外部中断、复位	不保留	需要极低功耗，可接受重新初始化

在开发板上验证停机模式是可行的，但不要用开发板直接测试整板功耗。更好的做法是用STM32F103最小系统板，把这部分逻辑独立验证。

下面是一个停机模式进入与唤醒流程的示意代码，函数名和具体调用方式需要按你使用的HAL库版本调整：

// 进入停机模式之前，建议关闭不必要的时钟和外设 void MCU_EnterStopWithRTC(void) { // 停止ADC、串口、定时器等外设 Sensor_Deinit(); Com_Module_PowerOff(); // 设置RTC闹钟唤醒时间 RTC_SetAlarmInSeconds(WAKEUP_PERIOD_S); // 使能RTC闹钟中断 NVIC_EnableIRQ(RTC_Alarm_IRQn); // 进入停机模式 HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI); // 从停机模式唤醒后，先重新配置系统时钟 HAL_InitTick(); SystemClock_Reconfig(); // 重新初始化外设 Sensor_Init(); Com_Module_PowerOn(); }

从停机模式唤醒后，系统时钟需要重新配置，这是很容易漏的一步。如果你在CubeMX里开启了时钟安全系统或需要重新配置PLL，需要参考生成的代码处理。

再说掉电保存。井盖节点可能因为电池更换、检修断电或者意外断电丢失状态。要把上一次的报警状态、累计次数、平台分配的参数保存下来。可选方案：

备份寄存器：在VBAT引脚接电池时，备份寄存器的数据在系统掉电后也能保持。这是简单可靠的方式。
内部Flash：写入较慢，且有擦写寿命限制，适合保存不频繁变化的参数。
外部EEPROM：比如AT24C系列，通过I2C读写。适合保存标定参数和上报记录。

核心原则是区分静态参数和动态数据。动态采集数据丢失没有太大关系，但设备ID、报警上限、上报周期这类参数必须持久化保存。写入Flash或EEPROM时要预留校验字段，防止写入一半时掉电导致读到损坏数据。

8. 数据上报接口调试与批量接入

井盖这类终端设备数量多，不是一台一台人工查看的。平台端需要处理的是一批设备的上报、超时、离线判断和故障检修。因此通信模块的接口调试要留出日志和重试机制。

在原型验证阶段，如果使用ESP8266通过MQTT上报，可以先在电脑上启动一个MQTT Broker，比如本机的Mosquitto，然后用MQTTX订阅主题，观察上报消息。如果是NB-IoT模块，多数用AT指令走UDP/CoAP或TCP上报，需要按模块厂商手册操作。

不同模块的AT指令细节差异很大，这里只给一个非常通用的串口发送AT指令框架，重点看数据结构设计：

// 使用UART发送AT指令并等待应答的通用框架 // 实际AT指令内容以通信模块手册为准 const char *at_cmd = "AT+CSQ\r\n"; UART_SendString(at_cmd); uint8_t resp_ready = UART_WaitResponse(delay_ms); if (resp_ready) { // 判断返回内容中是否包含OK }

更重要的不是AT指令本身的写法，而是上报失败后的处理逻辑。井盖分布广、环境复杂，通信盲区不可避免。上报失败不能无限重试，算法上可以采用退避重试策略：第一次失败2秒后重试，第二次5秒后重试，再之后按更长时间间隔重试，同时本地保留告警状态，防止重启后事件丢失。

平台接入的关键字段，建议至少包含下面几个维度：

设备唯一标识，对应某一具体井盖。
上报类型，区分周期心跳和异常事件。
异常事件类型和严重程度。
电池电压和通信信号强度。
采集时间或事件发生时间。
维护日志，记录设备复位原因、重启次数。

对批量设备的管理，重点不是写业务代码，而是设计好目录和命名。建议按井盖部署位置或管理片区建立设备ID表，每个传感器和通信模块在程序里要能打印出固件版本和设备ID，这样后期批量升级和维护时不会搞混。

9. 常见问题与排查方法

结合STM32F103和智能井盖项目的实际开发特征，下面整理一个排查清单，按出现频率排序。

问题现象	可能原因	排查方式	解决方案
设备进入低功耗后整板电流仍然很大	开发板上存在稳压芯片、USB转串口芯片、LED	测量单片机最小系统的供电电流，而不是整板电流	使用最小系统板做低功耗验证；关闭板载外设
串口打印乱码	波特率不一致、时钟配置错误	核对串口助手波特率，检查CubeMX时钟树	统一波特率，重新生成时钟配置
GPIO直接输入5V后异常	对应引脚不是FT引脚	查看数据手册引脚表格	增加电平转换电路
气体传感器读数一直跳动	传感器预热不足、ADC采样时间短、电源纹波大	通过串口打印连续ADC值观察	延长预热、增加均值滤波、检查传感器电源
WS2812B颜色闪烁	全局中断长时间关闭或DMA配置异常	检查程序是否频繁开关中断	改用定时器PWM+DMA方案
停机模式唤醒后程序跑飞	唤醒后没有重新配置系统时钟	加入系统时钟重新配置	按CubeMX生成的低功耗示例代码调整
上报消息成功但平台未收到	设备ID不对、协议字段错误、网络注册失败	抓取串口AT日志，核对平台日志	统一设备ID和设备协议
RTC唤醒时间不准确	外部低速晶振不起振或配置不对	检查RTC时钟源	更换外部32.768kHz晶振或改为内部时钟，按精度要求选择

再单独回答几个被反复问到的问题。

9.1 STM32F103停机模式为什么功耗还是高

停机模式只是让内核停止运行，并没有切断外设电源。如果外部传感器、通信模块、指示灯还处于供电状态，系统总功耗当然不会低。低功耗系统的原则是“按需供电，不用的模块物理断电”。通信模块需要单独用MOS管控制电源，传感器只在采样瞬间上电。

9.2 STM32F103的GPIO能不能直接承受5V

要查你的芯片型号的数据手册。数据手册引脚定义表格里如果标注了FT，表示这个引脚可以接5V输入。但还要看是输入还是输出，如果是开漏输出加上拉到5V，也需要确认引脚参数。最稳妥的是做电平转换或隔离驱动，不要赌引脚能力。

9.3 定时器输出占空比为什么到不了100

有些定时器通道在配置PWM时，如果比较寄存器值等于自动重装载值时，输出保持有效电平，可以输出100%占空比。但部分库函数或配置路径下，100%占空比需要把CCR寄存器设置为ARR值或更高，如果配置为CCR等于ARR加1或者强制输出模式，可能会看到异常波形。排查时先看定时器计数模式和PWM模式配置，再用逻辑分析仪确认波形。

9.4 用不用FreeRTOS

如果你只是在跑一个简单的循环采样、上报，不用FreeRTOS也是完全可以的。但如果你需要同时处理传感器轮询、通信模块超时重传、低功耗任务调度、WS2812B控制，用FreeRTOS可以更好隔离不同任务的超时逻辑。要注意的是FreeRTOS里的“低功耗”通常要配置Tickless模式，否则系统Tick定时唤醒MCU会破坏停机策略。这个配置需要单独研究，不要直接套用裸机低功耗代码。

10. 从开发板原型到可用设备的落地建议

把普中开发板上跑通的原型变成可用的智能井盖设备，还需要跨过几道坎。

第一，供电系统要重新设计。真实安装中一般用锂亚电池或大容量锂电池组，不能用USB供电。电源系统要满足宽电压输入、低静态功耗、电池欠压保护。开发板上的AMS1117线性稳压芯片本身静态电流偏大，不适合长时间待机。

第二，通信模块选型要以应用场景为准。在户外地下环境，NB-IoT覆盖比WiFi可靠很多。如果原型阶段用ESP8266做WiFi验证，后面替换成NB-IoT时要注意AT指令、TCP/UDP建链方式、心跳包周期都不一样。通信模块的天线位置也要测试，井盖是金属井盖时信号衰减会比较明显，可能需要外置天线。

第三，防护等级和结构设计问题。井盖内部不是干净的实验室环境，设备要做防潮、防尘、防腐蚀处理。传感器如果长期泡在污水环境，寿命会缩短。量产级的井盖电子模块通常要灌胶或用密封壳。

第四，固件升级机制。批量设备安装后，不可能每个井盖打开重刷固件，远程升级FOTA是把产品做成熟的重要环节。STM32F103可以通过串口或通信模块下载固件到内部Flash分区，引导程序判断版本后跳转，这个可以在原型阶段提前设计。

第五，测试要覆盖真实干扰场景。车辆碾压振动、暴雨积水、高温暴晒、低温天气都需要考虑。传感器阈值要经过多轮现场标定，项目答辩时如果能拿出连续运行几天不误报的数据，会比单纯演示“能上报”更有说服力。

从合规和隐私角度再强调一次：物联网井盖通常位于城市公共区域，采集的数据可能涉及公共设施运行状态，部署和使用前必须取得相关管理部门授权。设备安装、井内检测、传感器标定都涉及安全风险，不能由无资质人员在开放道路上私自操作。演示和开发环境尽量选择实验室模拟井盖或允许操作的实验区域。

11. 总结与下一步验证方向

“普中STM32F103智能井盖”这个题目的价值在于，它把一个物联网小产品需要面对的问题——传感器采集、状态识别、低功耗唤醒、数据上报、掉电保护、设备检修——全部压缩到了一块开发板上。做完这个项目，你对STM32的理解不会只停留在点灯和串口收发，而是能体会到产品级嵌入式开发最核心的思维方式。

建议你按下面的顺序做第一轮验证：

先跑通传感器ADC读取和倾斜状态判断，用开发板串口打印关键数据，确认采集链路可靠。
再搭一个简化状态机，验证正常状态和报警状态之间的切换。
然后做RTC周期性唤醒上报或外部中断唤醒上报，确认唤醒后系统恢复稳定。
最后只在最小系统板上做低功耗电流测量，记录停机模式电流，并验证掉电保存功能。
有余力时模拟通信异常场景，测试重试退避策略，这是最容易出彩的加分项。

最容易翻车的地方不是程序写不出来，而是传感器的噪声、开发板的额外功耗、唤醒后时钟配置、通信模块热启动失败。这些坑踩一遍，比看一百篇教程都管用。

如果你正在做类似课程设计或毕业设计，建议先把“最小闭环”跑通：一个传感器状态能被检测到并通过通信模块上报，再从云端或串口助手收到数据。之后再逐步加低功耗、多传感器、远程控制，不要一开始就追求把所有传感器都堆上。单点可靠，永远比功能堆砌更重要。我的建议是，这个项目值得花时间从基本原型做到一块干净的最小系统低功耗样板，做完之后你会发现，智能井盖本身倒不是重点，重点是这套设计方法能复用到任何物联网终端设备上。