实验室消防预警这件事，我在学校里折腾了大半个学期。起因很简单：学院实验室里堆着各种加热设备、化学试剂和连夜运行的仪器，而传统消防报警主机一套下来价格不低，布线又麻烦，很多实验室其实并没有做到位。所以我就用STM32从头搭了一套消防预警控制系统，把烟雾检测、火焰识别、温度监测和报警联动全部整合在一块板子上，并且把代码、原理图和Proteus仿真完整开源出来。这套方案不仅适合做课程设计、毕业设计，也适合真正想给实验室或者小型工作间加一道安全防线的人参考。整个项目的核心思路并不复杂：传感器采集环境数据，STM32做阈值判断和状态管理，蜂鸣器、LED和继电器负责报警输出与联动控制，再加上OLED显示当前状态，所有逻辑都可以在Proteus里先仿真验证，再移植到实物。

下面我按从方案设计到落地复现的顺序，把这个项目的关键细节完完整整地拆开讲。

1. 实验室消防预警，为什么值得用STM32从头撸一套

1.1 传统消控方案的痛点

很多人一提到消防报警，第一反应是买现成的烟雾报警器。确实，家用独立式烟雾报警器几十块钱一个，装上就能用。但放到实验室场景，它有几个问题：第一，独立式报警器只能本地响，没法把信号联动到风扇、电磁阀或者远程通知；第二，实验室里常见的酒精、有机溶剂挥发，某些传感器容易误报，而真正需要关注的火焰和异常升温反而没有监测；第三，报警阈值固定不可调，不同实验室的底噪环境差很多，固定阈值要么天天误报，要么真出事了不响。

所以这个项目的定位不是替代专业消防主机，而是做一套低成本、高灵活、可二次开发的预警控制系统。它要解决三件事：多种传感器融合判断，减少单一传感器误报；分级报警，不同严重程度对应不同动作；把关键状态可视化，方便现场人员快速判断。

1.2 系统整体架构与工作流程

整个系统采用STM32F103C8T6作为主控，这是最常见也最便宜的选择，蓝色Pill板十几块钱就能买到，资源完全够用。传感器方面选了三个：MQ-2烟雾传感器检测可燃气和烟雾浓度，火焰传感器检测红外火焰特征，DHT11温湿度传感器监测环境温度。输出设备包括有源蜂鸣器、红绿双色LED、一个继电器模块，继电器可以接排风扇或者电磁阀做联动，此外还有一个0.96寸OLED显示屏显示实时数据。

工作流程可以这样理解：STM32通过ADC读取烟雾传感器的模拟电压，通过GPIO读取火焰传感器的数字信号，通过单总线协议读取DHT11的温度值。然后主控里跑一个简单的状态机，把所有输入综合判断，输出到报警设备和显示设备。判断逻辑不是"单一超限就报警"，而是做了分级：温度偏高但烟雾正常时，提示注意但不鸣笛；烟雾浓度超标或者检测到火焰时，立即进入报警状态；如果温度和烟雾同时异常，则进入最高级报警并触发继电器联动。

1.3 代码、原理图、仿真三个部分的分工

开源资料里我把这三个部分分开是有原因的。原理图解决的是"硬件怎么连接"的问题，你照着接线就能搭出一套实物；仿真解决的是"逻辑对不对"的问题，在Proteus里不需要真实硬件就能调试状态机和阈值逻辑；代码则是连接两者的桥梁。我建议的复现路线是：先看原理图理解硬件连接，然后用仿真跑一遍代码逻辑，最后再动手焊实物。这样做的最大好处是，最难的调试环节被前置到了仿真阶段，实物阶段基本就是验证性的工作，不容易烧板子。

2. 原理图设计：传感器、电源与接口的核心细节

2.1 传感器选型与接口设计

原理图里最关键的是传感器接口设计，这里每一路都有讲究。

MQ-2烟雾传感器，我用的模块是带模拟输出的那种，四根引脚：VCC、GND、AO（模拟输出）、DO（数字输出）。在原理图里我把AO直接接到STM32的PA0引脚，用ADC1的通道0来采集。MQ-2的模拟输出在洁净空气中大概0.1V到0.3V，浓度越高电压越高，接近5V。但这里有个细节：MQ-2模块的AO输出范围是0到5V，而STM32的ADC只能接受0到3.3V。很多新手直接接上去，ADC采到的值永远只有4095，就是因为没做电平匹配。

