STM32室内气体检测系统：从传感器采样到浓度换算的完整实现

简介：基于STM32F103C8T6的智能室内气体检测系统完整工程，实时监测温湿度与空气质量，具备本地显示、智能调控与云端交互三大核心功能。系统通过MQTT协议将数据上传至HomeAssistant，实现可视化监控与硬件控制，并可接入小爱同学等主流智能家居生态，联动灯光与排气系统开关，适合作为电子类专业毕业设计、期末大作业或嵌入式物联网学习项目。压缩包共115个文件，以C源码和头文件为主（42个.c与44个.h），另含8个汇编启动文件、6份Markdown说明文档、9张图片资源及工程配置文件，整体仅957KB，模块划分清晰便于检索。工程基于STM32标准外设库，集成MQTT通信模块，覆盖定时器、ADC数据采集、USART、I2C等多类型驱动，便于快速理解STM32工程组织方式并开展二次开发，也可迁移到类似环境监测场景。目前已有92人浏览学习，适合有一定单片机基础、需要快速搭建室内环境监测与智能联动方案的开发者。

1. 基于STM32的智能室内气体检测系统：这套源码到底解决了什么

拿到「基于stm32的智能室内气体检测系统源码+文档说明.zip」这类压缩包的人，多数不是来研究算法的，而是要在课程设计、毕业设计或者家里DIY一台能实时监测空气质量的设备。先说一句可能让你意外的话：这类项目里，STM32的代码反而不是最难的，最难的是传感器标定和采样电路——代码只能让系统“动起来”，要让数据“可信”，功夫全在板子和参数上。这套源码的价值在于，它把传感器采集、浓度换算、阈值报警、显示和扩展接口串成了一条完整链路，你不需要从零开始画框图、调ADC，可以顺着它的架构改需求。它适合三类人：手头有F103开发板想快速出原型的学生，想给家里排气扇加自动控制的DIY爱好者，以及刚转嵌入式、想看懂一个真实多模块工程是怎么组织的初学者。如果你的目标是“能演示、能交差、能看懂并在它基础上改”，这套东西就值得你花时间拆开。

2. 硬件选型与采样电路：传感器、芯片和引脚配置怎么定

拿到任何源码，第一步永远是看它对应的硬件。STM32气体检测系统最常见的配置是：一颗STM32F103C8T6作为主控，配一个MQ系列模拟气体传感器、一个0.96寸OLED、一个蜂鸣器和几个按键，再留一组继电器或风扇接口。这个组合成本低、引脚少、资料多，而且覆盖了ADC采集、I2C显示、GPIO控制、定时器中断这些嵌入式基本功。如果你是照着源码画板子，先别急着改芯片，把F103C8T6引脚吃透再说。

2.1 气体传感器选型：MQ系列还是数字传感器

室内气体检测最常用的传感器有三类：MQ-2适合检测烟雾和可燃气体，MQ-7对一氧化碳敏感，MQ-135对氨气、苯类等空气质量指标有响应。它们的共同点是输出模拟电压，价格便宜，十几块钱一片，缺点是选择性差、需要加热、标定困难。如果源码里用的是MQ-2，那它默认的检测场景就是厨房燃气泄漏和烟雾报警；如果用了MQ-135，更多是监测室内综合空气质量。你拿到源码时，要看它头文件里传感器引脚和型号的宏定义，并对上实物。

另一类是SGP30、CCS811这类I2C数字传感器，直接输出等效CO2和TVOC值，不用做ADC换算，精度也更高，但价格贵不少，而且对PCB布局要求高。成熟方案里的做法是：模拟传感器留一路ADC，数字传感器留一路I2C，代码里做双传感器支持。你手里的源码如果只有模拟通道，后面想升级数字传感器，也不用推翻重写，只要在传感器抽象层加一个驱动文件就行。

2.2 最小系统引脚分配与启动文件确认

F103C8T6有48个引脚，除去电源和下载口，真正能用的GPIO大概30个出头。一套典型气体检测系统的引脚分配可以这样规划：

