1. 从零搭建一个环境检测节点的真实动机
前阵子有个做智能楼宇运维的朋友找我，说他们手头有一批老旧的机房和仓库，想加装环境监测，但市面上的成品方案要么贵得离谱，要么数据不开放，没法接进他们自己的管理后台。他问我能不能用低成本方案做一个能测烟雾、粉尘和噪音的节点，数据直接上云，手机和电脑都能看。这个需求其实非常典型——工业现场、仓储环境、地下车库、实验室这类场景，对烟雾、粉尘和噪音的实时监测需求一直存在，但很多人卡在“不知道怎么把传感器数据稳定传到云平台”这一步。
我最终选定的方案是STM32加WiFi模组加云平台。为什么是STM32而不是ESP32这类自带WiFi的芯片？原因很简单：STM32的生态成熟度、外设资源、抗干扰能力在工业场景里更让人放心，而且把采集和通信分开，后续换通信方式（比如换成4G模组）时不用动核心采集代码。WiFi模组负责联网，STM32负责传感器采集和逻辑处理，云平台负责数据存储和可视化。这套架构看起来简单，但真正跑通并且稳定运行，中间有不少细节值得说清楚。
这篇文章适合谁看？如果你手头有STM32开发基础，想做一个能落地的物联网环境监测项目，或者你正在做类似课题、需要一套可复现的完整方案，那接下来的内容应该能帮你省下不少试错时间。我会从传感器选型、电路设计、通信协议、云平台对接、数据校准这几个维度，把整个项目的关键环节拆开讲，重点放在“为什么这么选”和“实际跑起来会遇到什么问题”上。
2. 三类传感器的选型逻辑与信号特性差异
2.1 烟雾检测：为什么我最终选了MQ-2而不是激光式
烟雾检测常见的方案有离子式、光电式和半导体式。离子式含放射性物质，民用项目基本不用考虑；光电式精度高但价格偏贵，而且对粉尘干扰敏感；半导体式以MQ系列为代表，价格低、响应快、寿命长，缺点是输出是模拟量，需要预热和校准。
我选的是MQ-2，它能检测液化气、丙烷、氢气、烟雾等多种气体，虽然 selectivity 不算顶尖，但对于“有没有烟雾”这个判断已经够用。MQ-2的加热丝需要5V供电，预热时间至少24小时才能达到稳定状态，这一点很多人会忽略——刚上电就测，数据漂得厉害。实际使用中，我建议预热48小时后再做基准校准。
MQ-2的输出是模拟电压，接STM32的ADC引脚。这里有个坑：MQ-2的输出阻抗比较高，直接接ADC会导致采样不准。我的做法是加一个电压跟随器（用LM358搭），把输出阻抗降下来再进ADC。另外，MQ-2的加热丝电流大概150mA，如果节点用电池供电，这个功耗需要认真考虑，后面电源部分会细说。
2.2 粉尘检测：GP2Y1010AU0F的红外光学原理与驱动要点
粉尘检测我选的是夏普的GP2Y1010AU0F，这是一个红外光学粉尘传感器，内部有红外LED和光电晶体管，通过检测空气中颗粒物对红外光的散射来估算粉尘浓度。它的输出也是模拟电压，但驱动方式比较特殊——需要给红外LED提供脉冲驱动，而不是持续点亮。
为什么用脉冲驱动？两个原因：一是降低功耗，LED持续点亮电流不小；二是延长LED寿命。驱动时序上，LED的驱动脉冲宽度建议在0.32ms左右，采样要在LED点亮后0.28ms进行，这个时间窗口很关键。我一开始没注意这个时序，直接给LED常供电，结果数据跳动很大，后来查了手册才发现采样时机不对。
GP2Y1010AU0F的输出电压和粉尘浓度大致呈线性关系，但不同批次的传感器一致性一般，所以每台设备最好单独校准。校准方法后面会讲。另外，这个传感器对香烟烟雾特别敏感，如果现场有人抽烟，数据会飙得很快，这是正常现象，不是故障。
2.3 噪音检测：麦克风加放大电路的设计取舍
噪音检测的本质是把声压转换成电信号，再计算有效值。我用的方案是驻极体麦克风加运算放大器。驻极体麦克风输出的是毫伏级信号，需要放大到STM32的ADC量程范围内（0-3.3V）。放大倍数怎么定？这取决于你关心的噪音范围。一般环境噪音在30-100dB之间，对应声压从0.001Pa到2Pa。驻极体麦克风的灵敏度典型值是-42dBV/Pa，换算下来1Pa声压产生约8mV信号。如果放大100倍，100dB时输出约1.6V，在ADC量程内，这个倍数比较合适。
放大电路我用的是两级运放，第一级同相放大，第二级加一个偏置电压，把信号抬到1.65V附近，这样ADC可以采集到完整的交流波形。为什么不用单级放大？因为单级放大倍数太高时，运放的带宽和噪声会成问题，两级级联更容易做到100倍且保持信号质量。
软件上，噪音的计算不是简单取ADC平均值，而是计算一段时间内的均方根值（RMS）。具体做法是连续采样N个点（比如1024个），计算平方和，开根号，再根据麦克风灵敏度和放大倍数反推声压级。这个计算量对STM32来说不大，但要注意采样率要足够高，至少2kHz以上，否则高频噪音会丢失。
3. STM32主控的资源分配与ADC采样策略
3.1 为什么选STM32F103C8T6而不是更高端的型号
STM32F103C8T6是经典的“蓝色药丸”开发板核心芯片，72MHz主频、64KB Flash、20KB RAM，对于这个项目来说绰绰有余。三路ADC采集（烟雾、粉尘、噪音）加上WiFi通信，CPU负载很低。选它的理由很实际：价格便宜、资料多、社区支持好，出了问题容易找到答案。更高端的F4系列当然性能更好，但在这个场景下属于性能过剩，成本也没必要。
资源分配上，我用PA0采集MQ-2，PA1采集粉尘传感器，PA2采集噪音放大后的信号。三个ADC通道用规则组扫描模式，DMA搬运数据，这样CPU不用一直守着ADC。定时器TIM2用来触发ADC采样，同时给粉尘传感器的LED驱动提供精确的脉冲时序。USART1接WiFi模组，用AT指令通信。剩下的GPIO用来控制传感器电源和状态指示灯。
3.2 ADC采样中的噪声抑制与参考电压选择
STM32的ADC是12位的，参考电压默认是VDDA（3.3V），但VDDA如果和数字电源共用，数字部分的开关噪声会耦合进来。我的做法是给VDDA单独加一个LC滤波，并且用一颗低噪声的LDO给模拟部分供电。实测下来，这样处理之后ADC的跳动从±5个LSB降到了±2个LSB以内。
采样策略上，烟雾和粉尘是慢变量，每秒采一次就够了；噪音需要连续采样，我用定时器触发ADC，采样率设为4kHz，采1024个点后计算RMS，这样每秒能出约4次噪音值。DMA缓冲区设成双缓冲模式，一半填满时处理一半，避免数据覆盖。
还有一个细节：ADC采样时如果WiFi模组正在发射，电源波动会影响精度。我的解决办法是在WiFi发射期间暂停ADC采样，或者给WiFi模组单独供电。我选了后者，用一颗独立的3.3V LDO给WiFi模组供电，和MCU的电源分开，这样互不干扰。
3.3 传感器预热与上电时序管理
前面提到MQ-2需要预热，GP2Y1010AU0F也需要一点稳定时间。如果节点是电池供电、间歇工作的，每次上电都等预热不现实。我的做法是：如果节点是持续供电的，那就一直给传感器供电，不做电源管理；如果是电池供电的，MQ-2的加热丝不能断，否则每次都要重新预热，所以电池方案里MQ-2的功耗必须纳入计算。
上电时序上，我让STM32先初始化，然后依次给传感器上电，延时一段时间后再开始采集。具体延时：MQ-2给48小时（首次校准前），之后每次上电给5分钟稳定；粉尘传感器给1秒；麦克风放大电路给100ms。这些延时看起来不起眼，但不做的话，刚上电的数据基本不可信。
4. WiFi模组与云平台之间的数据链路设计
4.1 AT指令配网流程与断线重连机制
WiFi模组我用的是ESP-01S，跑AT固件。配网流程是：STM32发AT指令让模组连上指定的热点，然后建立TCP连接指向云平台的地址和端口。这里的关键是断线重连——现场网络不可能永远稳定，模组掉线后必须能自动恢复。
我的做法是在STM32里维护一个状态机：每隔10秒检查一次连接状态，如果发现TCP断开，就重新走一遍连接流程。重连时不要频繁发指令，否则模组会卡死。我设了3次重试，每次间隔5秒，3次都失败就重启模组。重启模组用AT+RST指令，或者直接控制模组的复位引脚，后者更可靠。
还有一个坑：ESP-01S的AT固件版本很多，不同版本的指令响应格式有差异。我建议先用USB转串口工具把模组连到电脑上，手动发一遍指令，确认固件版本和响应格式，再写STM32的代码。这一步能省掉很多调试时间。
4.2 数据上报协议：为什么我用JSON而不是自定义二进制
数据上报格式我选了JSON，虽然比二进制占带宽，但可读性好、云平台解析方便、调试时一眼就能看懂。每条数据的格式大概是这样：
{ "device_id": "node_01", "smoke": 123, "dust": 45.6, "noise": 52.3, "timestamp": 1234567890 }smoke是ADC原始值，dust是换算后的浓度（微克每立方米），noise是声压级（分贝）。timestamp用Unix时间戳，STM32没有RTC的话可以用云平台接收时间，但最好本地有时钟，这样数据缓存后补传时时间不会乱。
上报频率我设的是每30秒一次。为什么不是每秒？因为环境参数变化慢，30秒足够反映趋势，而且能降低功耗和云平台压力。如果检测到烟雾或粉尘超标，可以临时提高到每5秒一次，这个逻辑在STM32里做判断。
4.3 云平台侧的数据接收与存储方案
云平台我用的是一个支持MQTT和HTTP的通用物联网平台。STM32通过WiFi模组发HTTP POST请求，把JSON数据传到云平台的接口。为什么用HTTP而不是MQTT？因为HTTP实现简单，AT指令直接发就行，不需要额外的MQTT协议栈。缺点是实时性不如MQTT，但对于30秒一次的上报频率，HTTP完全够用。
云平台收到数据后，存到数据库，同时提供可视化界面。我用的平台支持自定义看板，可以把三个参数分别做成折线图，还能设阈值报警。报警方式我配了邮件和Webhook，Webhook可以推送到自己的管理系统。
这里有个细节：HTTP请求的Header里要带Content-Type: application/json，否则平台可能解析失败。另外，POST的Body长度要算准，AT指令发HTTP时，长度不对会导致请求被截断。我一般先把JSON字符串拼好，算好长度，再发AT指令。
5. 从ADC原始值到物理量的换算与校准
5.1 MQ-2的电压-浓度曲线拟合与基准校准
MQ-2的输出电压和气体浓度不是线性关系，而是近似对数关系。手册上给了一条曲线，但那条曲线是在标准测试条件下得到的，实际使用中需要校准。我的校准方法是：在洁净空气中测一个基准电压V0，然后根据手册曲线反推浓度。具体公式是：
Rs/R0 = (Vc - Vout) / Vout 浓度 = a * (Rs/R0)^b其中Vc是回路电压（5V），Vout是ADC测到的电压，Rs是传感器电阻，R0是洁净空气中的电阻。a和b是常数，需要根据手册曲线拟合。我实际用的时候，简化成用Vout和V0的比值来估算，虽然精度不如完整公式，但对于“有没有烟雾”这个判断足够了。
校准步骤：把节点放在洁净空气中，预热48小时，记录V0。然后放在有烟雾的环境里（比如点一根香），记录Vout的变化，确认响应方向正确。如果Vout随烟雾增加而增加，说明电路没问题；如果反了，检查负载电阻接法。
5.2 粉尘传感器的线性度验证与零点漂移处理
GP2Y1010AU0F的输出电压和粉尘浓度大致线性，典型灵敏度是0.5V/(100微克每立方米)。也就是说，洁净空气输出约0.9V，100微克每立方米时输出约1.4V。但实际使用中，零点会漂移，尤其是湿度大的环境。
我的处理方法是：每次上电时，如果读数低于某个阈值（比如0.8V），就认为当前是洁净空气，把当前值作为零点。然后后续读数减去零点，再除以灵敏度，得到浓度。这个方法不完美，但比固定零点靠谱。
另外，这个传感器对灰尘的响应有滞后，而且不能区分粒径。如果现场有大量水汽，读数会偏高。我在软件里加了一个湿度补偿，但效果有限。如果对粉尘精度要求高，建议上激光粉尘传感器，价格贵但数据质量好很多。
5.3 噪音分贝计算的RMS算法与A计权简化
噪音的RMS计算前面提过，这里说分贝换算。ADC采到的电压Vrms，先除以放大倍数得到麦克风输出Vmic，再根据麦克风灵敏度S（单位V/Pa）算出声压P = Vmic / S。然后声压级SPL = 20 * log10(P / P0)，其中P0是参考声压，取20微帕。
人耳对低频不敏感，所以专业噪音计会用A计权。STM32上做完整的A计权需要滤波器，计算量大。我的简化方案是：不做A计权，直接算线性声压级，然后在云平台侧做粗略修正。对于“噪音有没有超标”这个判断，线性值已经够用。如果要做噪音监测报告，那还是得上专业设备。
校准噪音通道需要一个标准声源，比如活塞发声器。没有的话，可以用手机上的声级计App做粗略对比，但精度别指望太高。我一般用App在安静房间和嘈杂环境各测一次，调整放大倍数，让STM32的读数和App读数大致吻合。
6. 实际部署中遇到的坑与稳定性优化
6.1 电源噪声导致ADC跳变的排查过程
项目第一次在现场跑的时候，发现粉尘数据偶尔会跳到满量程，但现场并没有那么多粉尘。排查过程：先用示波器看ADC输入引脚，发现电源上有高频毛刺。顺着电源查，发现WiFi模组发射时，3.3V电源上有约100mV的波动。虽然我给WiFi单独用了LDO，但LDO的输入端是共用的5V，5V上的波动通过LDO耦合到了3.3V。
解决办法：在5V输入端加一个大电容（470uF）和一个小电容（0.1uF）并联，LDO输出端也加0.1uF。另外，ADC采样时如果WiFi正在发射，就丢弃这次采样，等WiFi空闲再采。这样处理后，数据稳定了很多。
6.2 WiFi信号强度对数据上报成功率的影响
现场WiFi信号强度是个大问题。模组离路由器远的时候，TCP连接经常断。我的做法是：在STM32里读取模组的RSSI（信号强度），如果RSSI低于-80dBm，就降低上报频率，减少连接次数；如果低于-90dBm，就只缓存数据，等信号好了再补传。
缓存怎么做？STM32的Flash还有空间，我划了一块区域做环形缓冲区，每条数据存进去，上报成功后标记删除。如果网络断了，数据先存着，恢复后按时间顺序补传。这个机制在无人值守的场景里非常必要。
6.3 长时间运行后的内存泄漏与看门狗复位
STM32跑FreeRTOS的话，任务栈溢出和内存泄漏是常见问题。我一开始用动态内存分配，跑几天就死机。后来改成静态分配，所有缓冲区都在编译时确定大小，问题就没了。另外，看门狗一定要开，我用的独立看门狗，超时设2秒，主循环里定期喂狗。如果程序跑飞，看门狗会复位，复位后重新初始化，数据不会丢（因为存在Flash里）。
还有一个细节：WiFi模组的AT指令响应有时候会丢，如果STM32一直等响应，就会卡死。我的做法是给每个AT指令设超时，超时后重发或重启模组。这个逻辑用状态机实现，不要用阻塞式等待。
7. 数据可视化与报警阈值的设定经验
7.1 云平台看板的设计要点
云平台看板我做了三个折线图，分别对应烟雾、粉尘、噪音。每个图下面有一个阈值线，超过阈值时折线变红。看板上还放了当前值和最近24小时的最大值、平均值。为什么放最大值？因为环境监测里，峰值往往比平均值更重要，比如粉尘峰值可能反映了一次突发污染。
看板刷新频率我设的是1分钟，和上报频率匹配。如果上报频率是30秒，看板刷新可以设成30秒，但没必要更快，因为环境参数变化慢。
7.2 阈值设定的依据与动态调整思路
阈值怎么定？这个没有统一标准，取决于场景。机房烟雾报警阈值可以设低一点，因为机房不允许有烟雾；仓库粉尘阈值可以设高一点，因为仓库本身可能有粉尘。我的做法是：先跑一周，收集数据，看正常情况下的波动范围，然后把阈值设在正常范围的上限再加20%的余量。
动态调整的思路是：如果某个阈值经常被触发，但现场并没有异常，说明阈值设低了，可以调高；如果从来没触发过，可能设高了，可以调低。这个调整需要人工介入，不要做成自动的，否则可能掩盖真实问题。
7.3 报警去抖与多级报警策略
报警去抖很重要。如果噪音偶尔超一下阈值就报警，那报警就没意义了。我的做法是：连续3次上报都超过阈值才触发报警，而且报警后如果恢复正常，要连续3次低于阈值才解除报警。这样能过滤掉偶发波动。
多级报警我设了两级：一级是预警，超过阈值但没超太多，只记录不通知；二级是报警，超过阈值较多，发邮件和Webhook。这样运维人员可以先处理紧急的，预警的可以稍后看。
8. 后续扩展方向与个人实操体会
这个节点跑通之后，扩展方向其实很多。比如加一个继电器，检测到烟雾超标就自动启动排风扇；加一个SD卡，本地也存一份数据，防止网络长期中断导致数据丢失；把WiFi换成4G模组，就能用在没有WiFi的户外场景。硬件上，STM32的引脚还有富余，加温湿度传感器也很容易。
我个人在实际操作中的体会是：物联网项目最难的不是写代码，而是让设备在真实环境里稳定跑下去。实验室里跑通和现场跑三个月是两回事。电源质量、网络稳定性、传感器漂移，这些问题只有在现场才会暴露。所以我的建议是，做完原型后，一定要拿到现场去跑，至少跑一周，把遇到的问题都记下来，逐个解决。另外，数据校准不要追求一次到位，先跑起来，拿到真实数据后再回头调校准参数，这样效率更高。
还有一个小技巧：在STM32里加一个命令行接口，通过串口可以查看当前传感器读数、网络状态、缓存数据量。调试的时候非常有用，不用每次都连云平台看。这个接口用简单的字符解析就行，不需要复杂的协议。
