做了这个项目之后我才真正理解“室内空气质量监控”这件事的边界在哪里。一开始我以为不就是把PM2.5传感器、温湿度传感器接到单片机上读个值、显示出来吗真把系统搭起来、让它在房间里连续跑几天之后才发现问题接二连三传感器互相干扰、数值漂移、继电器一吸合单片机就复位、数据跟标准仪器对不上……每一件都在逼着我把方案推翻重来。这篇博文就以“基于单片机的室内空气质量监控系统设计”为主线把我从选型、硬件连接、软件框架、标定实测到调试排障的完整过程写出来。既不绕弯子也不藏着掖着。如果你是正在做课程设计、毕业设计或者想给家里DIY一套空气质量监测设备这篇内容应该能帮你少走不少弯路。我会把用到的主控、传感器选型思路、关键代码片段、踩过的坑和最后的联网扩展方案都摊开讲清楚。1. 方案选型先定传感器再定单片机这个顺序不能反1.1 拆监测需求室内空气到底要盯哪些指标很多人做这类项目喜欢一上来就挑单片机我却建议先想明白一个问题你究竟要监测哪些参数这决定了整个系统的成本、体积和开发难度。最常见的室内空气质量参数有这么几个PM2.5颗粒物浓度大家最关心也是“空气质量”这个词的代表指标。检测原理有红外散射和激光散射两种。激光散射式的模组通常串口直接输出数值精度和稳定性都更好价格也就贵二三十块钱我直接选了激光式的。温湿度温度和相对湿度是基础参数也会影响其他传感器的读数。常见的有DHT11、DHT22这类单总线传感器也有更好的I2C接口传感器。DHT22性价比高精度够用。甲醛装修污染的重头戏。市面上的甲醛传感器多是电化学原理输出模拟电压需要预热和定期校准新手容易在这里翻车。但既然要做“室内空气质量”甲醛还是得有。CO2反映通风状况。靠谱的方案是非分散红外NDIR原理价格比较高。如果预算有限可以暂时不做但扩展接口最好留出来。我记得第一版方案里贪多把五种传感器全塞进去结果光是应对传感器之间的供电和信号干扰就花了两周。后来冷静下来把需求收敛成“PM2.5 温湿度 甲醛”三个核心指标CO2作为二期扩展项目节奏立刻顺畅了很多。这就是典型的“传感器选型决定项目骨架”主控反而好定。1.2 匹配主控资源从外设需求倒推单片机型号定了传感器之后再去数需要的主控资源PM2.5激光模组是串口UART输出占用1路串口温湿度传感器用单总线或I2C占用1个GPIO或I2C接口甲醛传感器是模拟电压输出需要1路ADC显示用OLED走I2C和温湿度传感器可以复用同一路I2C还要预留蜂鸣器、LED、按键的GPIO。数完这些资源主控的选择就清楚了。我做这个项目用的是一颗很常见的Cortex-M3内核单片机具体型号是STM32F103C8T672MHz主频、3路UART、2路ADC、I2C和SPI齐全Flash和RAM也够用关键是资料多、Demo多出了问题不容易卡住。如果你预算更低用51单片机也能做但ADC精度、串口数量、定时器资源都会比较吃紧后续加WiFi模块也很难扩展。显示方案我纠结过LCD1602和OLED。LCD1602虽然便宜但并口占用IO多显示信息量有限OLED0.96寸I2C只需要两根线还能显示中文和简单图形我最终选了OLED。报警部分用有源蜂鸣器最省事IO一拉高就响不需要自己产生频率继电器则选带光耦隔离的模块后面调试时才意识到这个选择有多重要。2. 硬件连接供电、电平与布局里的三个坑2.1 电源树设计为什么传感器一启动就单片机复位这个坑我印象太深了。第一次搭好电路板烧录完程序屏幕刚亮起来还没高兴几秒PM2.5传感器一转起来整个系统就黑屏重启。用万用表量电源发现5V被拉到了4.2V左右3.3V更是抖得不像样。问题出在电源树设计上。PM2.5激光模组内部有个风扇启动瞬间电流可以到几百毫安甲醛传感器需要加热稳压电流也不小蜂鸣器和继电器更是出了名的“电老虎”。如果所有器件都从一个5V稳压输出上取电任何一个大电流动作都会把电源电压拽下去单片机一检测到掉电就复位。我后来把电源分成两路5V输入先经过一个1000uF电解电容稳压再分成两路——一路直接给传感器供电另一路经过LDO降到3.3V单独给单片机、OLED和逻辑电路供电。继电器则干脆用独立电源不跟传感器共用5V。这样即使传感器瞬时电流很大3.3V这路也几乎不受影响。经验总结电源树要看谁是大电流设备谁是对电压敏感的设备敏感设备必须单独一路。所有器件塞在一个稳压器后面是最省事也是最容易翻车的设计。2.2 电平匹配与共地串口乱码和ADC漂移的根源硬件第二个坑是电平匹配。PM2.5激光模组大多是5V逻辑输出而STM32F103的串口引脚是3.3V逻辑。直接把5V信号接到3.3V引脚上短时间不会有问题但长期跑下来容易损伤引脚更常见的是电平不匹配导致数据乱码。解决方法有两种选3.3V供电版本的模组或者在5V输出和单片机RX之间加分压电阻。我图省事换成了3.3V版本模组省掉转换电路。甲醛传感器的模拟输出虽然也是电压信号但输出阻抗不低直接接ADC会造成读数不稳。我在信号线上并联了一个0.1uF电容做滤波并且让ADC采样引脚和模拟地尽量短距离走线。另外一个容易被忽略的是共地所有传感器、单片机、显示屏的GND必须连在一起否则信号线之间的参考电位不一致串口乱码、ADC漂移全来了。2.3 PCB布局的教训传感器不要贴着单片机放如果是手工面包板/洞洞板搭电路位置自由度大但我也吃过亏。第一版把PM2.5模组紧挨着甲醛传感器放结果甲醛数值始终偏高。后来才反应过来PM2.5模组内部的风扇和激光器都是发热源热气流往上蹿正好经过甲醛传感器的进气口导致电化学传感器读数被干扰。PCB布局我总结三条经验传感器尽量放在板子边缘进气口朝外不要被外壳和排线挡住发热器件稳压芯片、主控与传感器之间留出至少1cm以上的距离蜂鸣器和继电器这类会产生电磁干扰的器件放在远离模拟信号线的位置。这些在原理图上看不出来只有物理装起来跑数据才能体会。3. 软件框架主循环、定时中断与三张“任务表”3.1 任务规划10ms、100ms、500ms分别该干什么硬件稳定之后软件框架就变成了核心工作。很多初学者习惯用delay()写顺序程序读完PM2.5等500ms再读甲醛再刷新屏幕。这套逻辑在只有一个传感器时没问题但多个传感器一多等待时间互相叠加系统实时性就崩了。我的做法是基于定时器中断的任务调度结构。主循环只检查各个任务标志位定时器每10ms产生一次中断在中断里对时间计数到对应时刻置位对应标志位。任务周期说明传感器数据采集100ms读PM2.5串口数据读甲醛ADC读温湿度数据滤波处理200ms对原始数据做滑动平均屏幕刷新500ms只在数据变化明显时才重绘报警判断1s对比阈值控制蜂鸣器和继电器按键扫描20ms检测切换显示页面核心代码结构大概是这样的思路volatile uint16_t tick_10ms; void TIM2_IRQHandler(void) { tick_10ms; if (tick_10ms % 10 0) flag_100ms 1; // 100ms if (tick_10ms % 20 0) flag_200ms 1; // 200ms if (tick_10ms % 50 0) flag_500ms 1; // 500ms if (tick_10ms % 100 0) flag_1s 1; // 1s } int main(void) { while (1) { if (flag_100ms) { flag_100ms 0; read_pm25(); read_hcho(); read_temp_humi(); } if (flag_200ms) { flag_200ms 0; filter_all_sensors(); } if (flag_500ms) { flag_500ms 0; update_display(); } if (flag_1s) { flag_1s 0; check_alarm(); } } }这样设计的好处是任何任务都不会长时间阻塞主循环哪怕某个传感器偶尔卡住也不影响其他任务运转。我在实际调试中把“任务周期”做成了一张表贴在工位上每次改动软件都要对照表格检查时序非常管用。3.2 PM2.5串口解析与滑动平均滤波PM2.5激光模组通常按固定协议通过串口发送数据帧比如以0x42 0x4D开头后面是数据长度、PM2.5浓度、校验码。解析思路很简单不断在串口中断里收字节找到帧头后按长度接收完整帧再做校验。uint8_t rx_buffer[32]; uint8_t rx_index 0; void USART1_IRQHandler(void) { uint8_t byte USART_ReceiveData(USART1); if (rx_index 0 byte ! 0x42) return; // 等待帧头 rx_buffer[rx_index] byte; if (rx_index 2 rx_buffer[1] ! 0x4D) { rx_index 0; // 帧头不对重新开始 return; } if (rx_index 32) { rx_index 0; // 校验通过后取出PM2.5浓度值 uint16_t pm25 (rx_buffer[6] 8) | rx_buffer[7]; } }拿到原始浓度之后我并没有直接显示。激光传感器在风扇转动、环境气流变化时单次读数跳动比较大短则几百ms的波动就会让屏幕上的数字跳动得很厉害。我加了滑动平均滤波维护一个长度为10的环形缓冲区每来一个新值就替换最旧的值显示的是所有值的平均值。#define FILTER_SIZE 10 uint16_t filter_buffer[FILTER_SIZE]; uint8_t filter_index 0; uint32_t filter_sum 0; void add_filter_value(uint16_t value) { filter_sum - filter_buffer[filter_index]; filter_buffer[filter_index] value; filter_sum value; filter_index (filter_index 1) % FILTER_SIZE; current_avg filter_sum / FILTER_SIZE; }窗口大小选10是因为它能在“响应速度”和“平滑程度”之间取得平衡。窗口太大会让数值变化显得迟钝甲醛浓度突然升高时半天看不出变化窗口太小又抑制不了抖动。对于课程设计级别的项目滑动平均足够了没必要上卡尔曼滤波——那个对初学者的调试成本太高。3.3 显示刷新策略与报警阈值设计OLED显示我做了两页第一页显示PM2.5和温湿度第二页显示甲醛和CO2预留位。按键切换页面短按切页长按可以进入阈值设置模式。刷新时有一个细节OLED刷新整屏很慢如果每500ms把全屏重画一次屏幕会闪得厉害。我改成“只在数值发生明显变化时才更新对应区域”比如PM2.5数值变化超过1才重画否则保持原样。这样看起来流畅也减少I2C总线负担。报警阈值这块我参考的是常见的空气质量分级标准但根据自己的需求做了一点调整参数注意阈值报警阈值说明PM2.575 ug/m³150 ug/m³超过75建议敏感人群注意超过150触发报警甲醛0.08 mg/m³0.15 mg/m³超过0.1建议开窗通风温度18℃ / 28℃——过低过高都提示湿度40% / 70%——超出区间提示报警要做去抖不能在阈值边界频繁响。我的策略是只有在连续3次报警判断都超限时才真正触发蜂鸣器避免传感器数据在阈值附近抖动导致蜂鸣器响一下停一下。4. 标定与实测没有交叉验证的数据都是猜测4.1 和标准仪器同室对比才发现偏差有多大软件跑通之后我满以为屏幕上显示的数字就是“真实空气质量”了。直到借来一台经过校准的标准监测仪器跟我的设备放在同一个房间里做了半天对比测试数据一摆出来我才意识到自己的想法有多天真。我当时测出来的几组PM2.5数据是这样的时间段我的设备读数ug/m³标准仪器读数ug/m³偏差上午10:003245-13上午11:004155-14下午14:00128135-7下午16:00189195-6明显的规律是浓度越低绝对偏差越大浓度越高读数越接近。这种现象跟激光传感器的检测原理有关。低浓度时散射光信号本身就很弱信噪比低模组内部的零点漂移就会体现为明显的读数偏移。甲醛传感器更是如此。电化学传感器刚上电的头几个小时输出会有一段漂移过程直接拿初值当环境浓度数据完全没法看。我当时犯的错是传感器上电两分钟就开始记录数据结果头一个小时的数据全部作废。标定带来的收获不是“把数值调准了”而是让我建立了一个清醒的认知任何传感器读到的都是“信号”不是“事实”。信号只有经过标定、校准、补偿之后才谈得上接近事实。4.2 线性校准与湿度补偿的实操方法标定的操作方法没有想象中复杂。以PM2.5为例我在不同污染条件下同时记录设备读数和标准仪器读数得到一组散点然后用线性回归拟合一阶方程真实值 斜率 × 设备读数 截距比如某次拟合出来的是真实PM2.5 1.13 × 设备读数 - 4.2用法很简单在软件里把传感器原始读数经过这个公式变换再送去滤波和显示。校准参数我存在单片机的Flash里方便以后重新标定时修改。甲醛传感器的补偿要麻烦一点。电化学传感器的输出受温度影响比较明显温度每变化1℃零点可能偏移不少。我采用的方法是在常温下标定零点然后记录不同温度下的零点偏移量做成一张查找表运行时根据当前温度做线性插值补偿。温湿度传感器在这里又派上了用场——它不只是一个显示参数更是其他传感器的补偿依据。这里有个很实际的经验不要指望别人的设备能直接生产一套校准参数发给你。每台设备的传感器个体差异、老化程度、安装位置都不一样只靠所谓“出厂校准”是不够的。我后来做的每台样机都会在装箱之前单独跑一次标定流程虽然麻烦但至少数据来源是可信的。5. 调试实录三个让我通宵的故障及根因5.1 传感器放进外壳后数值越测越离谱第一版样机是裸板数据看着还算正常。装进外壳之后PM2.5数值开始缓慢爬升哪怕是在净化器开了很久的房间里读数也居高不下。我以为传感器坏了拔出来裸放数据又恢复正常。排查之后发现问题出在“热对流”上。单片机、稳压芯片、传感器工作时的发热在狭小封闭的外壳里形成热气流。热空气上升冷空气从底部补充这种气流会把外壳里沉积的微尘搅动起来激光传感器看到的就不再是房间的真实浓度而是“局部扬尘浓度”。解决方法是外壳在传感器安装位置附近开通风孔并且加了一个小导流罩让进气口直接朝向房间主流空气方向而不是朝向电路板。另外把PM2.5模组的位置抬高跟发热源隔开一段距离。做完这些读数在密封外壳和裸板状态下基本一致了。这也解释了为什么市面上很多桌面空气质量监测仪明明是同一个传感器方案不同品牌的数值却差异巨大——外壳设计对气流的影响有时候比传感器本身的精度误差更严重。5.2 继电器吸合瞬间单片机重启这个故障花了我最长的时间。现象是当系统检测到PM2.5超标继电器闭合去控制净化器时整个设备瞬间重启。一开始我怀疑是代码问题以为是继电器控制函数里有什么死循环结果反复查看代码没发现任何异常。用示波器直接量3.3V电源线后发现继电器吸合的瞬间3.3V上出现了一个明显的负向脉冲持续时间大约几十毫秒直接把单片机电源拉到复位阈值以下。根本原因是反电动势和电流尖峰。继电器的线圈是感性负载断电瞬间会产生反向电压吸合瞬间的浪涌电流又很大两个因素叠加通过共用的电源线传导到单片机侧就把单片机干掉了。解决方法分三层硬件上继电器线圈两端并联续流二极管注意方向反向并联吸收反电动势继电器模块用光耦隔离让单片机信号和继电器驱动信号在电气上完全分隔继电器电源单独一路不跟主板共地供电。软件上继电器动作之前先停掉串口和ADC采样等继电器状态稳定后再恢复。这个操作虽然不能根治电源问题但能避免误动作被当成有效数据。验证方法用示波器同时检测3.3V和复位引脚确认复位信号与继电器动作在时间上高度相关。定位到这种确定性关联后问题就好解决了。5.3 WiFi模块一透传ADC读数就开始跳第三个坑是加装联网模块时踩的。WiFi模块只要开始连接网络、透传数据传感器采集到的ADC数值就明显波动。一开始以为是软件处理不过来后来发现WiFi模块发射瞬间电流可以达到300mA甚至更高这么大的脉冲电流会造成电源轨的瞬间跌落和噪声而ADC对电源噪声极其敏感。解决路径类似电源问题给WiFi模块单独供电它的电源线不要跟传感器和MCU共用同一条路径同时在ADC参考电压引脚旁边多放几个退耦电容。软件上也做了妥协WiFi发射数据期间暂停ADC采样等发射窗口过去之后再恢复。因为WiFi数据发送是毫秒级的事件对100ms周期的采样来说影响很小但ADC读数的稳定性提升立竿见影。6. 从监控到联网MQTT上报与自动联动的扩展路径6.1 低成本联网方案串口WiFi模块实现MQTT上报做成型之后很多人问能不能把数据发到手机上看。这个扩展并不复杂。我在主控上保留了第二路串口外接一块串口WiFi模块通过MQTT协议把数据上报到物联网平台手机端用现成的App或者网页面板就可以实时查看历史曲线。上报的数据格式我用的是一段轻量JSON{ device: air_monitor_01, pm25: 36.4, temp: 24.2, humi: 52.6, hcho: 0.05, alarm: 0 }主控只需要在定时任务里把这个字符串发给WiFi模块模块负责维持网络连接和MQTT消息发布。如果不想折腾客户端开发直接用物联网平台的默认可视化面板绑定好数据字段就能出曲线图。这一层扩展的价值在于一台设备放在房间里你不能实时蹲在它面前看数据但数据上了云端你就可以在任何地方查看家里的空气质量趋势还能设置手机推送通知。对毕设来说“远程监控”通常能作为加分亮点又不增加太多开发量。6.2 联动净化器滞回控制比简单阈值控制靠谱最后聊一下自动联动。最开始我的联动逻辑很“朴素”PM2.5超过75就开净化器低于75就关。结果净化器在阈值附近反复启停一晚上能开关几十次电机寿命和体验都很难受。后来改成滞回控制PM2.5超过90时开启净化器低于50时关闭。中间这段区间维持当前状态不变。用代码表示大概是if (pm25 90) relay_on(); if (pm25 50) relay_off();这个策略改动很小效果却非常明显。净化器启动次数大幅减少房间空气质量也能维持在一定范围内。类似的控制逻辑同样可以套用到新风机的联动上。还有一个细节我加了“滤网寿命计数器”每累计运转24小时就在固件里增加一个数值提示用户该换滤网了。这种小功能不值钱但能让整个系统从“采集显示工具”变成“有生命周期的设备”用户体验完全不同。做这个项目我最深的体会是室内空气质量监控系统真正难的从来不是单点技术而是怎么把传感器、电源、软件调度、标定校准、控制策略这些环节串成一个可靠的整体。任何一个环节的粗心都会在数据上暴露出来。如果让我给后来者一句建议那就是拿到传感器的第一周别急着写界面、连WiFi先把传感器平放在桌上连续采集三天数据搞清楚它的脾气和漂移规律。后面的开发会顺利得多。 
长河君 · 2026/10/20 8:58:30 · 阅读 1.2k 单片机室内空气质量监控系统：从硬件选型到标定调试全解析
做了这个项目之后我才真正理解“室内空气质量监控”这件事的边界在哪里。一开始我以为不就是把PM2.5传感器、温湿度传感器接到单片机上读个值、显示出来吗真把系统搭起来、让它在房间里连续跑几天之后才发现问题接二连三传感器互相干扰、数值漂移、继电器一吸合单片机就复位、数据跟标准仪器对不上……每一件都在逼着我把方案推翻重来。这篇博文就以“基于单片机的室内空气质量监控系统设计”为主线把我从选型、硬件连接、软件框架、标定实测到调试排障的完整过程写出来。既不绕弯子也不藏着掖着。如果你是正在做课程设计、毕业设计或者想给家里DIY一套空气质量监测设备这篇内容应该能帮你少走不少弯路。我会把用到的主控、传感器选型思路、关键代码片段、踩过的坑和最后的联网扩展方案都摊开讲清楚。1. 方案选型先定传感器再定单片机这个顺序不能反1.1 拆监测需求室内空气到底要盯哪些指标很多人做这类项目喜欢一上来就挑单片机我却建议先想明白一个问题你究竟要监测哪些参数这决定了整个系统的成本、体积和开发难度。最常见的室内空气质量参数有这么几个PM2.5颗粒物浓度大家最关心也是“空气质量”这个词的代表指标。检测原理有红外散射和激光散射两种。激光散射式的模组通常串口直接输出数值精度和稳定性都更好价格也就贵二三十块钱我直接选了激光式的。温湿度温度和相对湿度是基础参数也会影响其他传感器的读数。常见的有DHT11、DHT22这类单总线传感器也有更好的I2C接口传感器。DHT22性价比高精度够用。甲醛装修污染的重头戏。市面上的甲醛传感器多是电化学原理输出模拟电压需要预热和定期校准新手容易在这里翻车。但既然要做“室内空气质量”甲醛还是得有。CO2反映通风状况。靠谱的方案是非分散红外NDIR原理价格比较高。如果预算有限可以暂时不做但扩展接口最好留出来。我记得第一版方案里贪多把五种传感器全塞进去结果光是应对传感器之间的供电和信号干扰就花了两周。后来冷静下来把需求收敛成“PM2.5 温湿度 甲醛”三个核心指标CO2作为二期扩展项目节奏立刻顺畅了很多。这就是典型的“传感器选型决定项目骨架”主控反而好定。1.2 匹配主控资源从外设需求倒推单片机型号定了传感器之后再去数需要的主控资源PM2.5激光模组是串口UART输出占用1路串口温湿度传感器用单总线或I2C占用1个GPIO或I2C接口甲醛传感器是模拟电压输出需要1路ADC显示用OLED走I2C和温湿度传感器可以复用同一路I2C还要预留蜂鸣器、LED、按键的GPIO。数完这些资源主控的选择就清楚了。我做这个项目用的是一颗很常见的Cortex-M3内核单片机具体型号是STM32F103C8T672MHz主频、3路UART、2路ADC、I2C和SPI齐全Flash和RAM也够用关键是资料多、Demo多出了问题不容易卡住。如果你预算更低用51单片机也能做但ADC精度、串口数量、定时器资源都会比较吃紧后续加WiFi模块也很难扩展。显示方案我纠结过LCD1602和OLED。LCD1602虽然便宜但并口占用IO多显示信息量有限OLED0.96寸I2C只需要两根线还能显示中文和简单图形我最终选了OLED。报警部分用有源蜂鸣器最省事IO一拉高就响不需要自己产生频率继电器则选带光耦隔离的模块后面调试时才意识到这个选择有多重要。2. 硬件连接供电、电平与布局里的三个坑2.1 电源树设计为什么传感器一启动就单片机复位这个坑我印象太深了。第一次搭好电路板烧录完程序屏幕刚亮起来还没高兴几秒PM2.5传感器一转起来整个系统就黑屏重启。用万用表量电源发现5V被拉到了4.2V左右3.3V更是抖得不像样。问题出在电源树设计上。PM2.5激光模组内部有个风扇启动瞬间电流可以到几百毫安甲醛传感器需要加热稳压电流也不小蜂鸣器和继电器更是出了名的“电老虎”。如果所有器件都从一个5V稳压输出上取电任何一个大电流动作都会把电源电压拽下去单片机一检测到掉电就复位。我后来把电源分成两路5V输入先经过一个1000uF电解电容稳压再分成两路——一路直接给传感器供电另一路经过LDO降到3.3V单独给单片机、OLED和逻辑电路供电。继电器则干脆用独立电源不跟传感器共用5V。这样即使传感器瞬时电流很大3.3V这路也几乎不受影响。经验总结电源树要看谁是大电流设备谁是对电压敏感的设备敏感设备必须单独一路。所有器件塞在一个稳压器后面是最省事也是最容易翻车的设计。2.2 电平匹配与共地串口乱码和ADC漂移的根源硬件第二个坑是电平匹配。PM2.5激光模组大多是5V逻辑输出而STM32F103的串口引脚是3.3V逻辑。直接把5V信号接到3.3V引脚上短时间不会有问题但长期跑下来容易损伤引脚更常见的是电平不匹配导致数据乱码。解决方法有两种选3.3V供电版本的模组或者在5V输出和单片机RX之间加分压电阻。我图省事换成了3.3V版本模组省掉转换电路。甲醛传感器的模拟输出虽然也是电压信号但输出阻抗不低直接接ADC会造成读数不稳。我在信号线上并联了一个0.1uF电容做滤波并且让ADC采样引脚和模拟地尽量短距离走线。另外一个容易被忽略的是共地所有传感器、单片机、显示屏的GND必须连在一起否则信号线之间的参考电位不一致串口乱码、ADC漂移全来了。2.3 PCB布局的教训传感器不要贴着单片机放如果是手工面包板/洞洞板搭电路位置自由度大但我也吃过亏。第一版把PM2.5模组紧挨着甲醛传感器放结果甲醛数值始终偏高。后来才反应过来PM2.5模组内部的风扇和激光器都是发热源热气流往上蹿正好经过甲醛传感器的进气口导致电化学传感器读数被干扰。PCB布局我总结三条经验传感器尽量放在板子边缘进气口朝外不要被外壳和排线挡住发热器件稳压芯片、主控与传感器之间留出至少1cm以上的距离蜂鸣器和继电器这类会产生电磁干扰的器件放在远离模拟信号线的位置。这些在原理图上看不出来只有物理装起来跑数据才能体会。3. 软件框架主循环、定时中断与三张“任务表”3.1 任务规划10ms、100ms、500ms分别该干什么硬件稳定之后软件框架就变成了核心工作。很多初学者习惯用delay()写顺序程序读完PM2.5等500ms再读甲醛再刷新屏幕。这套逻辑在只有一个传感器时没问题但多个传感器一多等待时间互相叠加系统实时性就崩了。我的做法是基于定时器中断的任务调度结构。主循环只检查各个任务标志位定时器每10ms产生一次中断在中断里对时间计数到对应时刻置位对应标志位。任务周期说明传感器数据采集100ms读PM2.5串口数据读甲醛ADC读温湿度数据滤波处理200ms对原始数据做滑动平均屏幕刷新500ms只在数据变化明显时才重绘报警判断1s对比阈值控制蜂鸣器和继电器按键扫描20ms检测切换显示页面核心代码结构大概是这样的思路volatile uint16_t tick_10ms; void TIM2_IRQHandler(void) { tick_10ms; if (tick_10ms % 10 0) flag_100ms 1; // 100ms if (tick_10ms % 20 0) flag_200ms 1; // 200ms if (tick_10ms % 50 0) flag_500ms 1; // 500ms if (tick_10ms % 100 0) flag_1s 1; // 1s } int main(void) { while (1) { if (flag_100ms) { flag_100ms 0; read_pm25(); read_hcho(); read_temp_humi(); } if (flag_200ms) { flag_200ms 0; filter_all_sensors(); } if (flag_500ms) { flag_500ms 0; update_display(); } if (flag_1s) { flag_1s 0; check_alarm(); } } }这样设计的好处是任何任务都不会长时间阻塞主循环哪怕某个传感器偶尔卡住也不影响其他任务运转。我在实际调试中把“任务周期”做成了一张表贴在工位上每次改动软件都要对照表格检查时序非常管用。3.2 PM2.5串口解析与滑动平均滤波PM2.5激光模组通常按固定协议通过串口发送数据帧比如以0x42 0x4D开头后面是数据长度、PM2.5浓度、校验码。解析思路很简单不断在串口中断里收字节找到帧头后按长度接收完整帧再做校验。uint8_t rx_buffer[32]; uint8_t rx_index 0; void USART1_IRQHandler(void) { uint8_t byte USART_ReceiveData(USART1); if (rx_index 0 byte ! 0x42) return; // 等待帧头 rx_buffer[rx_index] byte; if (rx_index 2 rx_buffer[1] ! 0x4D) { rx_index 0; // 帧头不对重新开始 return; } if (rx_index 32) { rx_index 0; // 校验通过后取出PM2.5浓度值 uint16_t pm25 (rx_buffer[6] 8) | rx_buffer[7]; } }拿到原始浓度之后我并没有直接显示。激光传感器在风扇转动、环境气流变化时单次读数跳动比较大短则几百ms的波动就会让屏幕上的数字跳动得很厉害。我加了滑动平均滤波维护一个长度为10的环形缓冲区每来一个新值就替换最旧的值显示的是所有值的平均值。#define FILTER_SIZE 10 uint16_t filter_buffer[FILTER_SIZE]; uint8_t filter_index 0; uint32_t filter_sum 0; void add_filter_value(uint16_t value) { filter_sum - filter_buffer[filter_index]; filter_buffer[filter_index] value; filter_sum value; filter_index (filter_index 1) % FILTER_SIZE; current_avg filter_sum / FILTER_SIZE; }窗口大小选10是因为它能在“响应速度”和“平滑程度”之间取得平衡。窗口太大会让数值变化显得迟钝甲醛浓度突然升高时半天看不出变化窗口太小又抑制不了抖动。对于课程设计级别的项目滑动平均足够了没必要上卡尔曼滤波——那个对初学者的调试成本太高。3.3 显示刷新策略与报警阈值设计OLED显示我做了两页第一页显示PM2.5和温湿度第二页显示甲醛和CO2预留位。按键切换页面短按切页长按可以进入阈值设置模式。刷新时有一个细节OLED刷新整屏很慢如果每500ms把全屏重画一次屏幕会闪得厉害。我改成“只在数值发生明显变化时才更新对应区域”比如PM2.5数值变化超过1才重画否则保持原样。这样看起来流畅也减少I2C总线负担。报警阈值这块我参考的是常见的空气质量分级标准但根据自己的需求做了一点调整参数注意阈值报警阈值说明PM2.575 ug/m³150 ug/m³超过75建议敏感人群注意超过150触发报警甲醛0.08 mg/m³0.15 mg/m³超过0.1建议开窗通风温度18℃ / 28℃——过低过高都提示湿度40% / 70%——超出区间提示报警要做去抖不能在阈值边界频繁响。我的策略是只有在连续3次报警判断都超限时才真正触发蜂鸣器避免传感器数据在阈值附近抖动导致蜂鸣器响一下停一下。4. 标定与实测没有交叉验证的数据都是猜测4.1 和标准仪器同室对比才发现偏差有多大软件跑通之后我满以为屏幕上显示的数字就是“真实空气质量”了。直到借来一台经过校准的标准监测仪器跟我的设备放在同一个房间里做了半天对比测试数据一摆出来我才意识到自己的想法有多天真。我当时测出来的几组PM2.5数据是这样的时间段我的设备读数ug/m³标准仪器读数ug/m³偏差上午10:003245-13上午11:004155-14下午14:00128135-7下午16:00189195-6明显的规律是浓度越低绝对偏差越大浓度越高读数越接近。这种现象跟激光传感器的检测原理有关。低浓度时散射光信号本身就很弱信噪比低模组内部的零点漂移就会体现为明显的读数偏移。甲醛传感器更是如此。电化学传感器刚上电的头几个小时输出会有一段漂移过程直接拿初值当环境浓度数据完全没法看。我当时犯的错是传感器上电两分钟就开始记录数据结果头一个小时的数据全部作废。标定带来的收获不是“把数值调准了”而是让我建立了一个清醒的认知任何传感器读到的都是“信号”不是“事实”。信号只有经过标定、校准、补偿之后才谈得上接近事实。4.2 线性校准与湿度补偿的实操方法标定的操作方法没有想象中复杂。以PM2.5为例我在不同污染条件下同时记录设备读数和标准仪器读数得到一组散点然后用线性回归拟合一阶方程真实值 斜率 × 设备读数 截距比如某次拟合出来的是真实PM2.5 1.13 × 设备读数 - 4.2用法很简单在软件里把传感器原始读数经过这个公式变换再送去滤波和显示。校准参数我存在单片机的Flash里方便以后重新标定时修改。甲醛传感器的补偿要麻烦一点。电化学传感器的输出受温度影响比较明显温度每变化1℃零点可能偏移不少。我采用的方法是在常温下标定零点然后记录不同温度下的零点偏移量做成一张查找表运行时根据当前温度做线性插值补偿。温湿度传感器在这里又派上了用场——它不只是一个显示参数更是其他传感器的补偿依据。这里有个很实际的经验不要指望别人的设备能直接生产一套校准参数发给你。每台设备的传感器个体差异、老化程度、安装位置都不一样只靠所谓“出厂校准”是不够的。我后来做的每台样机都会在装箱之前单独跑一次标定流程虽然麻烦但至少数据来源是可信的。5. 调试实录三个让我通宵的故障及根因5.1 传感器放进外壳后数值越测越离谱第一版样机是裸板数据看着还算正常。装进外壳之后PM2.5数值开始缓慢爬升哪怕是在净化器开了很久的房间里读数也居高不下。我以为传感器坏了拔出来裸放数据又恢复正常。排查之后发现问题出在“热对流”上。单片机、稳压芯片、传感器工作时的发热在狭小封闭的外壳里形成热气流。热空气上升冷空气从底部补充这种气流会把外壳里沉积的微尘搅动起来激光传感器看到的就不再是房间的真实浓度而是“局部扬尘浓度”。解决方法是外壳在传感器安装位置附近开通风孔并且加了一个小导流罩让进气口直接朝向房间主流空气方向而不是朝向电路板。另外把PM2.5模组的位置抬高跟发热源隔开一段距离。做完这些读数在密封外壳和裸板状态下基本一致了。这也解释了为什么市面上很多桌面空气质量监测仪明明是同一个传感器方案不同品牌的数值却差异巨大——外壳设计对气流的影响有时候比传感器本身的精度误差更严重。5.2 继电器吸合瞬间单片机重启这个故障花了我最长的时间。现象是当系统检测到PM2.5超标继电器闭合去控制净化器时整个设备瞬间重启。一开始我怀疑是代码问题以为是继电器控制函数里有什么死循环结果反复查看代码没发现任何异常。用示波器直接量3.3V电源线后发现继电器吸合的瞬间3.3V上出现了一个明显的负向脉冲持续时间大约几十毫秒直接把单片机电源拉到复位阈值以下。根本原因是反电动势和电流尖峰。继电器的线圈是感性负载断电瞬间会产生反向电压吸合瞬间的浪涌电流又很大两个因素叠加通过共用的电源线传导到单片机侧就把单片机干掉了。解决方法分三层硬件上继电器线圈两端并联续流二极管注意方向反向并联吸收反电动势继电器模块用光耦隔离让单片机信号和继电器驱动信号在电气上完全分隔继电器电源单独一路不跟主板共地供电。软件上继电器动作之前先停掉串口和ADC采样等继电器状态稳定后再恢复。这个操作虽然不能根治电源问题但能避免误动作被当成有效数据。验证方法用示波器同时检测3.3V和复位引脚确认复位信号与继电器动作在时间上高度相关。定位到这种确定性关联后问题就好解决了。5.3 WiFi模块一透传ADC读数就开始跳第三个坑是加装联网模块时踩的。WiFi模块只要开始连接网络、透传数据传感器采集到的ADC数值就明显波动。一开始以为是软件处理不过来后来发现WiFi模块发射瞬间电流可以达到300mA甚至更高这么大的脉冲电流会造成电源轨的瞬间跌落和噪声而ADC对电源噪声极其敏感。解决路径类似电源问题给WiFi模块单独供电它的电源线不要跟传感器和MCU共用同一条路径同时在ADC参考电压引脚旁边多放几个退耦电容。软件上也做了妥协WiFi发射数据期间暂停ADC采样等发射窗口过去之后再恢复。因为WiFi数据发送是毫秒级的事件对100ms周期的采样来说影响很小但ADC读数的稳定性提升立竿见影。6. 从监控到联网MQTT上报与自动联动的扩展路径6.1 低成本联网方案串口WiFi模块实现MQTT上报做成型之后很多人问能不能把数据发到手机上看。这个扩展并不复杂。我在主控上保留了第二路串口外接一块串口WiFi模块通过MQTT协议把数据上报到物联网平台手机端用现成的App或者网页面板就可以实时查看历史曲线。上报的数据格式我用的是一段轻量JSON{ device: air_monitor_01, pm25: 36.4, temp: 24.2, humi: 52.6, hcho: 0.05, alarm: 0 }主控只需要在定时任务里把这个字符串发给WiFi模块模块负责维持网络连接和MQTT消息发布。如果不想折腾客户端开发直接用物联网平台的默认可视化面板绑定好数据字段就能出曲线图。这一层扩展的价值在于一台设备放在房间里你不能实时蹲在它面前看数据但数据上了云端你就可以在任何地方查看家里的空气质量趋势还能设置手机推送通知。对毕设来说“远程监控”通常能作为加分亮点又不增加太多开发量。6.2 联动净化器滞回控制比简单阈值控制靠谱最后聊一下自动联动。最开始我的联动逻辑很“朴素”PM2.5超过75就开净化器低于75就关。结果净化器在阈值附近反复启停一晚上能开关几十次电机寿命和体验都很难受。后来改成滞回控制PM2.5超过90时开启净化器低于50时关闭。中间这段区间维持当前状态不变。用代码表示大概是if (pm25 90) relay_on(); if (pm25 50) relay_off();这个策略改动很小效果却非常明显。净化器启动次数大幅减少房间空气质量也能维持在一定范围内。类似的控制逻辑同样可以套用到新风机的联动上。还有一个细节我加了“滤网寿命计数器”每累计运转24小时就在固件里增加一个数值提示用户该换滤网了。这种小功能不值钱但能让整个系统从“采集显示工具”变成“有生命周期的设备”用户体验完全不同。做这个项目我最深的体会是室内空气质量监控系统真正难的从来不是单点技术而是怎么把传感器、电源、软件调度、标定校准、控制策略这些环节串成一个可靠的整体。任何一个环节的粗心都会在数据上暴露出来。如果让我给后来者一句建议那就是拿到传感器的第一周别急着写界面、连WiFi先把传感器平放在桌上连续采集三天数据搞清楚它的脾气和漂移规律。后面的开发会顺利得多。