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 三个传感器的供电和接口汇总传感器输出类型供电接口注意事项烟雾模拟电压5VADC需预热输出阻抗高粉尘模拟电压5VADCGPIOLED脉冲驱动需气流噪音模拟交流3.3VADCDMA需偏置和放大RMS计算供电方面MQ和粉尘传感器通常要5VSTM32是3.3V所以需要一个5V稳压。如果整个节点用USB供电5V直接从USB取就行。如果用电池供电就要考虑升压电路和功耗管理。我一般会在5V和3.3V之间加磁珠和电容滤波避免传感器噪声串到MCU电源上。3. STM32端的采集逻辑定时器、ADC和DMA的配合3.1 为什么不用轮询而用定时器触发很多初学者写采集代码就是while循环里读ADC加个delay。这种写法在单任务里能用但一旦加入WiFi通信问题就来了WiFi发送数据时可能阻塞几百毫秒这期间ADC完全不采数据就丢了。正确的做法是用定时器触发ADCADC转换完成后触发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.3VESP8266也是3.3V可以直接连。但如果用5V的模块就要加电平转换。我见过有人直接把5V模块接到STM32串口上结果通信不稳定甚至烧引脚。供电是另一个大坑。ESP8266在发送数据时瞬间电流能到300mA以上如果电源不够猛电压会跌落导致模块重启。我一般会在模块的VCC和GND之间并一个100uF以上的电解电容再并一个0.1uF的陶瓷电容保证瞬态响应。4.2 AT指令配置流程和常见错误用AT指令配置ESP8266连WiFi和云平台基本流程是复位模块、设置工作模式、连接路由器、建立TCP连接、发送数据。每一步都有坑。复位模块后要等它输出ready不能立刻发指令。我试过复位后马上发AT结果模块还没启动完指令丢了。正确做法是等ready出现或者延时足够长。连接路由器时ATCWJAP指令会阻塞几秒这期间不能发其他指令。如果路由器信号弱可能超时失败。我的做法是加超时判断失败就重试重试三次还失败就重启模块。建立TCP连接时ATCIPSTART指令需要指定协议、IP和端口。如果云端是域名要先做DNS解析。DNS解析也可能失败同样要重试。发送数据时ATCIPSEND指令要先告诉模块发多少字节然后等模块返回再发实际数据。这个流程如果搞错数据就发不出去。我见过有人直接发数据不等结果模块把数据当成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模块过热。我一般会在外壳上开孔但加防尘网兼顾防护和透气。这套方案我前后迭代了几次从最早的频繁掉线、数据跳变到后来能连续运行几周不出问题关键就是把电源、滤波、重连、确认这几个环节做扎实。环境监测节点不难难的是稳定运行。希望这些经验能帮你少走弯路。
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 三个传感器的供电和接口汇总传感器输出类型供电接口注意事项烟雾模拟电压5VADC需预热输出阻抗高粉尘模拟电压5VADCGPIOLED脉冲驱动需气流噪音模拟交流3.3VADCDMA需偏置和放大RMS计算供电方面MQ和粉尘传感器通常要5VSTM32是3.3V所以需要一个5V稳压。如果整个节点用USB供电5V直接从USB取就行。如果用电池供电就要考虑升压电路和功耗管理。我一般会在5V和3.3V之间加磁珠和电容滤波避免传感器噪声串到MCU电源上。3. STM32端的采集逻辑定时器、ADC和DMA的配合3.1 为什么不用轮询而用定时器触发很多初学者写采集代码就是while循环里读ADC加个delay。这种写法在单任务里能用但一旦加入WiFi通信问题就来了WiFi发送数据时可能阻塞几百毫秒这期间ADC完全不采数据就丢了。正确的做法是用定时器触发ADCADC转换完成后触发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.3VESP8266也是3.3V可以直接连。但如果用5V的模块就要加电平转换。我见过有人直接把5V模块接到STM32串口上结果通信不稳定甚至烧引脚。供电是另一个大坑。ESP8266在发送数据时瞬间电流能到300mA以上如果电源不够猛电压会跌落导致模块重启。我一般会在模块的VCC和GND之间并一个100uF以上的电解电容再并一个0.1uF的陶瓷电容保证瞬态响应。4.2 AT指令配置流程和常见错误用AT指令配置ESP8266连WiFi和云平台基本流程是复位模块、设置工作模式、连接路由器、建立TCP连接、发送数据。每一步都有坑。复位模块后要等它输出ready不能立刻发指令。我试过复位后马上发AT结果模块还没启动完指令丢了。正确做法是等ready出现或者延时足够长。连接路由器时ATCWJAP指令会阻塞几秒这期间不能发其他指令。如果路由器信号弱可能超时失败。我的做法是加超时判断失败就重试重试三次还失败就重启模块。建立TCP连接时ATCIPSTART指令需要指定协议、IP和端口。如果云端是域名要先做DNS解析。DNS解析也可能失败同样要重试。发送数据时ATCIPSEND指令要先告诉模块发多少字节然后等模块返回再发实际数据。这个流程如果搞错数据就发不出去。我见过有人直接发数据不等结果模块把数据当成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模块过热。我一般会在外壳上开孔但加防尘网兼顾防护和透气。这套方案我前后迭代了几次从最早的频繁掉线、数据跳变到后来能连续运行几周不出问题关键就是把电源、滤波、重连、确认这几个环节做扎实。环境监测节点不难难的是稳定运行。希望这些经验能帮你少走弯路。
