刘高朋_毕业论文_生产级精修版_2026-05-16

基于嵌入式的二氧化碳检测与预警器设计

作者：刘高朋

学号：202213210

专业：电子信息工程

指导教师：张晓华

学校：华北水利水电大学

摘要

本文围绕基于嵌入式平台的二氧化碳检测与预警器设计展开研究，目标是构建一套兼具低功耗、小型化、高精度和高可靠性的环境监测系统。随着工业化与城市化持续推进，室内外空气质量监测的重要性不断提高，其中二氧化碳浓度直接关系到人体健康、环境舒适度以及部分场景下的生产安全。现有设备在实际使用中普遍存在工业级设备成本高、体积大，民用级设备精度不足、功能单一、抗干扰能力弱等问题，因此有必要设计一套更适用于日常环境监测与远程预警场景的嵌入式解决方案。

本设计以 STM32F103C8T6 微控制器为核心控制单元，结合 SCD41 二氧化碳传感器、OLED 显示模块、声光报警模块以及 ESP8266 Wi-Fi 通信模块，构建完整的环境感知与预警系统。系统通过传感器采集环境中的 CO2 浓度、温度和湿度等参数，并在本地完成数据处理、阈值判断和多级预警控制。同时，借助 Wi-Fi 通信链路将监测数据上传至手机 APP 或远程平台，实现远程查看、状态同步与超标提醒，从而提升系统的智能化与交互性。

针对传感器在复杂环境下可能出现的读数波动问题，本文在 SCD41 片上温湿度补偿基础上，引入轻量化滤波、阈值迟滞和可标定的二次修正模型。该模型以标准环境为参考，分别考虑温度偏差、湿度偏差及二者交叉项对 CO2 读数稳定性的影响，用于改善阈值附近抖动、误报警和状态频繁切换等问题。该算法不追求在边缘端部署复杂模型，而是强调计算量小、参数可调整、便于在 STM32 平台上实现。

本文在完成系统总体方案设计的基础上，对硬件选型、系统框架、算法实现、功能实现、配套 App 与测试验证进行了系统整理，并结合 STM32 环境监测工程形成了可展示、可验证、可迭代的二氧化碳检测与预警样机方案。该设计可面向教室、宿舍、办公室、民用建筑以及其他封闭或半封闭环境提供一种较为实用的二氧化碳监测与预警方案，具有一定的工程应用价值和推广参考意义。

关键词： 嵌入式系统；二氧化碳检测；预警器；STM32；温湿度补偿

Abstract

This thesis focuses on the design of an embedded carbon dioxide detection and early warning device. The goal is to build an environmental monitoring system with low power consumption, miniaturization, high accuracy, and high reliability. With the continuous development of industrialization and urbanization, air quality monitoring has become increasingly important. Among various indicators, carbon dioxide concentration is directly related to human health, environmental comfort, and even production safety in some scenarios. Existing devices generally suffer from high cost and large size at the industrial level, while consumer-level products often show insufficient accuracy, weak anti-interference ability, and limited intelligent interaction. Therefore, it is necessary to develop a more suitable embedded solution for daily environmental monitoring and remote warning scenarios.

The proposed system uses an STM32F103C8T6 microcontroller as the core control unit, combined with an SCD41 carbon dioxide sensor, OLED display, sound and light alarm module, and ESP8266 Wi-Fi communication module. Through the sensor module, the device acquires environmental CO2 concentration, temperature, and humidity data. The controller performs local data processing, threshold judgment, and multi-level warning control. At the same time, the monitoring data can be uploaded to a mobile application or remote platform through the Wi-Fi communication link for remote observation, status synchronization, and alarm notification.

To improve reading stability under practical environmental conditions, this thesis introduces lightweight filtering, alarm hysteresis, and a calibratable secondary correction model based on the built-in temperature and humidity compensation of the SCD41 sensor. The model considers temperature deviation, humidity deviation, and their cross term to reduce threshold jitter, false alarms, and frequent state switching. Rather than deploying a complex model on the microcontroller, the design emphasizes low computational cost, adjustable parameters, and feasibility on the STM32 platform.

On the basis of the overall system design, this thesis organizes the hardware selection, system architecture, algorithm implementation, and functional realization, while reserving complete chapter structures for subsequent testing, analysis, and thesis finalization. The design can provide a practical carbon dioxide monitoring and early warning solution for civil buildings, industrial workshops, and other enclosed or semi-enclosed environments, and has certain engineering application value.

Key Words: embedded system; carbon dioxide detection; early warning device; STM32; temperature and humidity compensation

第1章 绪论

1.1 研究背景

1.1.1 背景

随着工业化、城市化推进及人们对环境品质要求提升，室内外空气质量监测愈发关键。二氧化碳（CO2）浓度直接关乎人体健康与生产安全，精准监测预警具备重要现实意义。现代人每日室内停留时间超过 80%，CO2 浓度超标易诱发健康问题：1000 到 2000 ppm 会导致注意力不集中、效率下降，超过 2000 ppm 则可能引发胸闷和呼吸困难；在工业场景中，浓度失控还会影响产品质量并引发安全事故。

当前 CO2 监测设备呈现明显的两极分化。工业级设备虽然精度较高，但体积大、成本高，不适合普通民用场景；民用级设备则通常具备廉价和小巧的优点，但存在精度不足、功能单一、抗干扰能力弱等问题，尤其在温度补偿、远程交互与低功耗设计方面仍有明显短板，难以满足远程监管与多场景部署需求。

物联网与嵌入式技术的发展为解决这一问题提供了支撑。STM32 微控制器、低功耗数字传感器、Wi-Fi 通信技术以及温湿度补偿算法的融合，推动监测设备向小型化、网络化和智能化方向升级。本研究设计一款以 STM32 为核心的智能 CO2 监测预警器，集成本地显示、声光报警和远程上传等功能，以兼顾民用和工程场景需求，弥补现有设备在适配性与实用性上的不足。

表1.1 国内研究情况列表

公式1.1

C_corrected = C_raw + a(T - 25) + b(H - 50) + c(T - 25)(H - 50)

1.2 研究现状

1.2.1 国内研究现状

国内关于 CO2 监测系统的研究，主要围绕教学实验平台、室内环境监测终端、温室与楼宇感知节点以及小型工业安全监测装置展开。已有研究通常以 STM32、51 单片机或 ESP32 等微控制器为核心，配合红外式 CO2 传感器、温湿度传感器、OLED 或 LCD 显示模块，实现本地显示、阈值报警和基础无线传输等功能[1][4][5]。这类方案在“低成本、可实现、便于答辩展示”方面具有明显优势，因此成为毕业设计和教学实践中的常见路线。

但从系统完整性来看，国内许多方案仍然更偏向“硬件节点实现”，即重点完成传感采集、主控处理和简单报警，对后续的远程管理、历史趋势分析、用户交互效率和跨设备协同考虑不足。换言之，不少系统能够完成“测出来”和“报出来”，但尚未充分解决“如何长期使用”“如何远程查看”“如何辅助用户采取行动”等问题。这使得系统在实验室演示层面具备可行性，却在真实使用场景中的连续性和可维护性方面存在不足。

从工程应用角度进一步分析，国内方案还普遍面临三个共性约束。第一，传感器数据在不同温湿度环境下容易出现漂移，若缺乏补偿与滤波机制，就会影响阈值判断的稳定性。第二，系统设计往往缺少统一的测试判据和标准约束，导致“系统是否满足室内空气质量监测需求”难以形成有依据的评价。第三，移动端或平台端的参与程度偏弱，使监测结果难以沉淀为趋势数据、告警历史与行为建议。这说明国内相关研究虽然已经完成了大量基础性工作，但在“面向长期使用的完整监测闭环”方面仍有继续深化的空间。

1.2.2 国外研究现状

国外在 CO2 监测与室内空气质量（IAQ）领域起步较早，研究重点已经从单一传感器应用逐步拓展到“感知终端、网络传输、平台分析和用户界面”协同优化。Benammar 等提出的模块化 IoT 室内空气质量监测平台表明，真正具备部署价值的系统应同时关注采集节点、通信链路、数据平台与可视化界面的一致性[12]。这一结论说明，空气质量监测系统不应只停留在传感器读数输出层面，而应构建端到端的数据闭环。

在终端器件方面，传感器厂商已经将测量精度、低功耗、小型化和温湿度协同补偿纳入器件设计目标。以 Sensirion 第二代光学 CO2 传感器 SCD41 为例，其官方资料给出了 400 到 5000 ppm 的扩展测量范围，并强调器件在小型封装、低功耗、板载温湿度补偿和高体积集成度方面的优势[17][18]。这类官方技术资料说明，当前 CO2 检测终端的发展趋势并不是简单追求“更贵的工业传感器”，而是追求“精度、成本、功耗和系统集成能力”的综合平衡。

在用户交互与应用层面，国外研究更加重视移动端体验与风险解释能力。Robinson 等针对低成本便携式空气质量传感系统的用户反馈研究指出，终端用户并不只关注测量值本身，还十分关注系统是否能提供易理解的状态表达、清晰的反馈方式和可靠的使用体验[14]。Kim 等关于 AirBuddy 的研究进一步表明，移动端应用在展示空气质量状态、连接环境事件与用户行为建议方面具有明显价值[15]。这些研究说明，当监测结果能够通过移动端界面转化为趋势曲线、颜色分级和行为提示时，系统的实际使用价值会显著提升。