解决方式有两种。一种是在AO输出和PA0之间加分压电阻，用两个10K电阻串联分压，把0到5V映射到0到2.5V，这已经低于3.3V，安全了。另一种更优雅的方式，直接把MQ-2模块供电改为3.3V，但这样传感器的加热丝电压不足，灵敏度会明显下降，我不推荐。所以原理图里我用了分压方案，并且在分压节点加了100nF电容滤波，抑制电源纹波对ADC精度的影响。

火焰传感器，这里用的是一个简单的红外火焰探测模块，检测波长760nm到1100nm的红外光。模块输出DO数字信号，有火焰时输出低电平。这个模块的接口设计有个容易踩的坑：它内部比较器的参考电压是固定的，不同环境下灵敏度差异巨大。所以我在原理图上额外预留了一个电位器接口，用10K多圈精密电位器微调灵敏度，这是实物调试时的关键调节手段。

DHT11，温湿度传感器用单总线协议，数据引脚接PA1。原理图上务必在数据线和3.3V之间接一个4.7K上拉电阻，否则时序不稳定，读取经常失败。DHT11的供电我单独从3.3V取，不和5V混在一起，因为它的逻辑电平是3.3V标准，如果供电5V再配上不正确的上拉，信号可能读不到。

2.2 电源与复位电路：最容易被忽略的不稳定源

这套系统的供电我设计了两个方案：USB 5V供电和DC接口供电，通过一个自恢复保险丝进入系统。5V进来之后分成两路：一路直接给蜂鸣器、继电器、MQ-2加热丝供电；另一路通过AMS1117-3.3稳压到3.3V，供给STM32、OLED、DHT11和火焰传感器。

这里要重点说一个坑：继电器模块不能用STM32的GPIO直接驱动。继电器线圈工作电流在70mA左右，而STM32单个GPIO最大输出能力只有20mA，直接驱动轻则继电器不动作，重则烧毁引脚。原理图里我加了S8050三极管做驱动，GPIO接1K限流电阻到三极管基极，继电器线圈接在三极管集电极和5V之间，线圈两端并联一个1N4007续流二极管。这个续流二极管非常重要，继电器断开瞬间线圈会产生反向电动势，没有二极管的话，这个高压尖峰很容易击穿三极管。

复位电路用的是经典的10K上拉电阻加100nF电容到地，NRST引脚在低电平时复位。虽然STM32内部有复位电路，但外部RC电路能提高抗干扰能力，特别是在实验室这种电机、加热设备启停频繁的电磁环境里，外部复位电路更可靠。

2.3 下载调试接口与扩展预留

原理图里我还预留了三个非常实用的接口。首先是SWD下载接口，只用SWDIO和SWCLK两根线加地线，配合ST-Link就能下载和在线调试。不要用JTAG，占用的引脚太多了，SWD足够用。

其次是串口接口，USART1的TX和RX引出，方便通过串口把采集到的数据发到上位机查看，调试阈值时非常有用。第三是预留的IO口，PA2和PA3引出来作为扩展接口，后续如果要加Wi-Fi模块或者LoRa模块，不需要改板子直接飞线接上就行。

2.4 原理图绘制工具与封装检查经验

原理图我是用嘉立创EDA画的，免费、上手快、器件库全，生成的BOM清单可以直接用来买元件。画图时有几个经验值得分享：第一，电源和地网络一定要用全局网络标号，不要画长长的导线横穿整个图纸；第二，每个芯片的电源引脚旁边都加一个100nF去耦电容，这比只在一个地方放大电容效果要好得多；第三，画完一定要做电气规则检查，特别是有没有引脚悬空、网络命名冲突这类基础错误。

封装检查这块是很多新手栽跟头的地方。我的建议是：要用哪个封装，就下单前把封装图打印成1:1，拿实物芯片对比一下引脚间距。像MQ-2这种传感器模块，它本身是插针引出，封装反而简单。但DHT11有直插和贴片两种封装，引脚顺序完全不同，买零件之前一定要确认型号对应的封装。我自己就吃过这个亏，画完PCB才发现DHT11买的是贴片版，引脚定义和原理图对不上，最后只能飞线解决。

