简介面向单片机/嵌入式方向的课程设计或毕业设计这份「室内空气质量监测系统的设计与研究」资料包完整实现了基于单片机对室内甲烷、甲醛、PM2.5浓度的采集、处理与显示。方案涵盖原理图设计、Proteus仿真和Keil C程序支持数据本地显示与无线传输扩展既适合初学者通过仿真快速理解系统框架也可供开发者作为项目原型参考。压缩包共61个文件类型包括C语言源码、Proteus设计文件、原理图文档及其PDF预览、Hex烧录文件以及Keil工程配置等覆盖从硬件原理到软件烧录的完整设计链路。整体仅455KB文件分类清晰便于按需提取。已有112人学习。借助仿真工程和烧录文件可快速验证甲烷、甲醛、PM2.5检测逻辑原理图文档和PDF则能辅助电路分析降低实物搭建门槛。整体上既是一份可直接运行的参考设计也是一套值得拆解学习的教学样例。1. 室内空气质量监测系统不是买几个传感器就能上线的室内空气质量监测系统的设计与研究很多人一开始都误以为它等于“买几个传感器、接上开发板、屏幕上能跳数字”。等真把设备连起来跑一周就会发现能显示不等于能监测更不等于能做研究。数据漂移、部署位置影响、通信断档、缺乏校准任何一个环节出问题整个系统就退化成一件会闪灯的摆设。这篇文章要讲的是一个能真正用起来、数据可信、可以复现的完整方案覆盖传感器选型、单节点采集、MQTT上传、数据落库、可视化看板和现场校准六段链路。适合正在做课程设计或课题研究的学生也适合想给家里或办公室搭一套长期监测系统的开发者照着做能把误差来源逐个找到而不是停留在“能出数”的阶段。2. 传感器选型与单节点硬件先定测量链路再谈系统架构2.1 测量目标决定传感器选型从PM2.5到TVOC的取舍室内空气质量监测的常见误区是“参数越多越好”于是一上来就买一堆传感器最后发现有些数据根本解释不了。我一般会先问一个问题这套系统主要回答什么。如果是评估室内通风状况CO2和PM2.5是核心如果是关注装修污染甲醛或者TVOC必须纳入如果只是做温湿度舒适度研究那连颗粒物传感器都可以省。测量目标决定测量链路链路决定预算和复杂度。检测参数常见检测原理典型量程寿命参考主要坑点PM2.5/PM10激光散射0~1000 µg/m³2~3年气流直吹、凝露、激光器预热CO2NDIR非色散红外400~5000 ppm5~8年自动校准算法在室内会拉偏基线TVOCMOX半导体0~60000 ppb3~5年交叉敏感、温漂严重只能做趋势甲醛电化学0~2 ppm1~2年寿命短长期监测慎选温湿度电容式数字探头常见-40~125℃3~5年探头遮挡导致响应变慢PM2.5传感器几乎都在用激光散射原理输出的是质量浓度估算值不是称重结果所以它天然存在±10%到±20%的误差。CO2传感器要选NDIR原理的电化学CO2传感器在室内环境下寿命和稳定性都差很多。TVOC传感器最特殊它的输出是等效电阻经算法换算出来的指数不是严谨的浓度值因此我只会把它用于变化趋势判断从不当绝对浓度用。选型还有一个容易忽略的点输出接口。优先选串口UART输出、自带标准协议的传感器I2C接口虽然接线省但后续扩展多个传感器时地址冲突很麻烦。串口传感器每个设备一条数据线逻辑清晰出了问题也好定位。2.2 单节点硬件接线与串口数据的第一个代码主控的选择上做原型和课题验证我推荐带WiFi和蓝牙的集成方案这样省去外接通信模块的调试成本开发效率高。如果做产品化或者对功耗有严格要求的场景再用独立主控加低功耗通信模块的组合。电源方面注意两点传感器工作电流叠加后可能达到几百毫安USB供电经常撑不住颗粒物传感器内部有风扇供电电压跌落会让读数严重偏低。以常见的激光颗粒物传感器为例它的接口一般只有四根线VCC、GND、SET、TX。SET引脚用于控制工作模式TX接主控的RX。代码里要处理的第一个问题是数据帧同步和校验不能拿到什么读什么。#include SoftwareSerial.h // 传感器TX接GPIO16GND共地部分型号SET引脚需拉高启动 SoftwareSerial pms(16, 17); // 标准数据帧0x42 0x4D 开头长度字段为0x0014末尾两个字节是校验和 uint8_t frame[32]; void setup() { Serial.begin(115200); pms.begin(9600); // 激光颗粒物传感器默认波特率8N1 delay(5000); // 预热内部激光器和风扇稳定后再开始采样 } void loop() { if (readPmsFrame(frame)) { uint16_t pm25 (frame[6] 8) | frame[7]; uint16_t pm10 (frame[8] 8) | frame[9]; Serial.printf(PM2.5%d ug/m3 PM10%d ug/m3\n, pm25, pm10); } delay(1000); } bool readPmsFrame(uint8_t* buf) { if (pms.available() 32) return false; // 帧头同步读到0x42后确认下一个字节是0x4D while (pms.available()) { if (pms.read() ! 0x42) continue; if (pms.read() ! 0x4D) break; } for (int i 2; i 32; i) { buf[i] pms.read(); } // 校验和累加从帧头到倒数第三个字节低字节与帧末字节相等 uint8_t sum 0x42 0x4D; for (int i 2; i 30; i) sum buf[i]; if (sum ! buf[30]) return false; return true; }这段代码的核心逻辑是先把数据流“切”成完整的一帧再做校验和验证。PM2.5和PM10浓度的字节位置在帧结构里是固定的分别是第6~7字节和第8~9字节按大端序组合成整数。参数上要注意两点波特率9600是绝大多数激光散射传感器的默认值但也有个别型号是38400以传感器数据手册为准预热时间建议至少5秒实际测试中前几分钟的数据仍可能偏低最好在系统启动后丢弃前5分钟的采样。2.3 多参数节点的接线规划当节点需要同时采集PM2.5、CO2、温湿度时最好把传感器按接口类型分组串口传感器分别接不同的GPIOI2C传感器挂同一条总线但地址不能冲突。我在布置接线时会把供电线和信号线分开走避免电机或继电器启停时干扰串口数据。CO2传感器的加热器瞬时电流比较大如果和颗粒物传感器共用一个稳压模块会导致颗粒物传感器供电瞬间跌落表现为读数周期性跳动。常见做法是为CO2传感器单独配一个低 dropout 稳压通道或者把传感器的使能脚分开控制、错峰上电。3. 数据采集与通信采样时序、滤波与MQTT上云的三个关键点3.1 采样周期怎么定热机时间、均值窗口与突发污染捕捉采样周期设置直接影响数据质量和后续分析结论。传感器本身有一个最小响应周期颗粒物传感器通常每1秒出一帧数据CO2传感器典型响应时间在20秒到2分钟之间。如果系统按1秒周期直接入库CO2的变化曲线会呈现明显阶梯状因为新读数还没跟上环境变化。我一般会做两级处理前端按传感器原始周期读取后端做滑动平均后再入库入库周期统一为1分钟。from collections import deque WINDOW 6 class SlidingAverager: 按窗口长度做均值用于平滑原始采样突刺。 def __init__(self, windowWINDOW): self.buf deque(maxlenwindow) def push(self, value): self.buf.append(value) return sum(self.buf) / len(self.buf) avg SlidingAverager() for raw in [23, 25, 60, 31, 28, 26]: # 60这个突刺被窗口平均后输出不会瞬间跳高 print(round(avg.push(raw), 1))滑动窗口长度是这里的关键参数。WINDOW6 在每5秒获取一次数据的情况下等于30秒平均适合看室内空气质量变化如果窗口开太大比如60个点突发的污染事件比如炒菜、吸烟会被完全抹平这类短时高峰恰恰是室内监测需要捕捉的。还有一个容易忽略的细节传感器热机。激光颗粒物传感器内部激光二极管需要温度稳定冷启动后前5到10分钟读数普遍偏低这时候的数据要么丢弃要么打上“热机中”标记不能混进正常数据集做统计分析。3.2 用MQTT把数据送上统一消息总线单节点系统无所谓通信但室内空气质量监测系统一旦要覆盖多个房间就必须引入统一的消息通道。MQTT是物联网场景里最常见的方案它的消息体积小、支持断线重连、有QoS分级很适合传感器节点通过无线网络上传数据。备选方案是HTTP直接上报但HTTP连接开销大网络抖动时数据容易丢。以MQTT为主、HTTP作为兜底上报通道是比较稳妥的组合。#include WiFi.h #include PubSubClient.h WiFiClient net; PubSubClient mqtt(net); const char* mqttServer 你的broker地址; const int mqttPort 1883; const char* nodeName livingroom; void setup() { WiFi.mode(WIFI_STA); WiFi.begin(你的SSID, 你的密码); while (WiFi.status() ! WL_CONNECTED) { delay(500); } mqtt.setServer(mqttServer, mqttPort); mqtt.setKeepAlive(15); // 缩短保活周期减少半开连接 } void publishMetric(uint16_t pm25, uint16_t pm10, uint16_t co2, float temp, float rh) { if (!mqtt.connected()) { reconnect(); } char payload[128]; snprintf(payload, sizeof(payload), {\node\:\%s\,\pm25\:%u,\pm10\:%u,\co2\:%u,\temp\:%.1f,\rh\:%.1f}, nodeName, pm25, pm10, co2, temp, rh); mqtt.publish(indoor/air/livingroom, payload, false); } void reconnect() { while (!mqtt.connected()) { // 客户端ID必须唯一重复ID会导致broker互踢 if (mqtt.connect(nodeName)) break; delay(3000); } }MQTT负载建议直接用JSON字符串下游解析方便。主题命名上把类型和房间分开比如 indoor/air/livingroom这样可以按房间订阅也可以一次订阅 indoor/air/# 拿全量数据。参数上setKeepAlive(15)是我实测后比较稳的配置太短会增加无效心跳包太长会让路由器NAT表过期后出现半开连接表现为设备在线但消息发不出来。QoS选0就可以环境监测数据本身会有冗余重传反而会堵塞链路。3.3 断线补传别让网络抖动吃掉数据WiFi设备在长时间运行后掉线几乎是必然事件所以系统不能只做实时上报还要做离线缓存。常见做法是设备端维护一个环形缓冲区每次上报失败就把消息存入缓存恢复连接后按时间戳顺序补传。补传消息要带上原始采集时间不能填补传时刻否则数据分析时会并入一段无意义的“假活跃数据”。缓存区大小按节点数量和断线时长估算单节点每分钟一条消息断线一小时就需要60条缓存空间这在内存充足的主控上不是问题。我踩过的坑是补传时一次性把积压数据全部发出导致broker短时压力过大后来改成每秒最多补传10条问题就消失了。4. 数据平台与可视化从本地数据库到实时看板的最小闭环4.1 数据落库SQLite起步留出向时序数据库迁移的口子数据量不大时SQLite是最省事的选择单文件、零运维、支持SQL查询。一套家用监测系统一天大约产生1440条记录一年也就50万条SQLite完全扛得住。我见过有人一上来就部署整套分布式时序集群结果一半时间在维护基础设施而不是分析数据这是典型的过度设计。正确的做法是用SQLite把链路跑通确认数据有价值后再迁移到时序数据库。CREATE TABLE IF NOT EXISTS air_data ( ts INTEGER PRIMARY KEY, -- Unix时间戳单位秒主键天然去重 node TEXT NOT NULL, -- 节点标识如livingroom pm25 REAL NOT NULL, -- 单位 ug/m3 pm10 REAL, -- 单位 ug/m3 co2 INTEGER, -- 单位 ppm tvoc INTEGER, -- 单位 ppb可为空 temp REAL, -- 单位 摄氏度 rh REAL -- 单位 百分比 ); CREATE INDEX IF NOT EXISTS idx_node_ts ON air_data(node, ts);时间戳做整型主键有一个直接好处如果MQTT消息因重投导致同一条数据到达两次第二次INSERT会覆盖第一次不会产生重复行。建表时必须把node字段纳入主键或索引否则多节点数据写入后按房间查询会全表扫描。索引的代价是写入稍慢但对这个量级可以忽略。实际项目里我还会加一个 raw_data 表存未经滤波的原始读数方便回溯排查传感器故障只是这个表不需要长期保留定期清理即可。4.2 一个可复现的实时看板Flask接口与Web图表后端接口要解决两个问题查询最新状态和查询历史趋势。用轻量级Web框架提供JSON接口就够了不需要上重型应用框架。接口的典型实现如下from flask import Flask, jsonify import sqlite3 app Flask(__name__) DB air.db app.route(/api/latest/node) def latest(node): 返回指定节点最新一条监测记录。 conn sqlite3.connect(DB) cur conn.execute( SELECT ts, pm25, pm10, co2, temp, rh FROM air_data WHERE node? ORDER BY ts DESC LIMIT 1, (node,) ) row cur.fetchone() conn.close() if row is None: return jsonify({error: no data}), 404 keys [ts, pm25, pm10, co2, temp, rh] return jsonify(dict(zip(keys, row))) app.route(/api/history/node) def history(node): 返回最近6小时的历史数据用于前端绘图。 conn sqlite3.connect(DB) cur conn.execute( SELECT ts, pm25, co2 FROM air_data WHERE node? AND ts? ORDER BY ts ASC, (node, int(time.time()) - 6 * 3600) ) rows cur.fetchall() conn.close() return jsonify([dict(zip([ts, pm25, co2], r)) for r in rows])接口设计上要注意两个细节。第一数据库连接不要跨请求复用SQLite的写锁会因此产生 “database is locked” 错误每次请求独立连接、用完即关最稳妥。第二历史数据一次不要返回太多6小时数据大约360个点前端绘图足够平滑需要更长时间范围时再加时间分段参数避免一次传输几千个点拖慢页面。前端页面用开源图表库画趋势图设置1分钟轮询一次即可5秒轮询对室内环境没有任何意义只会徒增请求量。4.3 告警阈值怎么设才不烦人告警是可视化之后自然要做的功能但阈值设置不当会让系统变成“狼来了”。CO2的告警阈值要区分场景长期有人停留的客厅超过1000 ppm就提示开窗是合理的如果是卧室夜间CO2在800到1200 ppm之间波动属于正常范围低于2000 ppm可以不打扰用户。PM2.5的告警需要加持续时间条件比如连续10分钟超过75 µg/m³才触发单点突刺可能是传感器受气流干扰不必告警。告警消息带上前后半小时的趋势摘要能大幅减少误判。5. 校准与避坑五次翻车记录帮你的监测数据从“能看”到“可信”5.1 现场校准的两种常用做法户外基线法与两点线性修正传感器出厂标定是在标准环境下做的到了实际使用场景温度、湿度、老化都会让读数偏移。室内监测系统最常见的校准方法是户外基线法把设备放到室外自然通风、无遮挡的位置运行半小时记录稳定读数的中位数然后和当地环境监测站点的公开数据对照两者之差就是系统偏差。这个方法的优点是操作简单缺点是无法修正非线性误差所以对精度要求高的场景还要做两点线性修正。# 两个校准点(原始读数值, 参考值) # 第一个点取户外基线传感器读52参考点位30 # 第二个点取室内洁净时段传感器读11参考点位6 points [(52, 30), (11, 6)] (raw1, ref1) points[0] (raw2, ref2) points[1] k (ref2 - ref1) / (raw2 - raw1) # 增益系数 b ref1 - k * raw1 # 偏移量 def calibrate(raw): val k * raw b return max(0.0, val) # 负值无物理意义截断为0 print(calibrate(52)) # 期望输出接近30 print(calibrate(11)) # 期望输出接近6两点线性修正适用于PM2.5这类输出相对线性的传感器。参数上有三个要点校准点的参考值必须是真实可查的数据不能用“感觉空气很好”来拍脑袋校准点之间的跨度越大修正结果越稳两个点都挤在低浓度区间时高浓度的修正误差会被放大TVOC和甲醛传感器不要做这种线性修正它们的敏感机理决定了输出不是严格线性的盲目套公式会把数据修得更离谱。校准后要把增益和偏移量持久化存储并记录校准时间方便事后追溯数据是哪个校准版本产出的。5.2 五条避坑记录每个翻车现场都说清原因和解决办法坑一CO2读数长期稳定在400多仿佛室内空气永远新鲜。现象是设备运行一周后CO2数值始终在400到450 ppm之间波动与人在室内的作息完全无关。原因是很多NDIR CO2传感器内置了自动基线校准算法它假设历史最低值对应户外背景浓度会周期性地把读数基线向420 ppm拉。问题是室内夜间无人时CO2本来就偏低算法把这种场景误判成户外基线导致真实的高浓度读数被压缩。解决办法是关闭自动校准功能改为每两周手动拿到室外通风处做一次基线校准。坑二PM2.5数值大起大落甚至频繁归零。现象是数据曲线像锯齿几分钟内从30跳到80再跳回20偶尔直接变0。排查后发现传感器安装在空调送风口斜下方气流直接冲击采样口PM读数跟随风速剧烈波动归零则是颗粒物传感器在激光器预热不足时对低浓度环境的误判。解决办法是把设备移到远离送风口的位置保持采样口朝下或水平防止灰尘沉积同时把热机阶段的数据标记为无效。坑三TVOC数值每天夜间规律性升高白天反而正常。现象是每天晚上八九点TVOC开始爬升凌晨达到峰值白天又降下来。起初以为是通风问题后来排查发现是房间里有人睡前使用香薰和空气清新剂MOX传感器对醇类、芳香类化合物高度敏感把这些气味全部计入TVOC。解决办法有两个方向热销场景下直接把TVOC当趋势指标而不是浓度指标并且引入温湿度补偿公式如果确实要测真实TVOC换用电化学原理传感器价格会贵几倍。坑四两个节点放在同一个房间数据差了一倍。现象是客厅两个经过相同校准的节点一个读数30另一个读数70持续了一整天。原因检查后才明白一个节点放在靠窗的窗帘褶皱里处于阳光直射区局部温升导致颗粒物传感器内部气流异常另一个放在房间中央茶几上反而是合理的代表位置。本底浓度相同的房间不同位置受人员活动、窗户渗透、热源对流影响局部浓度差异可以非常大。解决办法是统一布点规范离地1.2到1.5米、远离门窗和热源、避开空调送风路径、采样口不要贴近墙面。坑五MQTT经常掉线数据库出现长时段断档。现象是设备白天正常凌晨数据断断续续早上恢复。排查发现家用路由器的WiFi休眠策略在设备空闲时切断了连接而MQTT客户端默认的保活时间较长等到要发数据时才发现连接早已被路由器清理。解决办法是给设备设置静态IP把MQTT keepalive从默认60秒改到15秒同时客户端增加断线重连的指数退避逻辑重连间隔从3秒逐步拉长到60秒避免频繁重连被路由器当作攻击行为。6. 进阶验证用基线对照和数据自洽检查判断系统是否真正可用6.1 数据自洽检查用相关性发现“悄悄坏掉”的传感器校准做完不等于系统永远可靠传感器会在长期运行中缓慢劣化。我习惯每周做一次数据自洽检查通风场景下开窗后PM2.5和CO2应当同步下降室内无人时段CO2应当缓慢下降并趋近室外背景值有人在室内开会时CO2上升趋势应与人员数量正相关。这些规律用肉眼观察曲线就能发现也可以用Pearson相关系数做量化正常节点PM2.5和CO2在通风时段应呈现中等正相关相关性突然消失大概率是其中一个传感器出了问题。6.2 埋点位置与记录习惯复盘时最值钱的东西数据异常时最怕没有现场记录。第一次跑系统时我把设备放在路由器散热风口旁边连续两天的数据显示温度偏高、湿度偏低当时还在怀疑传感器质量问题后来拍了张照片才发现是设备部署位置导致的。从此我养成两个习惯部署每个节点时拍照记录环境和距离所有异常现象随手记到日志文件包括当时的天气、通风行为、人员活动。这套“设备数据部署记录”的组合才是整个监测系统复盘时最值钱的部分很多看似传感器故障的异常最终都指向生活行为和环境干扰。6.3 一个月再校准判断系统能否长期服役校准不是一劳永逸。我一般建议系统运行满一个月后做一次对比测试把设备放到室外基线环境运行1小时与首轮校准的数据对比偏差小于10%说明传感器老化在可控范围继续用偏差超过20%就要检查激光器透镜是否污染、进气口是否堵塞必要时更换传感器模组。记住一个教训分析数据之前先确认数据是怎么来的。希望帮到你。本文还有配套的精品资源点击获取