在代码里，引脚映射一般集中在bsp_gpio.c或main.h里。你拿到源码后要做的第一件事，不是编译，而是grep一下引脚宏定义，确认它和你手头板子的丝印一致。F103的ADC引脚和I2C引脚存在部分复用，如果PA0被OLED占用，ADC通道就得改到PA1或PA4，这时HAL库的GPIO_InitStruct.Pin和ADC_ChannelConfTypeDef.Channel两处要一起改，漏改任一处都会让采样值读成0或悬空电压。

代码块：引脚宏配置示例，以HAL库为标准写法。

/* main.h 或 bsp_gpio.h 中的引脚宏定义 */ #define MQ_SENSOR_GPIO_PORT GPIOA #define MQ_SENSOR_PIN GPIO_PIN_0 #define MQ_SENSOR_ADC_CHANNEL ADC_CHANNEL_0 #define OLED_I2C_PORT GPIOB #define OLED_I2C_SCL_PIN GPIO_PIN_6 #define OLED_I2C_SDA_PIN GPIO_PIN_7 #define BUZZER_GPIO_PORT GPIOB #define BUZZER_PIN GPIO_PIN_12 #define RELAY_GPIO_PORT GPIOB #define RELAY_PIN GPIO_PIN_14

这段宏定义决定了整个工程的可移植性。换板子时只需要改宏，不需要动业务逻辑。强调两个细节：ADC通道编号不是随便写的，PA0对应ADC_CHANNEL_0，PA1对应ADC_CHANNEL_1，这是芯片手册写死的；蜂鸣器和继电器引脚一定选普通5V容忍引脚，有些F103引脚不是5V容忍，接继电器驱动芯片时可能会把引脚烧坏。

2.3 传感器采样电路与ADC输入阻抗匹配

MQ系列传感器的内部结构是一个加热电阻串一个可变电阻，输出端从上拉电阻取分压。很多新手直接把传感器输出脚引到STM32的PA0，发现读数要么满偏要么乱跳，原因在阻抗匹配。MQ传感器输出阻抗通常在几十千欧级别，而STM32 ADC的输入等效阻抗在2k到10k之间（取决于采样时间），直接连接会让分压点被拉低，读数就失去线性。

常见做法是在传感器输出和ADC引脚之间加一个RC低通滤波器，R取10k，C取100nF，既能滤掉高频噪声，又能提供一定的缓冲。更稳妥的方案是加一级运放电压跟随器，用LM358或MCP6002都可以，成本不到一块钱。如果你不想加运放，就把ADC采样时间拉到最大（如55.5周期），并让软件做多次采样取平均，也能缓解一部分问题。源码里如果初始化ADC时采样时间设置得很短，比如1.5周期，那就要注意了——这是造成读数不稳的常见原因之一，要手动改长。

代码块：ADC初始化配置，重点看采样时间参数。

void MX_ADC1_Init(void) { ADC_ChannelConfTypeDef sConfig = {0}; hadc1.Instance = ADC1; hadc1.Init.ScanConvMode = DISABLE; /* 单通道模式，不需要扫描 */ hadc1.Init.ContinuousConvMode = DISABLE; /* 单次转换，由软件触发 */ hadc1.Init.DiscontinuousConvMode = DISABLE; hadc1.Init.ExternalTrigConv = ADC_SOFTWARE_START; hadc1.Init.DataAlign = ADC_DATAALIGN_RIGHT; hadc1.Init.NbrOfConversion = 1; if (HAL_ADC_Init(&hadc1) != HAL_OK) { Error_Handler(); } sConfig.Channel = MQ_SENSOR_ADC_CHANNEL; sConfig.Rank = 1; sConfig.SamplingTime = ADC_SAMPLETIME_55CYCLES_5; /* 加大采样时间，降低输入阻抗影响 */ if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK) { Error_Handler(); } }

这里的ADC_SAMPLETIME_55CYCLES_5表示转换一个通道需要55.5个ADC时钟周期，ADC时钟一般是12MHz分频后的，算下来每次采样大约4.6微秒，完全不影响气体检测这种慢变场景。气体浓度变化周期是秒级甚至分钟级，采样时间拉长换来的精度提升是值得的。如果你发现原始值跳动超过±20个LSB，先看采样时间是不是被改短了，其次看供电是不是稳定。

3. ADC多通道采样与浓度换算：从原始值到PPM的完整链路