3. Proteus仿真：不烧一片板子先把逻辑跑通

3.1 仿真器件选型与元件库匹配

Proteus仿真的第一步是解决元件库问题。STM32F103C8T6在Proteus里的型号是"STM32F103C8"，可以直接在元件库搜到。MQ-2在Proteus里没有完全一致的模型，通常用"MQ-2"这个气体传感器模型，它有两个输出：模拟电压和数字阈值。DHT11也有现成模型，但要注意Proteus里的DHT11模型需要给它一个时钟信号才能正确输出温湿度数据，不然读出来的永远是0。火焰传感器没有标准模型，我用一个可变电阻分压电路代替模拟输出，或者直接用按钮模拟数字电平翻转，这完全够验证逻辑用。

在Proteus里放置STM32之后，第一件事不是连电路，而是双击芯片设置固件文件。Proteus的老版本需要把编译好的HEX文件手动关联到芯片上，新版本支持加载外部HEX文件。我用的流程是：Keil编译生成HEX，然后在Proteus里双击STM32芯片，在Program File选项卡里选择这个HEX文件。这一步搞错了，仿真跑起来芯片不会执行任何代码。

3.2 传感器信号模拟：ADC电压怎么注入

仿真里最灵活的部分就是模拟传感器信号。MQ-2的模拟输出在仿真里可以直接用电位器来模拟，一端接5V一端接地，滑动端接STM32的PA0，这样旋转电位器就能改变ADC输入电压，模拟烟雾浓度从正常到超标的完整过程。DHT11的读数在仿真里是通过模型参数设置的，右键点击DHT11器件，在属性里可以修改温度和湿度的初始值。这样调试状态机时非常方便，不用真的去加热或者点烟，直接改参数就行。

火焰传感器的数字信号在仿真里我用两种方式模拟：一种是按钮，按下接地表示检测到火焰；另一种是信号发生器输出矩形波，可以模拟火焰闪烁时信号抖动的情况。我强烈建议用按钮方式先跑通逻辑，再用信号发生器测试火焰检测的抗抖动滤波逻辑，因为真实的火焰传感器输出并不是稳定的低电平，而是随着火焰跳动不断变化的，如果主控程序里没有做消抖，很容易出现误报或者漏报。

3.3 仿真结果验证与边界测试

仿真阶段我做了三个层次的功能测试。基础测试是确认每个传感器单独报警时，蜂鸣器和LED的行为是否正确；联动测试是确认当温度和烟雾同时超标时，继电器是否正确吸合；边界测试则是把阈值设在临界点附近，观察是否有频繁翻转的临界抖动。

边界测试尤其重要，因为真实环境里信号不会像理想值一样稳定，烟雾浓度可能在阈值附近来回波动。我在代码里引入了迟滞比较的思路：报警阈值设为2.0V，复位阈值设为1.8V，也就是进入报警状态后，需要电压降到1.8V以下才会解除报警。这个0.2V的迟滞窗口，让系统不会因为信号微小的波动而频繁切换状态。在Proteus里我把电位器调到接近2.0V的位置，然后微调电压，观察系统是否稳定，这个测试暴露了最初版本没有迟滞逻辑时的状态抖动问题，修复后才算通过。

3.4 仿真与实物之间的差距提醒

仿真能验证逻辑，但别天真地以为仿真通过实物就一定没问题。Proteus里MQ-2模型的响应曲线和真实传感器差异很大，真实MQ-2在通上电之后需要预热几分钟，输出电压才会稳定，而模型瞬间就有输出。DHT11的时序在仿真里也偏理想化，实物的单总线时序对延时非常敏感，通常需要反复调整延时参数才能可靠读取。

所以我的经验是：仿真阶段重点验证状态机和阈值逻辑的正确性，实物的传感器特性和时序问题在调试阶段单独处理。仿真能帮你省掉80%的逻辑调试时间，剩下20%的硬件调优才是真正考验耐心的地方。

4. 代码模块化设计与核心逻辑实现

4.1 工程结构与模块划分

代码组织我尽量做到了模块化，每个人的工程习惯不同，但我觉得这种划分方式最适合这种多传感器项目：