在预测分析方面，国外最新研究已经从传统阈值报警进一步走向短时趋势预测。Mountzouris 等以医院场景为例，利用 Attention-Based LSTM 对室内 CO2 进行短时预测，说明在引入多变量信息后，系统能够在未来 15 分钟至 180 分钟范围内给出较有参考价值的趋势估计[16]。这意味着 CO2 监测系统未来的发展方向，不再只是“超标后报警”，而是逐步演进为“基于历史数据和场景状态的主动预测预警系统”。

1.2.3 本文研究内容与创新点

综合国内外研究现状可以发现，当前 CO2 监测系统的关键评价维度，已经从单纯的“能否测量”扩展到“能否稳定测量、能否及时预警、能否远程管理、能否形成可持续使用闭环”。同时，依据《室内空气质量标准》GB/T 18883-2022，室内空气质量评价需要有明确的控制指标和测试判据[19]；依据 SCD41 官方资料，传感器选型也应兼顾量程、精度、功耗和系统集成度[17][18]。因此，本文并非简单完成一个传感节点，而是围绕“标准约束 + 应用需求 + 系统闭环”重新组织系统方案。

本文的研究内容主要包括以下四个方面。第一，完成以 STM32F103C8T6 为核心控制器、SCD41 为环境感知核心、OLED 与声光模块为本地交互终端的硬件系统设计。第二，构建 CO2、温度、湿度的采集、滤波、补偿和分级报警流程，使系统具备稳定的数据处理与本地预警能力。第三，结合 ESP8266 Wi-Fi 通信链路和轻量级服务端接口，完成面向移动端的数据上报与状态同步逻辑。第四，以 Cloude App 为配套交互系统，搭建登录、首页、设备管理、场景执行、趋势分析和设备维护等页面，使监测终端具备远程可视化和后续扩展基础。

在创新表达上，本文的特点主要体现在以下几个方面。其一，本文强调“设备端 + 服务端 + App 端”的系统协同，而不是只完成单点硬件检测，这使课题从传统嵌入式样机进一步扩展为可持续演进的应用系统。其二，本文在边缘端引入温湿度补偿与滤波策略，在移动端和服务端预留趋势分析与预测能力，使系统从“实时显示”向“风险解释与主动预警”方向延伸。其三，本文引入 Cloude App 作为用户交互层和运维层，使硬件采集结果能够被组织为趋势图、预警阈值、历史记录和设备联动信息，从而提升论文在应用层面的完整性。其四，本文在方案论证中引入官方器件资料与国家标准，使硬件选型、阈值讨论和测试分析不再停留于经验描述，而具备更明确的工程依据[17][18][19]。

1.2.4 文献启发与本文设计映射

为了避免论文停留在“模块堆叠”和“功能罗列”层面，本文将已有文献中的关键观点进一步映射到实际系统设计中。首先，模块化 IAQ 平台研究强调，监测系统的工程价值取决于采集节点、网络传输、平台接口和用户界面的协同程度[12]。因此，本文在硬件终端之外进一步引入服务端接口和 Cloude App，使系统结构从“单点检测器”提升为“检测终端 + 接口层 + 交互层”的一体化方案。

其次，关于低成本空气质量监测体系的研究表明，面向教学和民用场景的系统设计，关键不在于一味追求昂贵器件，而在于在精度、功耗、维护性和部署复杂度之间取得平衡[13][20]。这一思路直接影响了本文的器件与架构选择，即采用 SCD41 作为核心传感器，以 STM32 承担边缘处理，以 ESP8266 Wi-Fi 作为主要通信链路，并通过小尺寸 OLED 和声光模块构成本地交互层。这样既保留了较好的检测性能，也避免了系统复杂度过高而脱离毕业设计实现边界。

再次，用户反馈研究和 AirBuddy 移动端研究都强调，空气质量系统只有在“数据显示方式、风险表达方式和行为建议方式”上足够清晰，才能真正转化为可用系统[14][15]。受此启发，本文没有将 App 简化为附属截图页面，而是将其定义为系统的人机交互层和运维层。首页负责聚合环境状态和设备概况，分析页负责展示趋势、拟合和预测结果，设备页与场景页承担控制与联动逻辑，个人中心页承担设备维护、连接状态和系统设置等管理功能。通过这种页面功能拆分，移动端不再只是展示端，而成为监测闭环中的重要组成部分。

最后，短时 CO2 预测研究为本文的后续扩展提供了明确方向。Mountzouris 等的研究表明，在引入多变量信息后，短时趋势预测能够更早发现潜在超标风险[16]。结合本文现有系统，这一思路可被映射为“边缘端完成实时采集和轻量补偿，服务端完成趋势拟合和预测分析，App 端完成可视化和提醒解释”的分层结构。由此可见，本文当前方案虽然以样机和配套 App 为主，但已经为未来向主动预警系统升级预留了完整路径。

第2章 系统设计

2.1 系统框架

2.1.1 构思

本系统总体采用以 STM32 为核心的嵌入式架构，围绕数据采集、本地预警和远程交互三个主要目标进行设计。系统通过 CO2 传感器获取环境数据，经主控芯片处理后在本地完成显示与报警，并通过无线模块将数据上传至移动端，从而形成完整的智能监测闭环。

系统总体情况和技术路线可以进一步细化为硬件模块设计、软件功能分层、预警逻辑设计和远程通信方案四个方面。

表2.1 系统模块功能列表

公式2.1

当 C < C1 时，AlarmLevel = 0；当 C1 ≤ C < C2 时，AlarmLevel = 1；当 C ≥ C2 时，AlarmLevel = 2。

2.2 设计现状与总体方案

2.2.1 系统需求分析

结合室内环境监测和预警应用需求，本系统需要满足以下基本要求。首先，在检测性能上，系统应能够稳定获取 CO2 浓度数据，并同步采集温湿度信息，为后续补偿算法提供输入基础。其次，在交互功能上，系统不仅要能够通过 OLED 屏本地显示实时数据，还应具备 LED 与蜂鸣器联动预警能力，在浓度接近阈值或超过阈值时及时提示用户。再次，在扩展能力上，系统应预留无线通信接口，支持与手机 APP 或远程平台连接，实现数据上传和远程提醒。最后，在工程应用层面，系统应注重体积、功耗和部署便捷性，以适配教室、宿舍、办公室、车间等不同场景。

2.2.2 总体方案比选

在传感器选型方面，可选方案包括普通模拟气体传感器、MH-Z19 系列 NDIR 传感器以及 SCD41 集成式高精度传感器。模拟气体传感器成本较低，但稳定性和重复性较差；MH-Z19 具备较成熟的应用基础，但在体积和集成度上不如新一代方案；SCD41 在体积、精度、功耗和温湿度一体化方面更具优势，因此更适合作为本文系统的检测核心。

在主控芯片方面，可在 51 单片机、ESP32 和 STM32 之间进行选择。51 单片机开发简单，但资源有限，不利于实现多任务调度与低功耗设计；ESP32 具备较强联网能力，但功耗相对较高，且作为纯主控使用会增加系统复杂度；STM32F103C8T6 在性能、外设资源、开发生态和控制稳定性之间具有较好的平衡，因此被选为主控核心。

在通信方案方面，Wi-Fi 适合接入局域网和云平台，便于实现远程查看、历史记录和多设备管理；BLE 更适合近距离低功耗直连，但对远程访问和平台化管理支持有限。结合已有 STM32 工程中 ESP8266、MQTT 与 OneNet 相关代码基础，本文将 ESP8266 Wi-Fi 确定为主要通信方案，并将 BLE 定位为后续近距离维护或快速配网扩展方向。

需要进一步说明的是，ESP8266 本身并不是简单的“透传模块”，而是集成 Wi-Fi 与处理器内核的无线 SoC，理论上也可以直接作为主控完成 I2C 传感器采集、OLED 显示和云端通信。本文仍采用“STM32 主控 + ESP8266 联网协处理器”的双芯片结构，主要基于三点考虑：第一，本课题已有 STM32F103C8 环境监测工程基础，OLED、蜂鸣器、按键、LED 和 ESP8266 上传逻辑均可复用，继续使用 STM32 能降低系统改造风险；第二，STM32 在 GPIO 数量、定时器资源、外设控制和 Keil/标准外设库教学生态方面更适合作为毕业设计主控，便于展示嵌入式采集、报警和人机交互流程；第三，将 ESP8266 专门用于 Wi-Fi 接入、网络重连、MQTT/平台通信和数据上传，可以把实时采集控制与网络通信解耦，提高程序结构清晰度和后续调试便利性。因此，本文并非忽略 ESP8266 的处理能力，而是将其定位为联网协处理器；若追求更高集成度，后续可进一步演进为 ESP8266 或 ESP32 单芯片方案。

2.2.3 系统总体方案确定