气体检测系统里，芯片最难的不是接收数据，而是把ADC原始值换算成人能读懂的浓度单位。MQ传感器的输出和气体浓度不是线性关系，而是近似对数关系，这就需要在代码里做曲线拟合或查表。这一章的每个步骤都直接影响最终显示的数字准不准。

3.1 多通道ADC采集与切换通道的稳定性问题

如果你的源码支持多种气体检测，那就有多个传感器接到不同的ADC引脚，需要做多通道切换。网上很多教程是切换一个通道后立刻读取，结果发现第一二次读到的值明显异常，这就是通道切换后的建立时间没留够。STM32的ADC在切换通道后，内部采样电容需要重新充电到新通道的电压，如果上一次采样的电压和这次相差很大，转换结果就会有偏差。

可靠的做法是：切换通道后先丢弃第一次转换结果，连续采样三次，取后两次或全部的平均值。如果是用HAL库做规则组扫描，要确认ScanConvMode配置为多通道模式，并且在NbrOfConversion里填上通道数量，每个通道都要单独调用HAL_ADC_ConfigChannel。很多人在单通道时没注意这些字段，扩到多通道时反复出错，就是这个原因。

代码块：多通道ADC采集并取平均，丢弃第一次转换结果。

#define MQ_CHANNEL_COUNT 2 /* 假设有MQ-2和MQ-135两个传感器 */ uint16_t adc_buffer[MQ_CHANNEL_COUNT][3]; /* 每个通道采3次 */ void Read_All_Sensor_Channels(void) { /* 打开ADC，因为是软件触发单次模式，每次读之前需要启动转换 */ for (int ch = 0; ch < MQ_CHANNEL_COUNT; ch++) { for (int sample = 0; sample < 3; sample++) { HAL_ADC_Start(&hadc1); HAL_ADC_PollForConversion(&hadc1, 10); adc_buffer[ch][sample] = HAL_ADC_GetValue(&hadc1); HAL_ADC_Stop(&hadc1); /* 轻微延时，让采样电容有时间恢复 */ HAL_Delay(2); } } } uint16_t Get_Sensor_Average(uint8_t channel) { uint32_t sum = 0; /* 丢弃第一次采样，取后两次平均 */ for (int i = 1; i < 3; i++) { sum += adc_buffer[channel][i]; } return (uint16_t)(sum / 2); }

这套逻辑在单通道系统里同样适用。多出来的那一次采样不是浪费，而是给电容一个稳定时间。如果传感器接在长排线上，或者线缆靠近220V布线，采到的值会叠加工频干扰，这时候还可以加上滑动平均或中值滤波。气体检测对实时性的要求极低，哪怕你把50次采样取中值，响应时间也完全够用——真正影响响应的是传感器的化学扩散过程，不是软件的滤波窗口。

3.2 软件滤波：中值加滑动平均的组合策略

MQ传感器受到气流、温度和加热丝波动影响，输出信号上叠加了不少毛刺。只用简单平均值扛不住偶发尖峰，只用中值滤波又会丢掉真实趋势。我一般会做两级处理：先对连续5次采样取中值，把异常尖峰干掉，再把中值结果送入一个长度为10的滑动平均窗口，平滑掉缓慢波动。这个组合在烟雾报警场景下表现很好，既不会因为打火机瞬间火花误报，也不会因为浓度缓慢上升而反应迟钝。

滑动平均窗口的长度要小心调。太短，滤波效果差；太长，测到的浓度峰值会被拉平，报警时间会滞后好几秒。对于MQ-2响应时间在10秒到30秒的系统，窗口长度设10到20次就够了，每次采样间隔2秒，对应20到40秒的时间窗，不会过度延迟。

代码块：中值加滑动平均的组合滤波实现。

#define MEDIAN_WINDOW 5 #define AVERAGE_WINDOW 10 static uint16_t median_buf[MEDIAN_WINDOW]; static uint16_t average_buf[AVERAGE_WINDOW]; static uint8_t median_index = 0; static uint8_t average_index = 0; uint16_t Sensor_MedianFilter(uint16_t new_value) { median_buf[median_index] = new_value; median_index = (median_index + 1) % MEDIAN_WINDOW; /* 拷贝并排序，取中值 */ uint16_t tmp[MEDIAN_WINDOW]; for (int i = 0; i < MEDIAN_WINDOW; i++) tmp[i] = median_buf[i]; for (int i = 0; i < MEDIAN_WINDOW - 1; i++) { for (int j = i + 1; j < MEDIAN_WINDOW; j++) { if (tmp[j] < tmp[i]) { uint16_t t = tmp[i]; tmp[i] = tmp[j]; tmp[j] = t; } } } return tmp[MEDIAN_WINDOW / 2]; } uint16_t Sensor_SlidingAverage(uint16_t filtered_value) { static uint32_t sum = 0; sum -= average_buf[average_index]; average_buf[average_index] = filtered_value; sum += filtered_value; average_index = (average_index + 1) % AVERAGE_WINDOW; return (uint16_t)(sum / AVERAGE_WINDOW); }