Core/ ├── main.c 主函数与状态机 ├── adc.c 烟雾ADC采集与滤波 ├── dht11.c 温湿度读取 ├── flame.c 火焰信号检测 ├── alarm.c 报警控制逻辑 ├── oled.c 显示驱动 └── relay.c 继电器控制

每个模块只干一件事，接口通过头文件暴露。比如adc.c只负责返回当前烟雾浓度对应的电压值，不关心这个值该怎么判断；alarm.c只负责接收传感器数据和报警状态，不关心数据是怎么来的。这样一个模块出问题，不会影响其他模块，调试时也能快速定位。

4.2 ADC采集与滤波：为什么平均值滤波还不够

烟雾传感器的ADC采集是这套系统里数据质量的关键。我最初用最简单的平均值滤波，连续采10次取平均，但实测效果很一般。原因在于MQ-2的输出噪声不是白噪声，里面有低频漂移，简单平均无法有效抑制。而且一旦出现瞬间尖峰，平均值会被拉得很高，造成误报。

后来我改用中位值平均滤波，也就是去掉最大值和最小值之后，再对剩余数据取平均。这个算法对尖峰脉冲的抑制效果非常好，代价只是多消耗一点CPU时间，对STM32来说完全无所谓。核心代码如下：

uint16_t ADC_GetMedianAverageValue(void) { uint16_t buf[10]; uint16_t temp; int i, j; uint32_t sum = 0; // 连续采集10次 for (i = 0; i < 10; i++) { buf[i] = ADC_ReadSingleChannel(); delay_ms(10); // 每次间隔10ms，让采样点分散 } // 冒泡排序，实际数据量小，排序开销可忽略 for (i = 0; i < 9; i++) { for (j = i + 1; j < 10; j++) { if (buf[j] < buf[i]) { temp = buf[i]; buf[i] = buf[j]; buf[j] = temp; } } } // 去掉最大值和最小值，对中间8个值取平均 for (i = 1; i < 9; i++) { sum += buf[i]; } return (uint16_t)(sum / 8); }

这里有个细节：每次采样间隔10ms是刻意加的。ADC采样本身是微秒级的，如果连续快速采10次，采到的很可能是同一时刻的信号，滤波效果等于没有。把采样点分散到100ms的时间窗口里，才能反映真实信号的变化趋势。

4.3 阈值判断与状态机设计

状态机是整个控制逻辑的核心，我设计了三种状态：正常状态、预警状态和报警状态。转换条件如下：

设计成状态机而不是简单的if-else堆叠，好处是状态转换的管理清晰。比如从报警状态恢复时，需要同时满足"温度降到55℃以下"和"烟雾电压降到1.8V以下"，而不是某一个条件满足就立刻恢复，这个恢复迟滞逻辑在if-else里写容易混乱。

核心状态机代码大致如下：

void FSM_Update(void) { switch (current_state) { case STATE_NORMAL: if (flame_detected || smoke_voltage > 3.0f || temp_c > 65.0f) { current_state = STATE_ALARM; } else if (smoke_voltage > 2.0f || temp_c > 50.0f) { current_state = STATE_WARNING; } break; case STATE_WARNING: if (flame_detected || smoke_voltage > 3.0f || temp_c > 65.0f) { current_state = STATE_ALARM; } else if (smoke_voltage < 1.8f && temp_c < 45.0f) { current_state = STATE_NORMAL; } break; case STATE_ALARM: // 报警状态的解除需要满足更低的阈值，形成迟滞 if (!flame_detected && smoke_voltage < 2.2f && temp_c < 55.0f) { current_state = STATE_WARNING; } break; } }

4.4 报警输出与联动逻辑

报警输出模块相对简单，但有三个实践经验值得说明。蜂鸣器使用有源蜂鸣器，接在PB12引脚上，通过NPN三极管驱动。有源蜂鸣器内部自带振荡源，只要给高电平就会响，程序里不需要生成PWM，控制逻辑简化很多。无源蜂鸣器虽然音调可变，但对这个项目没必要，反而增加复杂度。

LED指示用红绿双色共阴LED，红色接PB13，绿色接PB14。正常状态亮绿灯，预警状态亮黄灯（实际上是绿灯熄灭红灯闪烁，利用视觉暂留效果），报警状态红灯快速闪烁。用LED状态来指示系统工作状态，比单纯的蜂鸣器更直观。

继电器控制逻辑我加了一个安全设计：只有在报警状态并且确认持续时间超过3秒后，继电器才闭合。这个3秒的确认时间是为了防止瞬间的干扰信号导致排风扇或者电磁阀误动作。真实场景里，消防联动设备一旦误动作，可能会造成实验中断甚至是损失，所以联动要保守，报警可以果断。

4.5 OLED显示与按键设置阈值

0.96寸OLED用的是SSD1306驱动芯片，I2C接口接到STM32的I2C1上。显示内容分为三块：第一行显示烟雾电压值和状态图标，第二行显示温度和湿度，第三行显示当前状态文字和继电器状态。刷新频率设为500ms，太快没必要，还增加CPU负担。

阈值参数我在代码里做了宏定义，默认值如下：

#define SMOKE_WARNING_THRESHOLD 2.0f // 烟雾预警阈值 (V) #define SMOKE_ALARM_THRESHOLD 2.5f // 烟雾报警阈值 (V) #define TEMP_WARNING_THRESHOLD 50.0f // 温度预警阈值 (°C) #define TEMP_ALARM_THRESHOLD 60.0f // 温度报警阈值 (°C)

如果不想改代码重新编译，我预留了三个按键接在PB0、PB1、PB10，可以在运行时调整预警阈值。长按按键进入阈值设置模式，用OLED显示当前值，短按加减，再长按确认退出。这个功能在实物调试阶段非常有用，不用每次调阈值都重新烧录程序。

5. 实物调试记录：误报、漂移和阈值校准

5.1 烟雾传感器上电漂移问题

实物调试第一个遇到的坑就是MQ-2的预热漂移。刚上电时，MQ-2的内部加热丝需要时间把敏感层加热到工作温度，这个过程中输出电压会从高到低逐渐变化，有时候需要3到5分钟才能稳定。如果系统上电后立刻用初始值做判断，很大概率会误触发报警。

解决办法是在代码里增加一个初始化校准过程：系统上电后前10秒不进行报警判断，只采集数据，记录当前环境的基线电压值，之后所有的判断都用"当前电压减去基线电压"这个差值来执行。简单说就是做了一次自动零点校准。这个改动看似简单，却直接把上电误报率降到了零。

5.2 火焰传感器的方向性与干扰光

火焰传感器的方向性很强，它的红外接收管正前方灵敏度最高，侧面基本无响应。安装时要注意朝向，应该覆盖实验室的主要风险区域，比如加热设备或者试剂架。测试时我用打火机在30cm距离处实验，传感器正面朝火源时响应灵敏，但稍微偏一点角度就可能漏报。

另一个问题是红外干扰光。白炽灯、太阳光中的红外成分都会引起误报，尤其是阳光直射的时候，传感器可能一直输出"有火焰"信号。我这个模块本身不带滤光片，所以比较怕强光干扰。解决策略有两个：硬件上在传感器前面加红外滤光片，只让火焰特征波段的红外光通过；软件上增加一个确认机制，连续检测到火焰信号超过1秒才确认为真实火焰，瞬间的信号尖峰直接忽略。

5.3 阈值应该怎么设：分区分级策略

阈值设置不是拍脑袋定的，我总结了一套实用的方法论。先让系统在实验室正常环境下运行半天，记录烟雾传感器的基线电压波动范围。我的实测结果是，正常环境下烟雾传感器基线电压在0.15V到0.35V之间波动，偶尔有0.5V的瞬态尖峰。所以预警阈值设在2.0V是比较合理的，这个电压对应的烟雾浓度已经明显高于正常环境，但又没到剧烈燃烧的程度。报警阈值2.5V则对应更明显的烟雾浓度。

温度阈值方面，实验室正常温度在25到30度之间，我把预警阈值设为50度，这个温度已经远超正常环境，但又低于危险范围。报警阈值60度意味着环境已经异常升温，很有可能是设备过热或者初期火灾。

这里要特别提醒的是，每个实验室的环境底噪不一样。如果你的实验室通风条件差，或者经常有酒精挥发，烟雾传感器基线可能就是0.5V甚至更高，这时候阈值要相应抬升。最好的办法就是把自动校准得到的基线电压值在OLED上显示出来，调试时观察一段时间，再确定阈值。

5.4 联动测试与功耗考量

继电器联动测试我做了两种模式。模式一是直接带负载测试，接一个小风扇模拟排烟设备，报警时风扇启动，预警解除后风扇停止。模式二是模拟真实场景，用酒精灯产生烟雾，测试烟雾传感器从响应到报警再到继电器闭合的完整链路。实测下来，从烟雾浓度超标到继电器动作大约需要3秒，其中1秒是传感器响应时间，2秒是软件确认时间。这个响应速度对实验室场景来说完全够用，初期火灾不会在三秒内就失控。

功耗方面，整个系统在正常状态下大约120mA，其中MQ-2加热丝占了将近100mA，STM32和OLED加起来不到30mA。如果实验室供电不稳定，建议用5V 1A以上的电源适配器，不要用USB口的手机充电器勉强供电，因为继电器吸合瞬间会有电流尖峰，供电不足会导致STM32复位。

6. 开源资料复用指南：拿到代码原理图仿真怎么上手

6.1 文件目录与复现顺序

开源包里我按照使用顺序整理了文件结构。拿到资料后，第一步不要急着打开工程文件，先看根目录的说明文档，里面写了硬件连接表和引脚分配。第二步打开原理图PDF，对照引脚分配表理解每个模块的连接关系。第三步打开Proteus仿真工程，加载HEX文件跑起来。第四步再打开Keil工程看代码。这个顺序能让你从整体到局部逐步理解，不会一头扎进代码细节出不来。

引脚分配表是经过反复确认的，列出核心部分如下：

6.2 从仿真到实物的移植步骤

如果你打算照着实物的方式做一套，我的建议是分四步走。第一步，按照引脚分配表把核心模块接好，先不接传感器，只烧录一个测试程序，确认OLED能正常显示，蜂鸣器和LED能控制。第二步，单独接DHT11，读取温湿度数据并和手机天气App对比，确认数值合理。第三步，接烟雾传感器和火焰传感器，用打火机和酒精蒸汽做测试，调整阈值。第四步，接继电器和联动设备，做完整的联动测试。每一步都要验证通过再进行下一步，不要一次性把全部模块接上再调试，出了问题很难定位。

移植过程中最常见的坑是传感器模块的供电电压不一致。MQ-2模块要5V供电才能保证加热效率，火焰传感器和DHT11我用3.3V供电，OLED也用3.3V。如果全部接5V，OLED和DHT11大概率会冒烟。如果全部接3.3V，MQ-2灵敏度会下降。所以供电分配一定要按照原理图来，不能图省事统一电压。

6.3 二次开发思路：加远程报警和节点扩展

这套系统本身是一个很好的基础平台，二次开发的方向很多。我目前正在做的扩展方向是加ESP8266 WiFi模块，把报警状态实时推送到手机。思路很简单，串口1和ESP8266对接，STM32在状态发生变化时通过AT指令发送一个HTTP请求，调用Server酱或者钉钉机器人Webhook实现手机推送。这样人在办公室，实验室里出事了也能第一时间知道。

另一个方向是组网扩展。用RS485总线把多套预警节点接到一个总控上，每个节点负责一个实验室，总控汇总所有节点的状态。STM32F103C8T6本身有USART支持RS485通信，再加一个MAX485芯片就能实现。这种方案对于整栋实验楼的安全管理来说，比部署传统消防主机更灵活，成本也更低。

还有一个更细节的优化点：给系统加一个自检功能。每次上电时自动检查传感器是否在线，比如DHT11读不到数据或者烟雾传感器输出恒定为0，就在OLED上提示传感器故障。实验室设备管理人员能通过这个功能快速判断是哪一路传感器坏了，不用打开外壳逐个排查。

整个项目做下来，我最深的体会是：消防预警系统的价值不在控制器本身，而在传感器的选型、布局和阈值校准这些细节上。STM32只是把逻辑跑起来，真正决定系统靠不靠谱的，是你能不能理解传感器在真实环境中的表现。这也是为什么我把原理图、仿真和代码全部开源出来的原因——任何一个环节缺失，这套资料的价值都会大打折扣。如果你打算在自己的实验室部署这套系统，我建议你重点花时间在阈值校准和传感器位置调整上，这两项工作做到位，系统的可靠性会远超预期。