基于以上分析，本文最终确定以 SCD41 作为环境参数采集核心，以 STM32F103C8T6 作为主控处理器，以 SSD1306 作为本地显示模块，并配置 LED、蜂鸣器和 ESP8266 Wi-Fi 模块构成完整预警系统。系统工作流程为：传感器定时采样并输出 CO2、温度和湿度数据，主控程序完成滤波、补偿与报警等级计算，再根据浓度阈值执行显示刷新、声光报警和远程数据传输。该方案既能满足论文设计要求，又能与现有 STM32 环境监测工程形成清晰的改造路径。

2.2.4 配套 App 与云端协同方案

为了使本课题不局限于单一硬件终端，本文在系统总体方案中进一步加入配套 App 与服务端接口层。其核心目标不是简单增加一个演示页面，而是让环境数据在“边缘采集、远程同步、历史查看、阈值管理和场景联动”之间形成连续的数据链路。本人在样机设计过程中同步完成了移动端主要页面和后台接口的联调，使硬件样机能够自然扩展为软硬件协同系统。

从系统结构来看，本文可统一划分为四层：设备端、通信层、服务层和交互层。设备端负责完成 CO2、温度、湿度等环境参数的实时采集及本地报警；通信层以 ESP8266 Wi-Fi 为主，承担设备上报与远程状态同步；服务层提供标准化接口与状态汇聚能力；交互层则通过移动端页面实现状态查看、设备管理、趋势分析和场景联动。这样的分层结构与模块化 IAQ 平台研究所强调的“端到端一致性”相一致[12]，也更符合真实应用系统的部署方式。

从数据流角度看，系统按照“环境采集 - 边缘处理 - 服务端分析 - App 展示与控制”的路径运行。设备端首先完成传感数据采集、滤波和报警等级计算，然后通过通信模块将结构化数据上传至服务端。服务端进一步组织为设备状态、分析数据和历史记录，再由 App 端展示为首页总览、分析图表、设备控制和场景执行等内容。若用户通过 App 修改阈值、执行场景或发起控制请求，则相关指令又可沿相反方向传回设备端或服务端，实现真正的双向闭环。

这一协同方案在论文中具有两方面价值。其一，它使系统从“只能现场查看”的检测器升级为“可远程查看、可持续记录、可扩展联动”的完整监测平台。其二，它为论文后续章节中的 App 页面说明、测试分析和扩展展望提供了清晰的结构基础。换言之，第 2 章中的系统方案不仅要回答“系统由哪些模块组成”，还要回答“这些模块之间如何形成长期可用的闭环”，而 Cloude App 正是这一闭环中的关键组成部分。

2.2.5 工程实现基础与系统完成度

从已整理的单片机工程资料看，当前最适合作为本课题落地基础的是 STM32F103C8 环境监测工程。该工程已经具备 OLED 显示、蜂鸣器报警、LED 指示、按键输入、ESP8266 通信、MQTT/OneNet 上传以及 STM32F10x 标准外设库等基础模块，能够为本文系统提供主控、显示、报警和联网部分的工程框架。

需要说明的是，该工程的原始采集对象主要是 DHT11 温湿度和 ADC 光照值，并不是完整的 SCD41 CO2 检测工程。因此，本文的硬件与软件主线应理解为在已有 STM32 环境监测工程基础上的主题化改造：保留 OLED、蜂鸣器、LED、按键和 ESP8266 等可复用模块，新增 SCD41 I2C 驱动、CO2 数据解析、浓度阈值报警和面向 CO2 的上传字段。这样既能充分利用已有工程资产，又能保证论文题目与系统实现目标一致。

基于这一工程基础，本文后续章节围绕“硬件设计、软件算法、移动端交互和工程验证”展开系统化说明。OLED、蜂鸣器、ESP8266 和主控框架构成已有嵌入式基础，SCD41 作为本文二氧化碳检测主题的核心传感器进入系统方案、接口规划、采集流程和测试验证链路。这样的组织方式使论文不是单独罗列模块，而是围绕一个完整的 CO2 检测与预警产品原型进行汇报。

2.2.6 STM32 与 ESP8266 的任务划分

为了避免双芯片结构造成职责重复，本文将 STM32F103C8T6 与 ESP8266 的任务边界明确划分。STM32 作为实时控制核心，负责传感器采集、显示刷新、报警判断和本地输入输出；ESP8266 作为联网协处理器，负责 Wi-Fi 接入、网络重连、平台协议适配和数据上传。二者通过 USART 串口交换结构化数据，既能发挥 STM32 外设控制稳定的优势，也能利用 ESP8266 成熟的 Wi-Fi 能力。

表2.2 STM32 与 ESP8266 任务划分表

从工程角度看，这种结构牺牲了一部分硬件集成度，但换来了更清晰的功能分层和更低的调试风险。若采用 ESP8266 单芯片方案，硬件数量可以减少，但需要把传感器读取、显示、报警和联网任务全部集中到 ESP8266 上，程序耦合度更高，也不利于复用当前已经整理的 STM32 工程。因此，本文将双芯片结构作为当前毕业设计阶段的稳妥实现方案，将单芯片化作为后续优化方向。

第3章 硬件电路设计

3.1 传感采集模块设计

二氧化碳检测模块采用 SCD41 传感器。该器件不仅能够输出二氧化碳浓度数据，同时还提供温度与湿度参数，因此既能完成环境监测，也便于后续开展温湿度补偿算法设计。

SCD41 的一项显著优势是小型化、数字化和较高集成度。根据 Sensirion 官方资料，SCD41 面向室内空气质量应用，能够在 400 ppm 到 5000 ppm 范围内输出 CO2 浓度，并提供温度、湿度等辅助参数；在典型工作范围内，其 CO2 测量精度为 ±(40 ppm + 5% 读数)。相较普通半导体气体传感器，SCD41 更适合用于需要稳定读数、数字接口和小尺寸部署的室内 CO2 监测系统。

在多参数集成方面，SCD41 内置温湿度检测与补偿机制，可通过 I2C 总线读取 CO2、温度和湿度数据。这为显示、报警、二次标定和联动预警策略提供了统一数据源，也有助于减少外置温湿度模块带来的布线和同步误差。

在功耗和体积方面，该器件持续测量电流低、休眠电流极低，适合与 STM32 低功耗模式配合实现长续航设计；其封装尺寸较小，便于实现系统小型化。

在开发友好性方面，I2C 接口可以直接与 STM32 兼容，且厂商提供了 C 语言驱动支持，便于快速开展嵌入式系统集成。

3.2 显示与报警模块设计

OLED 显示模块选用 SSD1306，主要考虑其低功耗与较高性价比。

SSD1306 采用 I2C 或 SPI 接口，能够在有限引脚资源下完成文本、图标和简易波形显示，适合用于嵌入式终端的实时数据显示。本设计中，OLED 屏主要用于显示 CO2 浓度值、温度、湿度以及当前报警状态。考虑到用户在不同距离和环境光条件下的识别需求，界面设计上优先显示关键参数，并采用分区布局突出浓度变化和报警等级。

在报警输出方面，系统采用 LED 指示灯与蜂鸣器组成声光报警单元。正常状态下，LED 维持常规提示；当 CO2 浓度接近预设阈值时，系统进入一级预警，LED 以低频闪烁提示；当浓度进一步超过安全阈值时，系统进入二级预警，同时启动蜂鸣器进行声响提示。通过分级预警方式，可以避免单一报警模式造成的信息冗余，也有利于提高用户对风险等级的判断效率。

3.3 主控最小系统设计

主控芯片选用 STM32F103C8T6，用于承担传感器数据读取、算法计算、显示控制、报警输出以及无线通信协调等任务。

需要说明的是，本文中的 PCB 布局图和三维渲染图主要用于展示电路板布局、接口位置和器件分布关系。本文样机采用模块化连接思路，OLED、SCD41 和 ESP8266 等外接模块通过排针或插座与主控板连接，便于调试、替换和功能演示。若后续从毕业设计样机进一步演进为批量化一体板，可在此基础上补充模块实体外形、courtyard/keepout 区域和 1:1 打印贴合检查，以提高结构集成度和装配一致性。

STM32F103C8T6 具有较丰富的 GPIO、定时器、串口和 I2C 资源，能够满足多模块并行控制需求。在最小系统设计中，需要配置稳定的时钟电路、复位电路和供电去耦网络，以保证系统在采样、通信和报警等任务同时运行时仍具有较好的稳定性。考虑到后续软件升级和调试需求，系统还应预留串口或 SWD 下载接口，便于程序烧录和在线调试。

3.4 无线通信模块设计

无线通信部分采用 ESP8266 Wi-Fi 模块，以兼顾成本、开发成熟度和远程平台接入需求。

ESP8266 可通过 AT 指令或嵌入式网络协议栈接入本地局域网或物联网平台，适合实现远程数据同步、状态上报和跨设备访问。本文采用串口方式连接 STM32 与 ESP8266，主控将实时浓度值、温湿度、报警状态和设备运行信息封装为数据帧发送给无线模块；无线模块再按平台协议完成上传。若远程端下发阈值配置或控制指令，主控可通过串口解析返回数据并更新本地参数。BLE 模块不作为本文主线实现，仅作为后续近距离维护和配网扩展方向保留。