注意这里的滑动平均窗口用了循环队列，避免了每次求和都遍历全数组。代码量不大，但省下的CPU时间对F103这种主频72MHz的芯片来说意义不大，更主要的意义是逻辑清晰，便于以后扩展卡尔曼滤波或用查表法替代时对照修改。实际生成最终浓度值的伪代码如下：raw = Get_Sensor_Average(ch); med = Sensor_MedianFilter(raw); avg = Sensor_SlidingAverage(med);，浓度换算只用avg。

3.3 浓度换算：对数拟合法与R0标定

MQ系列数据手册里给的是灵敏度曲线，纵轴是Rs/R0，横轴是气体浓度，坐标是对数刻度。也就是说，Rs/R0与浓度P满足一个近似关系：Rs/R0 = A * P^(-n)，两边取对数得到log(Rs/R0) = -n * log(P) + log(A)，是一条直线。代码里的做法通常是存两个校准点，算出斜率和截距，然后用对数函数反推P。

具体到实现：先计算当前传感器的电阻Rs。传感器电路里，传感器和内部分压电阻RL组成分压，ADC读到的电压Vout满足Vout / 3.3 = RL / (Rs + RL)，反解出Rs = RL * (3.3 - Vout) / Vout。R0是传感器在洁净空气中的电阻值，必须在初次上电预热完成后标定保存到Flash里。有了Rs/R0，就能代入拟合直线的参数算出P。

代码块：从ADC值到PPM浓度的换算函数。

#define RL_VALUE 10.0f /* 负载电阻，单位kΩ */ #define READ_VOLTAGE 3.3f /* ADC参考电压 */ #define ADC_MAX_VALUE 4095.0f /* 12位ADC满量程 */ /* 在洁净空气中标定的R0值，首次使用前需要校准 */ static float sensorR0 = 10.0f; /* 对数拟合参数：log(Rs/R0) = A * log(P) + B */ /* 数据手册取两个点拟合得到，不同传感器批次略有差异 */ #define FIT_A (-0.47f) #define FIT_B 1.32f float Calc_Resistance(uint16_t adc_value) { if (adc_value <= 0) adc_value = 1; float vout = (float)adc_value * READ_VOLTAGE / ADC_MAX_VALUE; float rs = (READ_VOLTAGE - vout) / vout * RL_VALUE; return rs; } float Calc_Concentration(float rs) { float ratio = rs / sensorR0; if (ratio <= 0) ratio = 0.001f; /* 由 log(ratio) = A * log(P) + B 反推 P */ float logP = (logf(ratio) - FIT_B) / FIT_A; return expf(logP); }

这组参数看着简单，标定才是重点。FIT_A和FIT_B不是你随便填的，最好按传感器数据手册上的曲线取两个点计算得到；不同批次的MQ传感器一致性差，同一型号不同批次的R0可能差一倍，所以每块板子都要单独做一次零点标定。代码里如果直接硬编码R0，那换一个传感器后读数就会整体偏移。标定方法我在后面第6章详细写，这里先说结论：R0不准，后面的所有浓度值都是摆设。

3.4 温漂抑制：为什么同一环境下早晚读数不同

MQ传感器的敏感层电阻会随环境温度和湿度变化，给浓度换算带来零点漂移。很多做完系统的同学发现，白天显示200ppm，晚上同一房间变成300ppm，就开始怀疑代码写错了。这不是代码问题，是传感器特性。

