STM32环境监测节点实战：烟雾粉尘噪音传感器选型与WiFi上云

1. 从零搭建一个能用的环境监测节点，先想清楚这三件事

烟雾、粉尘、噪音这三个指标凑在一起，做环境监测节点是个很经典的需求。工厂车间要盯粉尘浓度，办公室要盯噪音和烟雾报警，地下车库要盯烟雾和颗粒物，场景不同但底层逻辑一样：传感器采集、主控处理、无线传输、云端展示。我前后做过几个类似的项目，从最早的纯本地蜂鸣器报警，到后来接WiFi上云做远程监控，踩过的坑基本覆盖了从硬件选型到云端数据落地的全链路。

这篇内容适合谁看？如果你手上有STM32的开发板，想做一个能实际跑起来的环境监测系统，而不是停留在点灯和串口打印阶段，那这篇就是写给你的。我会把传感器选型、STM32端的采集逻辑、WiFi模块的通信配置、云平台的数据对接这几个环节拆开讲，重点放在那些文档里不会写、但实际调试时一定会遇到的问题上。

先明确一个核心思路：环境监测节点的本质是一个周期性采集加可靠上报的系统。听起来简单，但实际做的时候你会发现，传感器的模拟量输出需要滤波、WiFi连接会断、云端会丢包、电源会波动。这些问题不解决，做出来的东西就只能放在桌上演示，没法真正投入使用。所以我在设计阶段就会把可靠性放在第一位，而不是先追求功能多。

另外说一个很多人容易忽略的点：三个传感器的采样节奏不应该完全一样。烟雾和粉尘的变化相对缓慢，几秒采一次完全够用；噪音是瞬时量，采太快数据量爆炸，采太慢又会漏掉突发噪音。我一般会把噪音的采样周期设得比烟雾和粉尘短一些，但上报周期统一，这样既保证了数据质量，又不会让WiFi模块频繁发送小包导致功耗和稳定性问题。这个细节后面会展开讲。

2. 传感器选型：别只看量程和精度，接口和供电才是第一道坎

2.1 烟雾检测：MQ系列还是专用模块

烟雾检测最常见的方案是MQ-2或MQ-135这类半导体气敏传感器。便宜、好买、模拟输出，STM32的ADC直接就能读。但它有几个坑必须提前知道。

第一，MQ系列需要预热。冷启动时输出漂移很大，通常要预热几分钟甚至更久才能稳定。我试过在上电后立刻读值，结果前几十秒的数据完全不可信。解决办法是在固件里加一个预热标志位，预热期间数据标记为无效，不上报云端。

第二，MQ系列的输出是模拟电压，但它的输出阻抗不低，直接接STM32的ADC引脚，如果采样时间设得太短，读数会偏低。STM32的ADC采样时间需要根据外部阻抗调整，一般建议把采样周期设长一些，比如239.5个ADC时钟周期，让采样电容充分充电。

第三，MQ系列对温湿度敏感。同一个浓度的烟雾，夏天和冬天读出来的值可能差不少。如果项目要求精度，要么加温湿度补偿，要么在云端做数据校准。我一般会在节点上再加一个便宜的温湿度传感器，把温湿度一起上报，云端做补偿计算。

如果你不想用MQ系列，也可以考虑专用的烟雾检测模块，比如基于红外散射原理的颗粒物传感器，它对烟雾的响应更直接，但价格会高一些。选哪个取决于你的预算和精度要求。

2.2 粉尘检测：光学原理是主流，但要注意气流

粉尘检测我强烈建议用光学散射原理的传感器，比如常见的GP2Y1010AU0F或者更便宜的替代品。它的原理是红外LED发光，颗粒物反射光线到光电管，输出模拟电压。相比MQ系列，它对粉尘的响应更线性，也更稳定。

但这个传感器有个致命问题：它需要气流通过检测腔。如果你把它焊在板子上静止不动，粉尘进不去，读数永远是零。我见过有人把粉尘传感器装在密封盒子里，然后抱怨读不到数据，这就是没理解原理。正确的做法是让传感器暴露在空气中，或者加一个小风扇制造气流。如果环境粉尘浓度很低，可以考虑加一个微型风扇主动抽气。