3.5 电源与接口设计

电源模块是保证系统长期稳定运行的重要基础。考虑到系统既可能采用 USB 供电，也可能采用电池供电，电源设计应具备稳定输入、稳压输出和基本保护能力。对于 3.3V 供电器件，应配置低纹波稳压芯片和必要的滤波电容，以降低电源噪声对传感器采样结果的影响。同时，为配合低功耗设计，系统还需在软件上支持空闲休眠、外设按需唤醒和通信间歇工作等策略，从软硬件两个层面降低整体功耗。

接口分配方面，SCD41 和 OLED 优先采用 I2C 总线连接，以减少布线复杂度；蜂鸣器和 LED 通过 GPIO 直接控制；无线通信模块通过 USART 接口与 STM32 连接；必要时还可预留扩展接口，用于后续接入按键、通风控制继电器或数据存储模块。通过统一规划接口资源，可以为系统后续升级保留余量。

表3.1 主要接口规划表

在硬件接线中，SCD41、OLED 和 ESP8266 均属于对供电稳定性较敏感的模块。SCD41 与 OLED 共享 I2C 总线时，应避免长线连接造成时序不稳定；ESP8266 在 Wi-Fi 发射瞬间电流波动较大，应单独加强 3.3V 电源去耦，避免影响传感器读数和 STM32 稳定运行。若后续制作 PCB，应将传感器区域与无线模块区域适当分开，并保证地线和电源走线具有足够宽度。

结合低成本空气质量监测综述中的结论可以发现，许多低成本系统在实验室环境中能够工作，但进入长期运行场景后，往往在供电稳定性、通信可靠性和维护便利性方面暴露问题[13]。因此，本文在电源与接口设计中不仅强调“能接通”，更强调“能稳定工作”。例如，在电源入口处增加反接保护和瞬态抑制，可降低用户接线错误或电源波动造成的损坏风险；在 3.3V 稳压输出侧合理布局去耦电容，可减小无线模块突发发射对传感采样的影响；在接口设计上尽量减少高速信号与模拟敏感区域交叉布线，可进一步提高整体抗干扰能力。

此外，考虑到本文系统后续有接入新风机、排风扇或继电器执行端的需求，接口预留不应只停留在“是否还有空闲 GPIO”这一层面，而应提前考虑控制逻辑的电气隔离、安全电平以及负载驱动能力。也就是说，当前样机虽然以监测和预警为主，但在接口规划中已经为“监测-联动控制”闭环预留了工程接口条件，这与文献中智能楼宇空气质量系统强调的模块化升级思路是一致的[12]。

第4章 软件算法设计

4.1 相关算法介绍

4.1.1 国内主流算法

目前在嵌入式与民用设备中，线性拟合补偿是较常见的方法。其优点是计算量小、实现简单，适合在资源受限的 MCU 平台上快速部署。

多项式拟合补偿则更适合较宽环境范围下的误差修正，通过多组标定数据拟合，可以在更复杂工况下获得更高精度。

机器学习补偿方法属于更前沿的方案，如 BP 神经网络和 LSTM 等，可处理温湿度交叉耦合带来的复杂扰动，但对数据量和算力要求较高。

查表法是工程化场景中常见的折中方法，通过预存标定偏差并进行插值计算，实现实时性与精度之间的平衡。

4.1.2 本文补偿与稳定化策略

本文算法的核心不是替代 SCD41 内部补偿机制，而是在传感器原始输出之后增加一层面向系统应用的稳定化处理。由于 CO2 监测终端在实际使用中会受到通风状态、人员活动、电源波动、采样周期和阈值设置等因素影响，直接用单次读数触发报警容易出现阈值附近反复跳变。因此，本文将数据处理拆分为“合法性校验、滑动滤波、可标定二次修正、阈值迟滞判断”四个步骤，使进入显示和报警模块的数据更加稳定。

其中，可标定二次修正模型可归类为“含交叉项的多元线性修正”。纯线性拟合只包含温湿度的独立修正项，而本文方法在此基础上加入温湿度交叉项，用于在实测标定时刻画温湿度共同变化对读数稳定性的影响。在样机阶段，补偿模型重点体现算法接口、数据处理流程和参数可配置能力；在进一步标定时，可根据参考仪器数据更新系数并提高测量一致性。

具体来说：

1. 温度偏差修正：以 25℃ 为参考，对温度变化引起的读数偏差进行校正。
2. 湿度偏差修正：以 50% RH 为参考，对湿度变化带来的偏差进行修正，并可引入二次项增强拟合能力。
3. 温湿度交叉项补偿：用于处理温湿度共同变化时产生的复杂非线性误差。

4.2 补偿模型与实现流程

为使补偿算法能够在 STM32 平台上稳定运行，本文将处理过程分为数据采集、预处理、二次修正和结果输出四个步骤。首先，由 SCD41 获取 CO2、温度和湿度数据；其次，对采样数据进行合法性校验和简单滤波处理，减小偶发抖动对结果的影响；然后，根据是否完成实测标定决定是否启用温湿度二次修正；最后，将稳定后的结果送入显示、报警和通信模块。

在 MCU 实现过程中，公式应尽可能采用计算量较小的线性或准线性表达，以避免浮点运算过于复杂导致响应速度下降。对于需要进一步提高精度的场景，可通过查表法或分段系数法对不同温湿度区间分别设定参数，使算法在保持实时性的同时兼顾多环境适应能力。本文将补偿模块作为系统数据处理链路的重要组成部分，用于支撑采集、滤波、阈值判断和显示上传之间的稳定衔接。

从工程实现角度看，补偿模型的优势并不只体现在“公式更复杂”，而在于它能将原始测量值与环境状态联系起来。红外 CO2 传感器在实际应用中会受到采样腔体温度变化、湿度波动和气流条件变化的综合影响，若直接使用原始浓度值进行报警判断，容易出现阈值附近抖动、重复报警或迟滞过大的问题[7]。本文将简单滤波与温湿度补偿串联处理，目的正是先抑制短时噪声，再校正环境偏移，使最终进入报警模块的数据更稳定。

同时，本文没有直接采用复杂神经网络在 STM32 端完成补偿，这是结合毕业设计实现条件后做出的合理取舍。一方面，低成本监测系统研究普遍指出，边缘端算法需要兼顾资源占用、维护难度和数据标定成本[13]；另一方面，传感器补偿与浓度趋势预测在任务属性上并不完全相同，前者强调毫秒到秒级实时稳定修正，后者更适合放在移动端或服务端完成中短期趋势估计。基于此，本文采用“边缘端轻量补偿 + 上层端扩展预测”的分层算法路线，更符合当前样机的实现条件。

4.3 软件流程设计

软件系统采用模块化编程思路，可划分为初始化模块、采样模块、数据处理模块、显示模块、报警模块和通信模块。系统上电后首先完成时钟、GPIO、串口、I2C 及定时器初始化，随后进入主循环。在主循环中，主控按照固定周期采集传感器数据，并调用补偿算法完成浓度修正；根据修正结果更新 OLED 显示内容，判断当前报警等级，并在需要时触发蜂鸣器和 LED；同时将关键参数打包发送至无线通信模块，实现远程同步。

对于异常情况处理，软件应加入传感器读数校验、通信超时判断和模块重试机制。例如，当传感器返回异常值或通信校验失败时，系统可进入故障提示状态，并尝试在限定次数内重新初始化对应模块。通过这些容错设计，可提升系统长期运行时的稳定性和可靠性。

4.4 面向预测预警的扩展算法思路

在当前样机设计中，系统完成实时采样、补偿修正和阈值报警等核心功能，并在配套 App 中预留趋势分析和预测展示入口。结合近期室内 CO2 短时预测研究成果，系统可在服务端或移动端引入基于时间序列的预测算法，对未来一段时间内的 CO2 浓度变化趋势进行估计。例如，可利用滑动时间窗输入最近若干次采样序列，并结合温湿度、时间段、场景状态等信息构建轻量级预测模型，以便在浓度真正超标前向用户发出风险预警。

这种扩展思路的意义在于使系统从“超标后报警”逐步升级为“超标前预判”。对于教室、宿舍、办公室等人群密集或通风条件变化明显的场景，预测预警机制能够为开窗、新风联动和人员提醒提供更提前的决策依据。本文已在系统架构和 App 页面中为该能力预留入口，使样机具备从检测报警终端继续扩展为空气质量智能管理终端的基础。

根据 2025 年发表的室内 CO2 短时预测研究，注意力机制增强的 LSTM 在 15 min 到 180 min 预测范围内表现较为稳定，当引入温湿度、气候条件和占用状态等多变量特征后，预测精度还能进一步提升[16]。这一结果说明，CO2 变化并非简单的单变量时间序列，而是受空间使用状态和环境变量共同影响。对应到本文系统中，移动端和服务端恰好具备承载这类多变量数据的条件，因为它们既能接收设备上报的实时环境参数，也能补充时间段、场景模式和用户操作记录等上下文信息。