抑制温漂有几个思路：第一，在设备内部放一颗温湿度传感器，比如DHT22或SHT30，根据温湿度对R0做修正；第二，软件里做一个“慢基线漂移补偿”，每隔几小时记录一次洁净空气下的读数，把低点抬到零点；第三，也是最重要的，别把绝对浓度当成唯一指标，把变化率和阈值报警结合使用。源码里如果只有简单的ADC转浓度，没有温湿度补偿，那它更适合做“相对浓度监测”，比如“现在比半小时前空气质量差了多少”。

4. 阈值报警、显示与联网上报：迟滞逻辑、OLED菜单和可选的MQTT

传感器数据读回来，换算成浓度，下一步就是让人“看见”和让设备“动作”。这一章解决的是交互层问题：报警怎么设计才不会反复触发，屏上怎么显示才不费眼睛，以及如果想远程查看，怎么在不动太多代码的前提下加网络模块。

4.1 两级阈值报警：迟滞比较器思路在软件里的实现

常见错误做法是：浓度超过阈值就报警，低于阈值就关闭。结果传感器信号一抖，蜂鸣器响一下停一下，比火警还烦人。工业上处理这类问题用的是迟滞比较，也就是常说的回差。比如设定上限500ppm报警，那么要等浓度降到400ppm以下时才解除报警，中间这100ppm的差值就叫迟滞区间。这样即使信号轻微波动，报警状态也能保持稳定。

软件实现时，把报警逻辑封装成状态机，比在中断里做比较靠谱。代码里定义一个报警状态变量，根据当前浓度和上次状态决定是进入报警还是退出报警。还要加一个报警延时确认机制，连续3次采样都超阈值才触发，防止偶发尖峰误报。

代码块：带迟滞和确认次数的报警逻辑。

#define ALARM_HIGH_THRESHOLD 400 /* 进入报警的浓度阈值，单位ppm */ #define ALARM_LOW_THRESHOLD 320 /* 解除报警的浓度阈值，低于它才停止 */ #define ALARM_CONFIRM_COUNT 3 /* 连续N次超阈值才报警 */ uint8_t alarm_state = 0; /* 0=正常 1=报警 */ uint8_t alarm_count = 0; void Update_Alarm_State(uint16_t concentration_ppm) { if (alarm_state == 0) { /* 当前正常，判断是否要进入报警 */ if (concentration_ppm >= ALARM_HIGH_THRESHOLD) { alarm_count++; if (alarm_count >= ALARM_CONFIRM_COUNT) { alarm_state = 1; alarm_count = 0; } } else { alarm_count = 0; } } else { /* 当前报警，用低阈值判断是否解除 */ if (concentration_ppm <= ALARM_LOW_THRESHOLD) { alarm_state = 0; } } HAL_GPIO_WritePin(BUZZER_GPIO_PORT, BUZZER_PIN, alarm_state ? GPIO_PIN_SET : GPIO_PIN_RESET); HAL_GPIO_WritePin(RELAY_GPIO_PORT, RELAY_PIN, alarm_state ? GPIO_PIN_SET : GPIO_PIN_RESET); }

这段逻辑解释了为什么阈值要设两个：高阈值是“触发线”，低阈值是“复位线”，中间带叫回差。回差至少要大于传感器在稳定环境下的最大波动幅度。如果环境里偶尔有烟雾飘过，波动就有50到100ppm，那回差设在80到120ppm之间比较合适。设得太大会让报警解除困难，设得太小等于没有。

4.2 OLED显示与按键菜单：从I2C小屏到SPI大屏的移植点

0.96寸I2C OLED是这类项目最常用的显示方案，驱动库通常是U8g2或移植版的SSD1306。代码里需要关注的是I2C地址，一般是0x3C，但有些模块是0x3D，如果显示不出来先检查地址。显示内容至少要包含三部分：当前浓度数值、系统状态（正常/报警）、菜单选项（校准零点、设置阈值）。

如果源码里用的是SPI接口的彩色屏，比如ILI9341，接线就复杂一些，有CS、DC、RST、SCLK、MOSI五个引脚。这类屏常遇到的问题是通过读ID寄存器返回0xA1A1，这不是屏坏了，多半是接线错误或者供电电压不够，VCC要接3.3V而不是5V，MISO脚在只写模式下可以不接但读ID时必须有。看到0xA1A1先量电压、查引脚，而不是怀疑驱动库。