另外，粉尘传感器的LED需要脉冲驱动，不能一直亮着。一直亮会导致LED发热，影响读数，也浪费电。典型的驱动方式是：LED亮0.32ms，然后在这个窗口内读ADC，然后LED灭，等下一个周期。STM32的定时器可以精确控制这个时序，用PWM输出驱动LED，在PWM高电平期间触发ADC采样。

2.3 噪音检测：麦克风加放大，别指望直接读

噪音检测的常见方案是驻极体麦克风加运算放大器。麦克风输出的是毫伏级的交流信号，STM32的ADC读不了负电压，所以需要加偏置电路，把信号抬到VCC/2附近，再放大到ADC能识别的范围。

这里有个关键点：噪音是交流信号，你读到的ADC值是瞬时值，不是噪音大小。要得到噪音的分贝值，需要在固件里做RMS计算。具体做法是：在一个采样窗口内连续读N个ADC值，计算均方根，然后转成电压，再根据麦克风的灵敏度和放大倍数反推声压级。这个过程计算量不小，如果STM32主频不高，建议用定时器触发ADC加DMA，让DMA自动搬运数据，CPU只负责计算。

放大倍数怎么定？取决于你的测量范围。如果测的是办公室噪音，大概40到80分贝，麦克风输出可能在几毫伏到几十毫伏，放大100倍左右比较合适。如果测工厂噪音，可能到100分贝以上，放大倍数要降低，否则信号会削顶。我一般会留一个可调电阻，实际调试时根据环境调整。

2.4 三个传感器的供电和接口汇总

供电方面，MQ和粉尘传感器通常要5V，STM32是3.3V，所以需要一个5V稳压。如果整个节点用USB供电，5V直接从USB取就行。如果用电池供电，就要考虑升压电路和功耗管理。我一般会在5V和3.3V之间加磁珠和电容滤波，避免传感器噪声串到MCU电源上。

3. STM32端的采集逻辑：定时器、ADC和DMA的配合

3.1 为什么不用轮询而用定时器触发

很多初学者写采集代码就是while循环里读ADC，加个delay。这种写法在单任务里能用，但一旦加入WiFi通信，问题就来了：WiFi发送数据时可能阻塞几百毫秒，这期间ADC完全不采，数据就丢了。

正确的做法是用定时器触发ADC，ADC转换完成后触发DMA搬运，DMA搬完一整块数据后触发中断，CPU在中断里处理数据。这样采集和通信解耦，WiFi发送再慢也不影响采集节奏。

具体配置：用一个通用定时器，比如TIM2，设置成1kHz的更新频率。每次更新事件触发ADC开始转换。ADC配置成外部触发模式，触发源选TIM2的TRGO。DMA配置成循环模式，缓冲区大小根据采样窗口定。比如噪音需要在一个窗口内采200个点，那DMA缓冲区就设200个halfword。

3.2 三个通道的ADC扫描和数据处理

STM32的ADC支持扫描模式，可以按顺序转换多个通道。我把烟雾、粉尘、噪音分别接到ADC的三个通道上，配置成扫描模式，DMA搬运。这样一次触发就能把三个通道都采一遍。

但噪音需要连续采很多点算RMS，而烟雾和粉尘只需要一个值。怎么处理？我的做法是：噪音通道在DMA缓冲区里占大头，烟雾和粉尘各占一个位置。比如DMA缓冲区设成202个halfword，前200个是噪音的连续采样，第201个是烟雾，第202个是粉尘。定时器触发一次，ADC按顺序转换这三个通道，DMA依次搬运。噪音的200个点算RMS，烟雾和粉尘直接取最后一次的值。

这个方案的好处是硬件自动完成，CPU负担小。缺点是DMA缓冲区要开得比较大，STM32F103的话RAM够用，如果是更小的型号要注意。