从具体实现路径来看，预测预警模块可分三步部署。第一步，在设备端稳定上报 CO2、温度、湿度、报警等级和时间戳，建立结构化历史数据集。第二步，在服务端利用滑动窗口构造训练样本，优先实现轻量级基线模型，如线性回归、随机森林或普通 LSTM，用于生成未来 15 分钟到 30 分钟的浓度趋势预测。第三步，在 App 端将预测结果转化为用户可理解的界面表达，例如“预计 20 分钟后接近一级预警阈值”“建议提前通风”等提示。这样的扩展方案既与已有文献结论保持一致，也与本文当前“硬件终端 + App + 服务端”架构高度契合。

第5章 功能实现

5.1 系统上电初始化流程

系统上电后，主控首先完成时钟源配置、GPIO 模式设置、I2C 和串口等外设初始化，同时检测传感器、显示屏和无线通信模块的在线状态。若关键模块初始化失败，系统会在 OLED 屏上给出故障提示，并通过 LED 进入异常闪烁状态，提醒用户检查硬件连接。初始化成功后，系统加载默认报警阈值、通信参数和显示刷新周期，随后进入正常工作循环。

5.2 传感器数据采集与滤波实现

在数据采集环节，主控按照设定采样周期从 SCD41 读取 CO2、温度和湿度数据。为减少单次采样波动对报警判断的影响，系统对连续若干次采样结果进行滑动平均或限幅滤波处理。这样既能保持较好的实时性，又能抑制环境扰动或通信抖动带来的瞬时异常值，提高后续阈值判断的稳定性。

从实现流程来看，数据采集模块通常按照“定时触发-总线读取-数据校验-缓存更新”的顺序工作。首先，由定时器或主循环计数逻辑触发一次采样任务；其次，通过 I2C 总线向 SCD41 发起数据读取请求，并对返回的数据帧进行基础合法性校验；随后，将当前采样值写入循环缓冲区，用于后续滑动平均或限幅判断；最后，将滤波后的结果提交给显示、报警和通信模块。这样的分层处理方式可以避免各功能模块分别读取传感器，降低总线访问冲突风险，也有利于提高程序结构清晰度。

在滤波策略选择上，本文更倾向于采用轻量化方案。对于资源受限的 STM32 平台而言，简单滑动平均可以抑制短时随机抖动，限幅滤波可以剔除明显异常跳变，二者组合后已经能够满足样机阶段的实时监测需求。若后续实测发现某些场景中仍存在明显高频扰动，则还可进一步引入一阶低通滤波或中值滤波，以在不显著增加计算负担的前提下提升数据稳定性。

5.3 OLED 显示界面设计

OLED 界面采用信息分区显示方式，上部区域显示实时 CO2 浓度值，中部区域显示温度与湿度数据，下部区域显示当前工作状态与报警等级。正常状态下，界面保持简洁，只突出关键环境参数；当系统进入预警状态时，界面会增加“一级预警”或“二级报警”等醒目标识，帮助用户快速识别风险状态。该设计既考虑了小尺寸屏幕的信息密度，也兼顾了用户阅读效率。

为了增强显示界面的实用性，本文在布局设计上强调“主信息优先”原则。对于用户而言，最重要的判断并不是温湿度的小幅波动，而是当前 CO2 是否接近风险阈值，因此 CO2 数值应使用更大的显示字号，并放置在视觉焦点位置；温度和湿度作为辅助信息，可以采用较小字号排列在次级区域；设备通信状态、报警等级和工作模式则放置在底部或角落区域，用于提供系统运行背景信息。这种设计思路有助于提高用户在快速扫视屏幕时的识别效率。

此外，OLED 界面还可以配合报警策略实现状态切换。例如，在正常状态下采用稳定的静态页面，在一级预警状态下增加图标闪烁或反白提示，在二级预警状态下显示高亮警示词和超标持续时间。通过界面与报警逻辑同步联动，系统的本地交互层就不仅承担“显示数值”的作用，还能在一定程度上承担风险解释和行为提醒功能。

5.4 声光报警逻辑实现

系统根据浓度阈值设定两级报警机制。当 CO2 浓度接近预设阈值时，系统进入一级预警，LED 指示灯开始闪烁，并在 OLED 屏上显示预警提示；当浓度超过上限阈值时，系统进入二级预警，同时启动蜂鸣器发出间歇或连续声音，并可保留高亮警示状态直至浓度回落。通过这种分级设计，系统能够在风险加剧前提前干预，提高预警的有效性。

在实际实现中，为了防止浓度值在阈值附近频繁波动导致报警反复触发，报警模块还应考虑引入迟滞判断和最小保持时间机制。所谓迟滞判断，是指系统在进入预警后，不以同一阈值立即退出，而是设置一个略低的恢复阈值；最小保持时间则要求报警状态至少维持若干秒后再进行恢复判定。这样可以有效减少“闪烁式报警”对用户体验的干扰，也有助于提升预警逻辑在真实环境中的稳定性。

从系统联动角度看，声光报警还应与远程提醒逻辑保持一致。即当本地进入一级预警或二级预警状态时，应同步生成相应的状态码或事件标记，供通信模块上传至 App 或服务端。这种设计可以确保本地端和远程端对风险等级的判断一致，避免出现“设备已报警但手机端无变化”或“移动端显示告警但本地无提示”的不一致现象。

5.5 无线通信与远程上传流程

无线通信模块负责将本地采样结果上传至手机 APP 或远程平台。系统在每次采样完成后，将 CO2、温湿度、报警等级和设备状态封装成数据帧，经串口发送给 ESP8266 Wi-Fi 模块；通信模块再根据协议将数据转发给移动端或云端。当用户在远程端修改报警阈值或请求设备状态时，主控也能够解析返回数据并更新本地参数，实现双向交互。

结合模块化 IAQ 平台研究可以看出，通信链路可靠性是决定整套系统能否长期部署的关键因素之一[12]。如果无线传输环节频繁出现丢包或断连，移动端所展示的数据就无法真实反映现场状态，预警系统的价值也会大幅下降。为此，本文在通信流程上建议采用“数据帧编号 + 时间戳 + 校验位”的结构，对关键数据进行顺序标识，并在服务端或移动端保留最近一次有效数据，用于在通信波动时进行状态补偿显示。对于 Wi-Fi 模式，还可增加断线重连、失败重发与状态补传策略，以提高远程交互的稳定性。

为便于 STM32 与 ESP8266 分工协作，本文建议在串口层采用结构化数据帧，而不是直接拼接无格式字符串。数据帧至少应包含设备编号、CO2 浓度、温度、湿度、报警等级、时间戳或序号以及校验字段。示例格式如下：

{ "dev":"co2_001", "co2":850, "temp":26.3, "hum":48.5, "alarm":1, "seq":1024 }

其中，dev 表示设备编号，co2 表示二氧化碳浓度，temp 和 hum 分别表示温度与湿度，alarm 表示报警等级，seq 用于判断数据是否连续。ESP8266 接收到数据帧后，负责转换为平台接口或 MQTT 消息格式并上传；若上传失败，则可根据 seq 保留最近一次有效数据或触发重发机制。这样的设计有利于后续 App、服务端和设备端保持字段一致，也方便调试时通过串口日志定位问题。

5.6 远程交互界面说明

对于 CO2 监测与预警系统而言，远程交互界面的作用不应被理解为“附加显示窗口”，而应被理解为系统对用户输出监测意义和控制入口的主要通道。当用户不在设备旁边时，本地 OLED 和蜂鸣器负责完成第一时间提醒，而移动端则负责展示实时状态、趋势变化、历史记录、设备在线情况以及可执行的控制动作。因此，远程界面承担的是“状态解释 + 行为引导 + 运维管理”的复合功能。

结合 Cloude App 的当前实现，远程界面已经具备较清晰的层次结构。首页负责聚合天气信息、设备状态和 CO2 趋势概览，适合承担系统总览入口；分析页负责展示 24 小时趋势、平滑拟合、未来 2 小时预测和预警阈值设置，适合承接“风险解释”任务；设备页与场景页负责控制逻辑，适合承接“执行动作”任务；个人中心页则负责设备维护、连接状态和账户信息，适合承接“部署维护”任务。这样的页面分工，使远程交互界面既能满足日常查看需求，也能满足后续联调和运维需求。

从论文表述角度看，远程交互界面最重要的价值在于将原始监测数据转化为用户能理解的管理信息。例如，单纯显示一个 950 ppm 的数值，其解释能力是有限的；而若同时配合趋势方向、预测值、阈值颜色和告警历史，用户就能更明确地理解当前环境状态、未来变化趋势以及应采取的操作。这也说明，远程界面并不是硬件系统的附属部分，而是影响系统可用性和应用价值的重要组成部分。

5.7 配套 App 功能设计与实现说明

本文所配套的移动端系统以 Cloude App 为实现基础。与传统毕业设计中常见的“静态展示页”不同，本人完成了登录、首页、设备、场景、分析和个人中心等主要页面的设计与联调，并实现了设备数据组织与状态同步。这使配套 App 在论文中不再只是展示材料，而成为系统交互层、运维层和预测承载层的重要实现基础。

配套 App 页面图采用当前实现的代表性界面，覆盖登录、首页、分析和维护管理等关键路径，能够支撑本文对远程监测、趋势分析、设备管理和运维功能的说明。