按键菜单设计上，我推荐三个按键就够：一个“菜单/确认”，一个“加”，一个“减”。短按切换菜单项，长按确认操作。零点校准这种操作一定要加确认弹窗，防止误触后R0被改写。

4.3 联网上报：串口透传协议与MQTT轻量封装

标题里没提联网，但很多同学最后都想把数据发到手机上看。最省事的路线不是换ESP32，而是在现有F103上挂一个ESP8266模块，走串口AT指令。F103的业务代码只负责把浓度数据拼成JSON字符串，通过UART发给ESP8266，ESP8266负责WiFi连接和MQTT上报。这样F103的代码改动量很小，只需要增加一个数据发送函数。

如果用MQTT，常见做法是连接本地的MQTT Broker，比如在局域网里跑一个mosquitto，或者用巴法云这类公共平台。需要提醒的是，数据上报周期不要设太短，5秒一次足够，ESP8266长时间高频率发送会发热，WiFi模块发热后掉线是玄学问题，很难从代码层根治。发送失败时要做好重试和缓存机制，别让F103因为UART发送阻塞住传感器采样。

代码块：通过串口发送浓度数据到ESP8266的JSON格式。

uint8_t mqtt_buf[128]; void Send_Concentration_Report(uint16_t co_ppm, uint16_t smoke_ppm) { /* 拼接JSON: {"c":123,"s":45} */ int len = snprintf((char *)mqtt_buf, sizeof(mqtt_buf), "{\"c\":%u,\"s\":%u}\r\n", co_ppm, smoke_ppm); /* 通过UART透传给ESP8266，波特率建议115200 */ HAL_UART_Transmit(&huart2, mqtt_buf, len, 100); }

串口透传的坑通常在波特率和电平上。ESP8266的GPIO容忍3.3V，但有些模块的板载串口芯片是5V电平，直接和STM32互连会出问题，最好确认模块是3.3V版本。另一个坑是共地，两个模块的GND没连在一起，串口数据就是乱码。这些问题排查起来不难，但第一次做时几乎都会踩一遍。

5. 气体检测系统避坑指南：从预热漂移到传感器交叉干扰

这一章是血泪经验的汇总。把最常见、最容易让新手卡壳三天的问题列出来，每条按现象、原因、解决的顺序写。你如果做的是类似项目，碰到问题先翻这一章，大概率能省下半天时间。

5.1 上电后读数乱跳，烧录完屏幕显示浓度上天

现象：程序烧进去，OLED或串口上显示的浓度数值从0跳到几千，过几分钟又自己降下来，完全没法看。

原因：MQ系列传感器内部有加热丝，冷态时传感器电阻和正常工作时差异很大。上电瞬间加热丝还没达到工作温度，敏感层的电导率处于非稳定状态，ADC读出来的原始值自然忽高忽低。这是物理特性，不是程序Bug。

解决：软件里加预热逻辑，设备上电后标记“预热中”，前60到120秒不参与浓度计算，只显示预热倒计时；同时把数据采集循环启动延时设到10秒以上，让加热丝有足够时间稳定。如果不想等那么久，可以在菜单里加一个“强制跳过预热”选项，但这只用于调试，产品形态下不能开放。

5.2 ADC采样值稳定在固定数值，比如4095或0

现象：浓度值要么满量程4095，要么一直是0，怎么吹气都不变化。

原因：满量程大概率是传感器输出端悬空或者引脚复用配置错了，ADC读到了浮空电压；读到0则可能是传感器供电没打开、分压电阻虚焊，或者传感器被烧坏了。还有一种容易忽视的情况是PA0同时被用作了其它外设的功能脚，GPIO模式不是模拟输入。

解决：先用万用表量传感器输出脚对地电压，正常应该在0.5V到3V之间，如果量到5V说明模块是5V供电直接输出，后级需要分压；接着检查GPIO_InitStruct.Mode是不是GPIO_MODE_ANALOG，不是的话改成模拟模式，再重新初始化ADC。区分是传感器坏了还是代码坏了，就看同一个GPIO接一个电位器，旋转时ADC值是否线性变化。

5.3 同一气体浓度，传感器放平放竖读数不一样

现象：板子平放在桌面读数稳定，拿起来竖立或者靠近墙壁后读数明显变化。