3.3 数据滤波：滑动平均和中值滤波怎么选

原始ADC数据一定有噪声。烟雾和粉尘的噪声主要来自电源波动和传感器本身的热噪声，噪音的RMS值也会有波动。我一般对烟雾和粉尘用滑动平均，窗口大小8到16，既能平滑数据又不会太滞后。噪音的RMS值用中值滤波，因为噪音偶尔会有突发尖峰，滑动平均会被尖峰拉高，中值滤波能有效剔除。

滑动平均的实现很简单：开一个数组，每次新数据进来，替换最老的数据，然后求平均。中值滤波稍微麻烦一点，需要排序，但窗口小的话计算量可以接受。如果STM32主频够高，也可以用快速排序的变种。

注意：滤波窗口不要设太大，否则数据滞后严重。环境监测一般要求秒级响应，窗口太大可能导致报警延迟。

3.4 数据打包和上报周期

采集到的数据需要打包成固定格式，方便WiFi模块发送和云端解析。我一般用简单的自定义协议：帧头两个字节，然后是烟雾值、粉尘值、噪音值、温度、湿度，每个两字节，最后加一个校验和。总共十几个字节，一包就能发完。

上报周期怎么定？烟雾和粉尘变化慢，30秒上报一次足够。噪音如果要做实时监控，可以10秒上报一次。但上报太频繁会增加WiFi功耗和云端压力。我的折中方案是：正常状态下30秒上报一次，如果任一指标超过阈值，立刻上报一次报警包，然后恢复到30秒周期。这样既省电又能及时报警。

4. WiFi模块的通信配置：AT指令还是透传

4.1 模块选型和接线

WiFi模块我用过几种，从早期的ESP8266到后来的ESP32，还有各种AT指令模块。如果只是做数据透传，ESP8266的AT固件就够用，价格便宜，资料多。如果要做更复杂的逻辑，比如本地网页配置，那ESP32更合适。

接线方面，STM32和WiFi模块之间用串口通信，一般是UART。注意电平匹配：STM32是3.3V，ESP8266也是3.3V，可以直接连。但如果用5V的模块，就要加电平转换。我见过有人直接把5V模块接到STM32串口上，结果通信不稳定，甚至烧引脚。

供电是另一个大坑。ESP8266在发送数据时瞬间电流能到300mA以上，如果电源不够猛，电压会跌落，导致模块重启。我一般会在模块的VCC和GND之间并一个100uF以上的电解电容，再并一个0.1uF的陶瓷电容，保证瞬态响应。

4.2 AT指令配置流程和常见错误

用AT指令配置ESP8266连WiFi和云平台，基本流程是：复位模块、设置工作模式、连接路由器、建立TCP连接、发送数据。每一步都有坑。

复位模块后，要等它输出"ready"，不能立刻发指令。我试过复位后马上发AT，结果模块还没启动完，指令丢了。正确做法是等"ready"出现，或者延时足够长。

连接路由器时，AT+CWJAP指令会阻塞几秒，这期间不能发其他指令。如果路由器信号弱，可能超时失败。我的做法是加超时判断，失败就重试，重试三次还失败就重启模块。

建立TCP连接时，AT+CIPSTART指令需要指定协议、IP和端口。如果云端是域名，要先做DNS解析。DNS解析也可能失败，同样要重试。

发送数据时，AT+CIPSEND指令要先告诉模块发多少字节，然后等模块返回">"，再发实际数据。这个流程如果搞错，数据就发不出去。我见过有人直接发数据不等">"，结果模块把数据当成AT指令解析，完全乱套。

4.3 断线重连和心跳机制

WiFi连接不可能永远稳定。路由器重启、信号波动、云端维护，都会导致连接断开。如果固件里没有重连机制，节点就变成孤岛了。

我的做法是：在STM32里维护一个连接状态标志，每次发送数据前检查标志。如果发送失败，或者收到模块的"CLOSED"提示，就把标志置为断开，然后启动重连流程。重连流程包括：检查WiFi连接、重新建立TCP、重新发送数据。