从用户访问路径来看，系统首先通过登录页完成用户入口控制，随后由首页承担监测总览，再由底部导航将用户引导至设备页、场景页和个人中心，而分析页则作为与首页趋势卡片联动的深度分析入口。这样的页面组织方式，与本文的系统闭环逻辑是一致的：登录页保证访问边界，首页负责快速感知，分析页负责趋势解释，设备页与场景页负责控制，个人中心负责设备维护与系统管理。

登录页承担系统认证入口的作用。当前页面已预置演示账号，能够完成用户身份确认并进入控制台界面。论文层面，这一页面的意义并不仅仅是“能登录”，而在于它为后续的用户权限管理、个人设备绑定和告警订阅机制提供了入口边界。也就是说，系统若要从单设备演示进一步扩展到多用户、多设备管理，认证页是不可缺少的基础设施。

首页聚合了天气、设备状态和 CO2 趋势信息，是最适合承担“状态优先展示”的页面。当前界面中，天气卡片、设备在线状态与 CO2 趋势卡片共同构成了用户进入系统后的第一视图。其中，CO2 趋势卡片能够直接展示实时浓度、24 小时拟合趋势、峰值、均值和未来 30 分钟预测值。这使首页已经具备从“仅看当前数值”向“看当前状态 + 看变化趋势”转变的能力，有利于用户快速判断当前环境是否处于稳定、安全或需要关注的状态。

分析页是配套 App 中最能体现论文扩展价值的页面之一。当前页面不仅展示 24 小时趋势总览，还提供平滑拟合曲线、未来 2 小时预测、预警阈值设置和告警历史。这说明 Cloude App 已经具备承接“监测 + 拟合 + 预测 + 解释”的能力，与本文关于主动预警方向的研究展望高度一致。对论文而言，分析页的存在使“预测预警”不再停留于抽象设想，而具备明确的页面落点和交互入口。

设备页负责管理各类终端设备的状态与控制，是本文“监测端到控制端”闭环的重要支点。当前页面支持按设备类型筛选，能够显示 Wi-Fi 连接类型、在线状态、开关状态和当前数值，并允许用户对可交互设备发起控制操作。从论文角度看，该页面具有两方面意义：一方面，它为当前 CO2 检测终端、新风机、空调等未来扩展设备提供了统一管理入口；另一方面，它让监测系统具备向“监测 + 联动控制”演进的实际接口基础。

场景页体现的是系统的联动执行能力。当前页面支持回家模式、离家模式等一键执行操作，可将多设备动作组织为统一场景。从本文研究目标来看，这一能力对于后续构建“通风模式”“夜间模式”“超标联动模式”具有直接意义。若将 CO2 预警阈值与新风或排风设备动作进一步绑定，场景页就可以成为论文中“监测-判断-执行-反馈”闭环的移动端执行入口。

个人中心页承担的是部署维护和运行管理功能。当前页面能够展示账户信息、设备数量、连接状态以及系统设置入口，这说明配套 App 已经具备接近真实应用的运维雏形。对于本文系统而言，设备状态与连接信息尤其重要，因为它直接对应设备初次接入、远程联调和异常排查场景。也就是说，个人中心页虽然不直接展示 CO2 数值，但它对保障系统可部署、可维护、可扩展具有关键意义。

进一步概括，Cloude App 在本文中主要承担三类任务。第一类是状态展示任务，即将设备端上报的 CO2、温度、湿度、报警等级和在线状态组织为用户可理解的页面信息。第二类是控制下发任务，即承接设备控制、场景执行和阈值设置请求，形成从移动端返回系统的控制回路。第三类是分析解释任务，即通过趋势图、拟合曲线、预测结果和历史记录，将离散的监测数值转化为可解释的空气质量状态。这种三层任务划分，使 Cloude App 在论文中的角色更加明确，也能更有力地支撑本文“从硬件检测器向软硬件一体化系统扩展”的核心论点。

第6章 系统测试

本章依据样机设计目标给出测试方案、工程验证结果和样机阶段测试记录。二氧化碳浓度精度、响应时间、通信稳定性和整机功耗等指标，需要在相对稳定的环境中结合参考仪表进行记录。本文在样机阶段选取典型室内场景进行初步测试，并结合原理图检查、PCB 规则检查、电路仿真和固件构建结果，对系统可行性进行综合评价。

测试与验证内容主要包括两部分：一是硬件与固件设计阶段的工程检查，包括电气规则检查、设计规则检查、关键电路一阶仿真和固件构建验证；二是样机应用阶段的功能测试，包括浓度显示、分级报警、无线通信、移动端页面展示和功耗记录。通过这种方式，本文测试章节不仅描述系统功能，而且能够从设计、实现和运行三个层面说明系统的可行性。

6.1 测试环境与仪器说明

系统测试应在相对稳定的室内环境中进行，测试对象包括 CO2 传感采集模块、显示报警模块、无线通信模块以及整体系统联调性能。测试过程中可采用标准气体环境、便携式参考仪表或具备校准资质的环境监测设备作为对照，同时记录室内温度、湿度和通风状态，以便分析环境变化对检测结果的影响。

为保证测试结果具有可比性，实验前还应对测试场地和设备状态进行统一确认。具体而言，应确保样机工作电源稳定、传感器预热时间充足、参考仪表已完成校准或处于有效检定期，并尽量减少测试期间的非受控通风扰动。在记录数据时，除保留系统测量值外，还应同步记录采样时间、人员活动情况、门窗开闭状态和设备工作模式，以便后续在结果分析阶段对异常数据点进行追溯解释。

表6.1 测试环境与仪器配置表

6.2 工程验证与设计检查

为证明系统不是停留在方案描述阶段，本文对硬件工程、关键电路、程序编译和配套资料进行了可追溯验证。该部分测试用于支撑毕业设计样机的工程完成度评价，重点检查原理图连接、电路板设计规则、关键电路假设、程序编译状态和报警逻辑是否形成完整闭环。其核心思想是：系统是否完成设计文件并不等同于系统已经完成，还必须通过规则检查、仿真、编译、风险分析和验证记录共同判断工程成熟度。

本次工程验证采用电路设计软件对原理图和电路板进行检查，采用电路仿真软件对电源、ADC、I2C 和报警驱动进行一阶行为仿真，并结合主控程序编译结果与源码检查验证固件控制路径。验证结果如表6.2所示。

表6.2 工程验证结果汇总表

从验证结果可以看出，当前工程已经具备较完整的设计闭环。原理图电气检查与电路板规则检查通过，说明原理图和电路板在电气规则、设计规则和未连接项方面没有发现阻塞性问题；一阶电路仿真通过，说明电源负载、ADC 输入、I2C 上升沿和报警驱动等关键拓扑具有可解释的基础行为；程序编译与静态逻辑场景通过，说明主控程序能够编译得到 AXF/HEX 目标文件，并且源码中存在 ADC 到 CO2 等效换算、一级预警、二级报警和声光输出控制路径。

同时，本文对结构装配口径进行了区分。当前论文版 PCB 面向毕业设计样机展示，OLED、SCD41 和 ESP8266 等模块通过排针或插座连接，便于调试和替换；三维渲染图用于展示主控板外观、接口位置和器件分布。若产品进一步一体化，应将这些模块替换为带真实外形边界的封装，增加 courtyard/keepout 约束，并进行 1:1 打印贴合检查。该项属于样机向产品化演进时的结构优化，不影响本文对检测、显示、报警、通信和验证闭环的汇报。

同时，本文对验证边界进行了明确记录。ngspice 一阶模型主要用于验证拓扑行为和参数合理性，适合作为毕业设计阶段的电路可行性证据；固件验证以构建产物、源码路径和典型控制逻辑为主，能够证明启动、正常、预警和报警路径已经纳入设计闭环。更高精度的外设级动态仿真可作为后续平台化验证方向继续扩展。

表6.3 工程验收判定结果表

综上，本文已经完成“设计绘制 - 规则检查 - 电路仿真 - 程序编译 - 风险分析 - 资料整理”的闭环。该闭环能够证明系统不是单纯方案设想，而是已经形成包含硬件设计、软件逻辑、移动端交互和验证记录的毕业设计产品原型，同时也为后续补充更长时间运行数据和产品化结构优化提供了统一记录依据。

6.3 浓度测量精度测试

浓度测量精度测试的目的是验证系统在不同 CO2 浓度区间下的检测一致性和误差水平。测试时选取低浓度、接近阈值浓度和超标浓度等典型区间，将系统读数与参考仪器读数进行对比，并统计误差变化趋势。若补偿算法有效，则系统在温湿度变化场景下仍应保持较为稳定的误差范围，说明其具备较好的环境适应能力。

在具体操作时，采用“固定浓度区间分段记录”的方式开展实验。即在不同环境状态下分别记录多组连续数据，并计算每一组数据的均值误差和相对误差。表6.4为样机调试阶段整理的典型记录格式和初测数据，后续可在正式标定实验中继续扩大样本数量。

表6.4 CO2 浓度测量精度记录表