原因：MQ传感器是自然扩散进气，气体通过外壳上的网罩进入敏感层。如果传感器贴紧墙面或被外壳挡住进气孔，气体扩散路径变长，响应就会变慢甚至浓度偏低。放平放竖不影响进气，但挡住了就不行。

解决：外壳设计时给传感器留出独立的气室或通风孔，不要和电源模块挤在一起。安装位置避开风扇直吹和空调出风口，直吹会让读数剧烈波动。如果是带继电器控制排风扇的系统，传感器应装在房间中部或靠近可能的泄漏源，而不是装在排风扇旁边，否则抽风会直接稀释采样点浓度，系统永远不知道室内真实情况。

5.4 酒精、油烟让误报停不下来

现象：在厨房炒个菜，没人抽烟也没燃气泄漏，报警器响了。

原因：MQ-2对酒精、油烟、汽油挥发物都有响应，选择性差是这类传感器的天生短板。它检测的是“可燃气体总量”，不是“单一气体”。家里的料酒、洗洁精气味都可能触发报警。

解决：先确认传感器型号是否匹配检测对象。做燃气报警用MQ-2或MQ-5，做CO报警用MQ-7，别混用。软件上做联合判断，比如同时读温度和湿度，在厨房做饭时温度和湿度会同时上升，这时候可以把报警阈值临时抬高或屏蔽一段时间。这不是最优雅的办法，但低成本系统里很实用。

5.5 烧录后OLED花屏、按键失灵、蜂鸣器乱响

现象：程序能跑但屏幕显示乱码，按键按一个触发两次，或者蜂鸣器上电就响。

原因：很可能是电源问题。STM32F103的ADC、I2C和外设同时工作时，电流需求会冲到100mA以上，如果用USB口直接供电，线路压降会造成VDD不稳，I2C通信就容易出错。按键没有消抖是另一个高频原因，机械按键按下和释放的瞬间会产生几毫秒到几十毫秒的抖动，不处理就会一次按下触发多次。

解决：检查稳压芯片输出，AMS1117-3.3的输入至少要有5V，输出接一个100uF电容再进芯片。按键用软件消抖，检测到电平变化后延时20ms再确认。蜂鸣器上用三极管驱动的话，看基极电阻是不是太小导致误触发。还有一点，OLED的I2C总线上拉电阻要接，常见做法是VCC和SCL/SDA之间各接4.7k上拉，如果模块本身自带上拉就不用重复加。

6. 上电验证与标定技巧：让检测数据从“能看”到“可信”

系统能跑只是第一步，数据可信才有实用价值。这一步很多源码说明文档里不会写细，但恰恰是最重要的一环。拿到源码烧好程序后，不要急着调参，先按下面这套流程做基础验证和标定。

先检查R0标定。找一个确认无泄漏、无烟味、通风良好的房间，别在刚做完饭的厨房测，把设备放桌上，通电预热30分钟以上，待读数稳定后进入菜单的校准模式，让系统把当前环境记录为洁净空气基准。这样做，R0就对应了当前环境下传感器的阻值。注意温湿度变化后R0会漂，所以每两三个月要重新校准一次。

然后做简易响应测试。拿一个打火机，不点火，只放气，从设备侧面慢慢靠近传感器，观察浓度曲线是否在几分钟内上升；移走后十几分钟内是否回落。打火机燃气是丁烷，MQ-2对它有响应，这是最便宜方便的测试气源。想测CO传感器就用烟头或香烟产生的烟气，但要在通风良好的地方测，别把整个房间搞脏。通过这类测试可以验证报警阈值设得是否合理，通常阈值要比正常环境观察值的最大值高出30%以上。

最后做重复性测试。同一测试场景做三遍，记录每次达到报警阈值的时间。如果三次的响应时间差超过20%，优先怀疑传感器老化或采样电路接触不良，而不是代码。这套源码更适合作为开发平台来用，你可以把它的报警逻辑换成自己的业务，也可以把ADC部分换成数字传感器，核心是先把“从采集到显示报警”这条链路跑通。我个人习惯是拿到任何气体检测项目，先不看算法，打开串口打印原始ADC值，盯着它看五分钟，等它波动规律清楚了再去动阈值和滤波参数——原始值不稳，后面全是空中楼阁。希望这个流程能帮你少走点弯路。

本文还有配套的精品资源，点击获取