心跳机制也很重要。有些云平台会主动断开长时间没有数据的连接。我一般每60秒发一个心跳包，内容可以是固定的几个字节，云端收到后知道节点还活着。如果云端有心跳响应，STM32收到响应后刷新连接状态，收不到就触发重连。

4.4 数据发送的缓冲和重发策略

如果WiFi正在重连，采集到的数据怎么办？直接丢掉太可惜，我一般会在STM32的RAM里开一个环形缓冲区，把最近几十条数据存起来。WiFi恢复后，先把缓冲区的数据补发，再发最新数据。这样即使网络断了几分钟，数据也不会丢。

但缓冲区不能无限大，STM32的RAM有限。我一般设成能存50条左右，满了就覆盖最老的数据。如果网络断了太久，老数据被覆盖也没办法，总比整个系统卡死强。

重发策略也要注意：不要一失败就疯狂重发，那样会阻塞主循环。我的做法是失败后等几秒再重试，重试间隔逐渐拉长，避免网络拥塞时雪上加霜。

5. 云平台对接：数据怎么存、怎么展示、怎么报警

5.1 云平台选型和数据协议

云平台的选择很多，有通用的物联网平台，也有自己搭的服务器。如果只是做demo，用通用的物联网平台最快，注册账号、创建设备、拿到连接信息就能用。如果要长期运行，自己搭服务器更可控，但维护成本高。

数据协议方面，MQTT是主流。它比TCP透传更规范，支持发布订阅、QoS、遗嘱消息。但MQTT对STM32来说稍微重一点，需要移植MQTT客户端库。如果资源紧张，用TCP透传加自定义协议也能用，就是云端要自己解析。

我一般会推荐MQTT，因为它的遗嘱消息功能很实用：节点掉线时，云端能立刻知道，而不是等心跳超时。这对报警系统很重要。

5.2 数据存储和可视化

云端收到数据后，一般存到时序数据库里，比如InfluxDB或者云平台自带的存储。存储结构按时间戳加设备ID加指标值来设计，方便查询和聚合。

可视化方面，云平台一般都有仪表盘功能，可以拖拽生成图表。我一般会做三个图：烟雾浓度趋势、粉尘浓度趋势、噪音分贝趋势。再加一个实时数值显示，方便快速查看当前状态。

如果云平台不支持自定义仪表盘，也可以自己写一个简单的网页，用WebSocket实时接收数据，用图表库画图。这个方案灵活但工作量大，适合有前端基础的人。

5.3 报警规则和通知方式

报警是环境监测的核心价值。没有报警，数据就只是数据。报警规则一般设阈值：烟雾超过某个值、粉尘超过某个值、噪音超过某个值，就触发报警。

报警通知方式有几种：云平台内置的通知、邮件、短信、Webhook推送到其他系统。我一般会用Webhook推送到一个消息队列，然后由其他服务处理。这样灵活，可以对接各种通知渠道。

报警规则要注意防抖。如果数据在阈值附近波动，可能会频繁触发报警。我一般会加一个持续时间条件：超过阈值持续10秒才报警，避免误报。另外，报警后要有一个恢复通知，告诉用户环境恢复正常了。

5.4 云端数据校准和补偿

前面提到传感器对温湿度敏感，云端可以做补偿。具体做法是：根据温湿度值查表或者用公式计算补偿系数，然后对烟雾和粉尘的原始值做修正。补偿公式需要根据传感器手册和实际标定数据来定，没有通用公式。

如果项目要求高，还可以做多点标定：在已知浓度的环境下记录传感器输出，拟合出曲线，云端用这个曲线反推浓度。这个工作比较繁琐，但能显著提高精度。

6. 实测中遇到的几个典型问题和排查过程

6.1 WiFi模块频繁重启

现象：节点运行几分钟后，WiFi模块突然断开，然后重新连接，循环往复。