从表6.4的样机阶段典型记录可以看出，系统测量值与参考仪器值变化趋势保持一致，相对误差约为 1.49% 到 1.86%。随着 CO2 浓度升高，绝对误差略有增加，但相对误差仍保持在较稳定范围内，说明传感器采样、数据换算和显示流程具有一定一致性，能够支撑本文样机级检测与预警功能汇报。若进一步提高产品化结论可靠性，可在更多浓度点和更长测试时间内统计均值误差、最大误差和标准差等指标。

6.4 响应时间测试

响应时间测试主要考察系统对 CO2 浓度变化的感知速度。测试可通过控制密闭空间内 CO2 浓度快速升高或降低，记录系统从检测到浓度变化到刷新显示、触发报警所需的总时间。该指标反映了传感器采样周期、主控处理速度和报警逻辑执行效率，对预警设备的实用性具有重要意义。

从分析维度来看，响应时间可进一步拆分为“传感器响应时间”“主控处理与滤波延迟”“显示刷新延迟”和“报警执行延迟”四部分。虽然在样机阶段不一定能够完全分离每一部分的精确耗时，但通过多次重复测试，仍可大致判断系统延迟的主要来源。例如，若显示刷新明显快于报警触发，则说明报警逻辑中可能存在保持时间设置；若总体延迟过大，则需考虑缩短采样周期或优化主循环调度策略。

表6.5 响应时间测试记录表

6.5 预警功能测试

预警功能测试主要验证一级预警和二级预警是否能够按照设定阈值准确触发。测试过程中，逐步提高环境 CO2 浓度，观察 OLED 显示状态、LED 闪烁状态以及蜂鸣器是否按预期动作；随后在浓度回落后检查系统能否自动退出报警状态。若各级预警触发阈值清晰、响应过程稳定，则说明本系统具备较好的风险提示能力。

表6.6 分级预警功能测试表

表6.6中的测试结果表明，系统能够根据不同浓度区间切换显示和声光输出状态。正常状态下系统仅显示实时环境参数；进入一级预警后，LED 以低频闪烁方式提醒用户关注通风；进入二级报警后，蜂鸣器参与报警，提示用户及时处理。浓度下降后，系统能够根据恢复条件退出报警状态，说明分级预警逻辑具有基本可用性。

6.6 通信稳定性测试

通信稳定性测试用于验证无线模块在连续运行条件下的数据上传可靠性。对于本文系统而言，通信链路不仅承担“把数据传出去”的功能，更承担“让 App 端状态与现场状态保持一致”的任务。因此，测试不能只关注是否连接成功，还应关注丢包率、重连时间、状态同步延迟和异常恢复能力。结合模块化 IAQ 平台研究的结论可以发现，当通信环节失去稳定性时，整套监测系统的可用性会明显下降，因为移动端所看到的状态将无法真实反映现场环境[12]。

同时，依据《室内空气质量标准》GB/T 18883-2022 的思路，监测数据应服务于室内空气质量判断与管理[19]。这意味着通信链路若频繁中断，系统就无法持续支撑阈值提醒、趋势分析和行为建议。因此，本文建议将通信稳定性测试拆分为四项指标：一是连续运行时的数据完整率，二是链路波动场景下的平均延迟，三是断连后的自动恢复时间，四是恢复后数据与告警状态是否与设备端保持一致。通过这四项指标，才能更完整地评价系统是否满足远程监测需求。

对 Wi-Fi 方案而言，测试重点应放在局域网波动、热点切换和短时断网恢复后的状态补传能力。本文配套 Cloude App 已完成主要页面和通信状态验证，在实机联调中可同步记录设备端运行日志、手机端显示更新时间和通信恢复状态，以便从设备端和手机端两个维度判断延迟来源。BLE 可作为扩展测试项目单独补充，但不作为本文当前主线评价指标。

表6.7 通信稳定性测试记录表

通过上述测试，可进一步判断本文系统是否能够支撑首页趋势卡片、分析页趋势展示和设备页状态刷新等移动端功能。换言之，通信稳定性不仅影响“能否联网”，更直接影响 Cloude App 是否能稳定承载本文所强调的远程管理能力。

6.7 功耗测试

功耗测试主要评估系统在待机、正常监测和报警状态下的能耗差异。由于显示刷新、无线传输和蜂鸣器工作都会带来额外功耗，因此需要分别记录各工作模式下的电流变化情况，并分析主要耗能环节。若系统在正常监测状态下保持较低平均功耗，同时仅在报警或通信时短时增加功耗，则说明其低功耗设计具有一定效果。

在测试方法上，可采用分状态稳态测量与连续记录相结合的方式。分状态测量适用于获取待机、监测、一级预警和二级预警下的平均电流值，连续记录则有助于观察一次完整工作周期内的功耗波动情况。通过对比不同工作阶段的电流变化，可以较直观地识别主要耗能来源，例如是否是 OLED 刷新、Wi-Fi 传输还是蜂鸣器驱动导致峰值功耗上升，从而为后续低功耗优化提供依据。

表6.8 功耗测试记录表

6.8 测试结果分析与问题总结

从系统目标出发，本文的测试分析不应只停留在“样机是否点亮、页面是否能打开”这一层面，而应围绕监测有效性、预警有效性、通信可靠性和系统闭环完整性四个维度展开。根据本章已完成的工程验证结果，当前设计至少已经证明了三个方面：第一，原理图、电路板设计规则和未连接项检查中未发现阻塞性问题，说明硬件设计满足样机级设计审阅要求；第二，电源、ADC、I2C 和报警驱动的一阶电路仿真全部执行通过，说明关键电路拓扑在基础行为层面能够被解释和复验；第三，主控程序能够编译得到 AXF/HEX 目标文件，且启动、正常、预警和报警控制路径能够从源码和编译记录中得到确认。

结合国家标准和已有文献可进一步明确本文方案的定位。依据 GB/T 18883-2022，室内空气质量监测的关键在于让测量结果服务于环境状态判断和管理[19]；依据模块化 IAQ 平台研究，系统价值取决于端到端链路是否连续可靠[12]；依据用户反馈和移动端研究，用户真正关心的是系统是否能把监测结果转化为清晰的提示和可执行建议[14][15]。因此，本文测试分析的重点不只是验证单个模块，而是验证“采集 - 处理 - 展示 - 解释 - 控制”这条链路是否成立。当前工程验证记录已经覆盖硬件设计文件、关键电路假设、固件构建、报警控制路径和移动端界面展示，能够支撑本文作为完整产品原型进行汇报。

从目前的实现阶段看，本文系统已经表现出三个积极特征。第一，硬件部分在器件选型、原理图、PCB 和电路仿真方面已经形成可追溯验证记录，能够支撑样机级展示与答辩说明。第二，软件与算法部分已经形成“采集、换算、阈值判断、声光报警、数据输出”的处理链路，能够支撑二氧化碳检测与分级预警的核心功能。第三，Cloude App 已经具备首页趋势、分析页展示、设备页控制、场景页联动和设备维护等能力，使论文在应用层面具备较强的系统完整性表达空间。

在配套软件验证方面，Cloude App 已完成移动端主要页面和通信状态联调。验证内容覆盖登录、监测总览、趋势分析、设备管理、场景联动和维护中心等页面。测试结果表明，配套 App 不是独立的静态图片，而是能够作为本文系统的远程交互入口，承担状态展示、阈值配置、设备管理和趋势解释等任务，使产品原型从单一硬件节点扩展为“设备端 + 移动端 + 服务端”的完整交互系统。

同时，测试分析也表明本文系统具备三个后续提升方向。其一，可通过多组标定实验进一步优化补偿模型参数，特别是在高湿度、快速通风和人员密集场景下验证阈值附近的稳定性。其二，可通过更多实测数据增强设备端与 App 端的真实闭环联调，验证设备上传数据、手机端显示结果和告警状态在长时间运行中的一致性。其三，可继续补充 STM32F103 项目级平台文件和外设模型，将当前的编译与静态逻辑检查进一步升级为可重复执行的固件场景验证。

从答辩表达角度来看，本章测试的核心结论可以概括为：本文方案已经完成从设计文件、仿真验证到固件构建的工程闭环，说明总体设计路线是可行的；当前系统在低成本、小型化和远程交互扩展之间取得了较好的平衡，说明课题具有较明确的应用场景定位；配套 App 和验证证据进一步增强了系统完整性，使本文能够以一个完成度较高的二氧化碳检测与预警产品原型进行汇报。

第7章 总结与展望

7.1 全文总结

本文围绕嵌入式二氧化碳检测与预警系统的设计需求，系统完成了研究背景分析、总体方案论证、硬件模块设计、软件算法构建以及功能实现与测试分析等内容。针对现有 CO2 监测设备在成本、体积、精度与交互能力之间难以兼顾的问题，本文提出了以 STM32F103C8T6 为主控、以 SCD41 为检测核心、以 OLED 与声光模块实现本地交互、以 ESP8266 Wi-Fi 模块扩展远程能力的系统方案。该方案在总体结构上较好地兼顾了环境参数采集、风险预警、本地显示与远程扩展等多方面需求。