排查过程：先查电源，用示波器看模块VCC引脚，发现发送数据时电压从3.3V跌到2.8V。确认是电源瞬态响应不够。解决办法是在模块VCC附近加100uF电解电容和0.1uF陶瓷电容，电压跌落降到3.1V以上，问题解决。

这个坑很典型，很多WiFi模块的规格书里会写瞬间电流，但实际布线时容易忽略电容。我的经验是：不管规格书怎么说，WiFi模块旁边一定要加足够大的电容，宁大勿小。

6.2 噪音数据跳变严重

现象：噪音RMS值在安静环境下也会突然跳到很高，然后恢复。

排查过程：先用示波器看麦克风放大后的信号，发现偶尔有尖峰。检查电路，发现放大器的电源没有滤波，WiFi模块的噪声串到了放大器电源上。在放大器电源引脚加RC滤波后，尖峰消失。

另一个原因是软件滤波窗口太小。把中值滤波窗口从5加大到11后，数据平滑了很多。但窗口不能无限大，否则响应变慢。最终用11，兼顾平滑和响应。

6.3 云端数据偶尔丢失

现象：云端图表上偶尔有数据点缺失，但节点日志显示数据已发送。

排查过程：先查WiFi模块的发送日志，发现有些数据包发送后没有收到云端的ACK。再查云端日志，发现这些包确实没到。怀疑是TCP连接在发送瞬间断了。后来在STM32里加了发送确认机制：发送后等云端ACK，超时没收到就重发。重发后数据不再丢失。

这个问题的根因是TCP连接不稳定，但TCP本身不保证应用层数据一定到达。应用层加确认机制是必要的，尤其是对可靠性要求高的场景。

6.4 粉尘传感器读数始终为零

现象：粉尘传感器接上后，ADC读数一直是零，换传感器也一样。

排查过程：先查供电，5V正常。再查LED驱动信号，用示波器看LED引脚，发现没有脉冲。检查代码，发现定时器配置错了，PWM没有输出。修正定时器配置后，LED正常闪烁，ADC读数正常。

这个坑是典型的配置错误。粉尘传感器的LED驱动时序很关键，如果PWM频率或占空比不对，LED不亮或者一直亮，都会导致读数异常。建议先用示波器确认LED驱动信号，再查ADC。

7. 几个能直接抄的实操建议

第一，电源设计留足余量。WiFi模块、传感器、MCU的电流需求加起来可能超过500mA，如果电源只能提供500mA，满载时电压会跌。我一般会选1A以上的电源，留一倍余量。

第二，ADC参考电压要稳。STM32的ADC参考电压如果波动，所有模拟读数都会漂。如果板子上有WiFi模块，建议用独立的LDO给模拟部分供电，或者至少在参考电压引脚加足够的滤波电容。

第三，固件里加看门狗。环境监测节点通常无人值守，如果固件跑飞，没有看门狗就会死机。STM32内置独立看门狗，配置成几秒超时，主循环里定期喂狗。如果喂狗失败，看门狗复位MCU，节点自动恢复。

第四，云端数据保留策略要提前定。如果数据量不大，可以永久保留。如果数据量大，要定期清理或者降采样。我一般会保留原始数据一个月，然后降采样成小时平均值长期保留。

第五，调试时先用串口打印所有关键数据。传感器原始值、滤波后值、WiFi连接状态、发送结果，全部打印出来。这样出问题时能快速定位是哪个环节的问题。等系统稳定了再关掉打印，节省资源。

第六，外壳设计要考虑气流和散热。粉尘传感器需要气流，噪音传感器需要声音能传进去，WiFi模块需要散热。如果外壳密封太严，粉尘读不到，噪音被闷住，WiFi模块过热。我一般会在外壳上开孔，但加防尘网，兼顾防护和透气。

这套方案我前后迭代了几次，从最早的频繁掉线、数据跳变，到后来能连续运行几周不出问题，关键就是把电源、滤波、重连、确认这几个环节做扎实。环境监测节点不难，难的是稳定运行。希望这些经验能帮你少走弯路。