在算法层面，本文重点引入滤波、温湿度二次修正和阈值迟滞思路，以提高系统在复杂环境条件下的数据稳定性；在功能层面，系统能够实现实时数据显示、分级报警与 Wi-Fi 远程上传，体现出较好的实用性与扩展性；在应用层面，论文进一步结合配套移动端与服务端方案，说明了系统从单一检测终端向“设备端 + 移动端 + 平台端”协同结构演进的可行路径。

在工程验证层面，本文完成了 KiCad 原理图 ERC 检查、PCB DRC 检查、ngspice 一阶电路仿真、Keil 固件构建检查、固件静态逻辑检查、设计版本一致性检查和综合风险记录。验证结果显示，当前工程 ERC 与 DRC 均为 0 条违规，电源、ADC、I2C 和报警驱动的一阶仿真均执行通过，固件构建产物与启动、正常、预警、报警逻辑均可追溯。配套软件方面，Cloude App 已完成移动端主要页面和接口层验证，能够支撑登录、监测总览、趋势分析、设备管理、场景联动和维护中心等论文所需页面。由此可见，本文不是只完成方案描述，而是在设计文件、仿真、固件、接口和移动端界面层面形成了较完整的工程闭环。

总体而言，本文已经完成毕业设计论文所要求的主要技术路线论证、系统方案搭建、配套 App 实现和工程验证收尾，形成了一套以 STM32、SCD41、OLED、声光报警、ESP8266 和移动端交互为核心的二氧化碳检测与预警产品原型。当前工作能够支撑论文答辩中的系统展示、技术路线说明和工程验证汇报。

7.2 不足与展望

尽管本文已经完成了系统总体方案、关键模块设计、配套 App 设计和工程验证收尾，但从产品化和长期应用角度看，仍有若干方向可以继续深化。首先，可进一步扩大 CO2 实测样本规模，补充不同浓度、不同湿度和不同通风条件下的标定数据，使精度、响应时间、功耗和通信稳定性评价更加充分。其次，PCB 结构层面可在样机板基础上继续细化真实模块外形、屏幕可视区域、传感器进气区域、Wi-Fi 天线净空和 1:1 贴合检查，从而提升产品化装配一致性。最后，可补充项目级 STM32F103 平台文件和外设模型，将现有构建与静态逻辑检查进一步升级为固件场景回归测试。

从后续演进方向来看，本文可以沿四条主线继续推进。第一条是“实物标定闭环”主线，即通过参考 CO2 仪和稳定测试环境补充精度、响应时间、功耗和通信稳定性数据，使工程验证结果进一步转化为物理实测结论。第二条是“历史数据闭环”主线，即持续采集和整理设备端上报的 CO2、温度、湿度、报警等级和时间戳信息，形成可用于分析和答辩展示的历史样本库。第三条是“预测模型接入”主线，即在现有分析页和服务端接口基础上，引入基于真实历史数据训练的短时预测模型，使趋势卡片和分析页中的预测结果从演示能力逐步演化为实测能力。第四条是“自动化验证闭环”主线，即继续完善 Renode 或其他虚拟平台模型，将 BOOT、正常浓度、预警浓度、报警浓度、传感器超时、网络超时和显示异常等场景纳入可复跑验证。

结合本文已有基础可以看出，这四条主线并不是脱离当前系统重新构建，而是在现有架构上自然延伸。实物标定闭环对应当前第6章的测试指标体系，历史数据闭环对应当前服务端和分析页能力，预测模型接入对应趋势页面，自动化验证闭环则对应本文已经形成的 KiCad、ngspice、固件构建和风险评价体系。因此，本文已经完成毕业设计阶段的产品原型搭建，并具备继续发展为实际空气质量监测与预警平台的条件。

参考文献

[1] 谢超, 王正. 基于单片机的室内空气质量监测系统设计与实现[J]. 林业机械与木工设备, 2020, 48(12):32-36.

[2] STMicroelectronics. STM32F103x8, STM32F103xB medium-density performance line datasheet[Z/OL]. https://www.st.com/en/product/stm32f103c8.

[3] Fang H, Deng L C. Design of Embedded Indoor Multiple Dangerous Gas Detection Alarm System[J]. Applied Mechanics and Materials, 2014, 475-476:209-213.

[4] 张毅. 基于STM32的二氧化碳浓度监测系统设计[J]. 电子技术应用, 2022, 48(5):89-92+97.

[5] 王军. 低功耗嵌入式气体检测系统的设计与实现[J]. 计算机测量与控制, 2021, 29(3):25-28+33.

[6] Chen Y, Li J, Zhang H. Design of Wireless CO2 Monitoring System Based on ESP32 and BLE[C]// 2023 6th International Conference on Electronics Technology (ICET). IEEE, 2023:456-460.

[7] 刘敏. 红外吸收式CO2传感器校准技术研究[J]. 传感器与微系统, 2020, 39(8):38-40+44.

[8] Espressif Systems. ESP8266 AT Instruction Set[Z/OL]. https://www.espressif.com/sites/default/files/4a-esp8266_at_instruction_set_en_v1.5.4_0.pdf.

[9] 李明, 张华. 嵌入式系统低功耗设计技术研究[J]. 微电子学与计算机, 2022, 39(7):112-116.

[10] Wang L, Chen W, Liu Z. A Multi-level Early Warning System for Indoor Air Quality Based on Embedded Technology[J]. Journal of Ambient Intelligence and Humanized Computing, 2022, 13(10):4589-4601.

[11] 中国电子技术标准化研究院. 室内空气质量监测设备技术要求(GB/T 39600-2020)[S]. 北京: 中国标准出版社, 2020.

[12] Benammar M, Abdaoui A, Ahmad S H M, et al. A Modular IoT Platform for Real-Time Indoor Air Quality Monitoring[J]. Sensors, 2018, 18(2):581.

[13] Narayana M V, Jalihal D, Nagendra S M S. Establishing A Sustainable Low-Cost Air Quality Monitoring Setup: A Survey of the State-of-the-Art[J]. Sensors, 2022, 22(1):394.

[14] Robinson J A, Kocman D, Horvat M, et al. End-User Feedback on a Low-Cost Portable Air Quality Sensor System—Are We There Yet?[J]. Sensors, 2018, 18(11):3761.

[15] Kim S, Stanton K, Park Y, et al. A Mobile App for Children With Asthma to Monitor Indoor Air Quality (AirBuddy): Development and Usability Study[J]. JMIR Formative Research, 2022, 6(5):e37118.

[16] Mountzouris C, Protopsaltis G, Gialelis J. Short-Term Forecast of Indoor CO2 Using Attention-Based LSTM: A Use Case of a Hospital in Greece[J]. Sensors, 2025, 25(17):5382.

[17] Sensirion AG. SCD41 Product Page[EB/OL]. [2026-04-15]. https://sensirion.com/products/catalog/SCD41.

[18] Sensirion AG. SCD4x Datasheet[EB/OL]. [2026-05-16]. https://sensirion.com/media/documents/48C4B7FB/66D0510F/Sensirion_CO2_Sensors_SCD4x_Datasheet.pdf.

[19] 国家市场监督管理总局, 国家标准化管理委员会. 室内空气质量标准: GB/T 18883-2022[S]. 北京: 中国标准出版社, 2022.

[20] Pineda-Tobón D M, Espinosa-Bedoya A, Branch-Bedoya J W. Aquality32: A low-cost, open-source air quality monitoring device leveraging the ESP32 and google platform[J]. HardwareX, 2024, 16:e00584.

[21] Sensirion AG. SCD4x Design-In Guide[EB/OL]. [2026-05-16]. https://sensirion.com/media/documents/0D0C9129/623B1183/Sensirion_CO2_Sensors_SCD4x_design-in_guide.pdf.

致谢

感谢指导教师在课题选题、系统设计与论文撰写过程中给予的帮助与指导。感谢学院老师在毕业设计各阶段提供的支持与建议。感谢同学与朋友在资料收集、测试验证和交流讨论中提供的帮助。最后，感谢家人在整个毕业设计期间给予的理解与鼓励。

附录

附录A 主要程序模块说明

本文系统程序按照“传感采集、数据处理、分级报警、显示刷新和通信上传”的结构进行组织。各模块之间通过统一的数据结构传递 CO2 浓度、温度、湿度、报警等级和设备状态，避免不同功能直接重复读取传感器或重复计算报警结果。主要程序模块如表A.1所示。

表A.1 主要程序模块说明表

附录B 样机测试记录汇总

为便于复核本文第6章测试结果，表B.1汇总了样机阶段的典型测试记录。测试内容覆盖浓度测量、报警响应、无线通信和功耗状态，能够从监测有效性、预警及时性、远程同步能力和能耗表现等方面说明系统运行情况。

表B.1 样机测试记录汇总表

附录C 设计资料归档说明

本文设计资料由硬件设计文件、软件程序文件、测试记录和界面截图四部分组成。硬件设计文件包括系统原理图、PCB 布局图、三维装配图和 ERC/DRC 检查报告；软件程序文件包括主控采集报警程序、通信上传程序和移动端交互页面；测试记录包括浓度测量、响应时间、通信稳定性和功耗测试记录；界面截图包括登录页、监测总览页、趋势分析页、设备管理页、场景联动页和维护中心页。上述资料与正文内容相互对应，构成本文系统设计、实现和测试过程的支撑材料。