境監(jiān)測與安防系統(tǒng)設計與仿真實現(xiàn))
1. 糧倉環(huán)境的真實痛點監(jiān)測什么、為什么重要前幾年幫老家一個糧庫做過一次巡檢系統(tǒng)改造當時陪我下倉的老保管員說了句話讓我印象特別深“這個倉要是半夜悶熱返潮一倉糧能毀掉一半等第二天早上發(fā)現(xiàn)神仙來了也救不回?！奔Z食存儲這事兒最怕的不是老鼠是看不見的溫濕度和突發(fā)火情。很多團隊做STM32畢設或者農(nóng)業(yè)物聯(lián)網(wǎng)項目時習慣把糧倉環(huán)境監(jiān)測當成“溫濕度采集 OLED顯示”的簡化任務但真正跑過現(xiàn)場的人都知道糧倉環(huán)境安防遠遠不止讀兩個數(shù)據(jù)那么簡單。這套系統(tǒng)的定位很明確用STM32做一套適合糧倉場景的本地環(huán)境監(jiān)測與安防終端采集溫度、濕度、煙霧濃度、火焰信號和人體入侵信號超限時聲光告警同時驅動排風扇等執(zhí)行設備。代碼、原理圖、Proteus仿真全部開源適合正在找STM32項目練手的嵌入式學習者也適合想做農(nóng)業(yè)物聯(lián)網(wǎng)課程設計或者小規(guī)模糧倉改造的工程師參考。項目本身不復雜但把“環(huán)境監(jiān)測”和“安防”兩套邏輯完整地揉進一個STM32F103C8T6里涉及到的單總線時序、ADC采集、多路告警調(diào)度和仿真聯(lián)調(diào)都值得掰開揉碎講一遍。1.1 溫度和濕度是糧食安全的頭號殺手糧食在存儲過程中最核心的生命活動是呼吸作用。溫度每升高10℃糧食呼吸強度大概會翻倍呼吸消耗干物質不說還會釋放水分和熱量讓糧堆局部“出汗”。當溫度掉到25℃以上、相對濕度超過70%的時候霉菌和儲糧害蟲的繁殖速度會進入指數(shù)區(qū)間。換句話說糧倉里最需要盯的兩個指標就是溫度和濕度這倆數(shù)據(jù)一旦越線霉變和蟲害幾乎不可避免。傳統(tǒng)做法是保管員每天定時拿手持溫濕度計逐倉巡查記錄成紙質表格。這里有兩個致命問題一是夜間和非工作時間出現(xiàn)溫濕度異常根本沒人知道等第二天開門已經(jīng)晚了二是大倉不同部位溫濕度差異很大單點手持測量覆蓋不全。這套系統(tǒng)在每個監(jiān)控節(jié)點實時采集溫濕度超過閾值立刻告警等于把“人盯數(shù)據(jù)”變成了“系統(tǒng)盯數(shù)據(jù)”。1.2 煙霧、火焰、非法入侵安防的另一半糧倉的安防需求很容易被忽略。糧粉在特定濃度下是易燃易爆的電氣線路老化、人員違規(guī)吸煙都有可能引發(fā)火情同時糧倉一般位置偏遠夜間防盜壓力也不小。單純做“環(huán)境監(jiān)測”不做“安防”只能算完成了一半。所以這套系統(tǒng)在溫濕度采集之外增加了三個安防維度煙霧濃度檢測通過MQ-2氣體傳感器實時監(jiān)測煙霧發(fā)生火情時能在早期發(fā)現(xiàn)?；鹧鏅z測紅外火焰?zhèn)鞲衅髯R別火光作為煙霧告警的交叉驗證減少誤報。人體入侵檢測被動式紅外熱釋電傳感器HC-SR501感知闖入者夜間告警提醒值守人員。四路信號在STM32里統(tǒng)一調(diào)度用不同的告警策略區(qū)分“環(huán)境異常”和“安防事件”這樣不會一有風吹草動就亂響也不會漏報真正的問題。這個需求拆解的過程恰恰是很多教程沒講透的部分——拿到原理圖先別急著畫板子先搞清楚系統(tǒng)到底要感知哪些物理量。2. 系統(tǒng)架構與硬件選型這套方案為什么這么配硬件選型是項目能不能順利跑起來的第一道坎。很多初學者一上來就想上頂級芯片結果外圍電路復雜、調(diào)試困難項目爛尾。這套系統(tǒng)選件的基本原則是在滿足性能的前提下優(yōu)先選資料多、成本低、容易買到的器件。2.1 主控選型STM32F103C8T6憑什么夠用主控選了STM32F103C8T6這是一顆基于ARM Cortex-M3內(nèi)核的芯片主頻72MHz64KB Flash20KB SRAM。有人會問糧倉監(jiān)測是不是得用更高端的芯片來保證可靠性實測下來的結論是沒必要。從資源占用角度算一筆賬資源用途占用情況GPIODHT11、LCD1602/OLED、按鍵、LED約15個引腳ADCMQ-2煙霧傳感器模擬輸出1個通道定時器系統(tǒng)節(jié)拍、延時延時1-2個串口調(diào)試日志輸出1個把這些全部算進去Flash和SRAM的占用率都不超過一半余量足夠后續(xù)擴展。而且這顆芯片可以說是STM32生態(tài)里資料最豐富、Proteus仿真支持最成熟的型號之一遇到問題搜解決方案一搜一大把非常適合作為教學和工程驗證的載體。2.2 傳感器與執(zhí)行器選型清單整個系統(tǒng)的硬件清單如下模塊型號/方案作用選型理由溫濕度采集DHT11采集溫度和相對濕度單總線協(xié)議接線簡單夠用煙霧檢測MQ-2檢測煙霧/可燃氣濃度模擬數(shù)字雙輸出靈敏度可調(diào)火焰檢測紅外火焰?zhèn)鞲衅髂K識別火光數(shù)字電平輸出接口簡單人體感應HC-SR501感知人體紅外輻射被動式熱釋電誤報率低顯示LCD1602或OLED SSD1306本地顯示溫濕度與告警狀態(tài)16x2字符顯示調(diào)試直觀告警有源蜂鳴器 LED聲光告警有源蜂鳴器單片機直接驅動不了需要三極管輸出控制繼電器模塊驅動排風扇隔離大負載安全可靠電源USB 5V AMS1117-3.3V系統(tǒng)供電穩(wěn)壓簡單成本極低這里重點解釋一下DHT11和DHT22的選擇。DHT11的精度是±2℃、±5%RH在糧倉這種場景下夠不夠坦白說做精細化糧庫監(jiān)測這個精度偏粗更推薦DHT22±0.5℃、±2%RH。但DHT11的優(yōu)勢在于單總線時序簡單、代碼量小、仿真模型成熟作為項目學習和技術驗證完全夠用。如果需要高精度方案軟件層只需要替換驅動函數(shù)上層邏輯不用動——這也是把傳感器驅動和業(yè)務邏輯分開寫的價值所在。2.3 整體工作流程系統(tǒng)上電后先自檢初始化LCD顯示啟動界面然后進入主循環(huán)定時器產(chǎn)生2秒節(jié)拍觸發(fā)溫濕度采集DHT11的數(shù)據(jù)手冊要求兩次讀取間隔大于1秒太頻繁會讀取失敗。周期性讀取煙霧濃度ADC值檢測火焰?zhèn)鞲衅骱腿梭w感應模塊的電平狀態(tài)。將采集數(shù)據(jù)刷新到LCD。在告警判斷函數(shù)里做閾值比較和消抖處理。超限時觸發(fā)聲光告警并通過繼電器啟動排風扇/打開應急照明。這套流程的邏輯非常清晰后面代碼部分會詳細展開。3. 原理圖設計每個模塊背后的設計邏輯原理圖是這套系統(tǒng)最容易被“抄完就忘”的部分。很多人拿到原理圖直接用但不知道為什么這里要加上拉電阻、那里要加RC濾波。把這些設計邏輯講清楚才是真正吃透項目。3.1 電源與最小系統(tǒng)穩(wěn)定是底線電源部分采用了USB 5V輸入 AMS1117-3.3V穩(wěn)壓的方案。為什么不用ST-Link直接給3.3V因為MQ-2的加熱回路需要5V供電DHT11和LCD1602的典型工作電壓也是5V所以系統(tǒng)必須同時存在5V和3.3V兩路電源。AMS1117-3.3的輸出端要加10uF和100nF去耦電容一個負責低頻穩(wěn)壓一個負責高頻噪聲濾除。STM32F103C8T6的每個VDD引腳旁邊也建議就近放一個100nF去耦電容這是很多初學者容易漏掉的小細節(jié)不加也能跑但ADC采樣精度和系統(tǒng)穩(wěn)定性會打折扣。最小系統(tǒng)部分有幾個關鍵字——8MHz外部晶振配兩個22pF負載電容、復位電路用10k上拉電阻加100nF電容、BOOT0和BOOT1通過10k下拉電阻接地保證從Flash啟動、SWD下載口引出PA13/PA14。這里特別提醒一點SWD接口一定要把GND也引出來否則下載器經(jīng)常連不上目標板。3.2 傳感器接口電路上拉、分壓、隔離DHT11的輸出引腳是漏極開路結構數(shù)據(jù)線上需要接一個4.7k-10k的上拉電阻到VCC。上拉電阻太小會讓總線驅動能力不足太大會導致上升沿變緩實測4.7k最穩(wěn)。MQ-2模塊的AO引腳輸出的是模擬電壓直接接到STM32的PA1引腳即可。但注意MQ-2的AO輸出范圍是0-5V而STM32的ADC輸入范圍是0-3.3V——市售MQ-2模塊上往往自帶一個可調(diào)電位器和比較器模塊的DO輸出是TTL電平可以直接接但AO輸出直接接ADC引腳是有風險的。穩(wěn)妥的做法是用兩個電阻做分壓比如10k和20k串聯(lián)將5V分壓到3.3V以內(nèi)或者直接購買3.3V兼容版的MQ-2模塊。HC-SR501的輸出是3.3V兼容的數(shù)字電平可以直接接GPIO。這個模塊上有兩個可調(diào)電位器分別調(diào)節(jié)感應距離0-7米和延時時間5秒-300秒用在糧倉安防場景建議把延時調(diào)到最小、靈敏度調(diào)到中間檔。3.3 告警與驅動電路GPIO怎么帶動大負載STM32的GPIO最大輸出電流只有約20mA直接驅動蜂鳴器和繼電器的線圈肯定不夠必須加驅動電路。蜂鳴器用S8050 NPN三極管驅動GPIO通過1k基極電阻接三極管基極蜂鳴器接在集電極和VCC之間發(fā)射極接地。GPIO輸出高電平時三極管導通蜂鳴器響起。繼電器驅動用的是ULN2003達林頓管陣列這個芯片內(nèi)部自帶續(xù)流二極管可以直接驅動繼電器線圈。這里有一個反復被問的問題為什么不用三極管因為繼電器線圈是感性負載斷電瞬間會產(chǎn)生很高的反向電動勢如果不加續(xù)流二極管會擊穿驅動管。ULN2003內(nèi)部集成了這個保護設計上省心很多。如果是單路繼電器用一個NPN三極管加一個1N4007續(xù)流二極管也完全可以。4. 代碼實現(xiàn)驅動、調(diào)度與告警邏輯整套代碼是在Keil MDK5環(huán)境下基于STM32標準外設庫完成的。工程結構分為四層硬件驅動層DHT11、ADC、LCD、業(yè)務邏輯層采集任務、告警任務、調(diào)度層主循環(huán)定時器標志位、配置層時鐘、GPIO、中斷初始化。4.1 工程結構與代碼布局建議的工程文件組織方式文件/文件夾職責core/啟動文件、系統(tǒng)時鐘配置user/main.c、stm32f10x_it.c 中斷服務函數(shù)hardware/dht11.c、adc.c、lcd1602.c、alarm.c、key.csystem/系統(tǒng)初始化、延時函數(shù)把硬件驅動和業(yè)務邏輯分開最大的好處是換傳感器或者改邏輯時不用動底層驅動。比如從DHT11換成DHT22只需要重寫dht11.c里的讀寫時序上層調(diào)用函數(shù)接口不變。4.2 DHT11單總線時序的軟件實現(xiàn)DHT11的時序是整個代碼里最講究的部分。單總線協(xié)議沒有時鐘線靠嚴格的延時和電平翻轉來傳輸數(shù)據(jù)容錯窗口通常在10-30us級別所以延時函數(shù)的精度直接影響通信成敗。讀取一次溫濕度的完整流程主機把總線拉低至少18ms發(fā)出起始信號。主機釋放總線并延時20-40us等待DHT11響應。DHT11拉低總線80us作為應答然后拉高80us表示即將發(fā)送數(shù)據(jù)。隨后DHT11依次發(fā)送40位數(shù)據(jù)8位濕度整數(shù)、8位濕度小數(shù)、8位溫度整數(shù)、8位溫度小數(shù)、8位校驗和。每位數(shù)據(jù)的解碼規(guī)則是先有50us低電平緊接著高電平。高電平持續(xù)26-28us表示邏輯0高電平持續(xù)70us表示邏輯1。核心讀取代碼uint8_t DHT11_ReadByte(void) { uint8_t i, data 0; for (i 0; i 8; i) { // 等待50us低電平結束 while (DHT11_PIN 0); // 延時約30us后采樣電平 Delay_us(30); if (DHT11_PIN 1) { data (data 1) | 0x01; } else { data (data 1) 0xFE; } // 等待高電平結束 while (DHT11_PIN 1); } return data; }讀取完整數(shù)據(jù)的流程uint8_t DHT11_ReadData(uint8_t *temp, uint8_t *humi) { uint8_t buf[5]; uint8_t i; // 主機拉低至少18ms發(fā)送起始信號 DHT11_PIN_OUT(); DHT11_PIN_LOW(); Delay_ms(20); DHT11_PIN_HIGH(); Delay_us(30); DHT11_PIN_IN(); // 檢查DHT11應答信號 if (DHT11_PIN 1) return 1; // 無應答 while (DHT11_PIN 0); // 等待應答低電平結束 while (DHT11_PIN 1); // 等待高電平結束 // 連續(xù)讀取5字節(jié)含校驗 for (i 0; i 5; i) { buf[i] DHT11_ReadByte(); } // 校驗和驗證 if (buf[4] ! (buf[0] buf[1] buf[2] buf[3])) return 2; // 校驗失敗 *humi buf[0]; *temp buf[2]; return 0; }這個代碼里有幾個細節(jié)值得注意一是Delay_us(30)必須放在判斷之前放在判斷之后讀到的高電平就包含了70us和26us兩種可能無法區(qū)分0和1二是主循環(huán)調(diào)用DHT11的間隔不能小于1秒否則傳感器無法完成內(nèi)部測量會一直返回0。這也是為什么把采集放到2秒定時器節(jié)拍里。4.3 ADC采樣與煙霧濃度換算MQ-2的AO輸出接到STM32的PA1引腳對應的ADC通道是ADC1_IN1。配置ADC1工作在連續(xù)轉換模式采樣時間為55.5周期確保阻抗匹配。讀取代碼uint16_t ADC_ReadChannel(uint8_t channel) { ADC1-SQR3 channel; // 選擇轉換通道 ADC1-CR2 | (uint32_t)1 22; // 啟動轉換 while (!(ADC1-SR (1 1))); // 等待轉換完成 return ADC1-DR; // 返回12位ADC值 }煙霧濃度的判斷不能只看單次ADC值。MQ-2在剛上電的幾十秒內(nèi)讀數(shù)會飄因為內(nèi)部加熱絲需要時間達到工作溫度。我的做法是在開機后等待MQ-2預熱完成約60秒啟動時保存一個基線值然后用當前讀數(shù)相對基線的偏差作為判斷依據(jù)這樣可以抵消不同環(huán)境下的濃度基準差異。uint8_t SMOKE_GetLevel(uint16_t baseline, uint16_t current) { // 偏差超過200個ADC碼值認為有煙霧 if (current baseline 200) return 1; return 0; }4.4 告警消抖與狀態(tài)機設計告警邏輯最容易犯的錯誤是一讀到超限就立刻觸發(fā)告警。傳感器瞬間波動、電磁干擾、甚至灰塵飄過探測口都會造成毛刺直接觸發(fā)的后果就是蜂鳴器亂叫值守人員很快就會失去信任。所以告警函數(shù)里做了一次數(shù)值消抖連續(xù)3次采樣都超限才確認告警。void Alarm_Task(void) { static uint8_t confirm_count 0; uint8_t danger 0; // 條件判斷 if (temp TEMP_ALARM_THRESHOLD || humi HUMI_ALARM_THRESHOLD || smoke_adc smoke_baseline SMOKE_DEVIATION || fire_detected || pir_detected) { confirm_count; if (confirm_count 3) { danger 1; } } else { confirm_count 0; } if (danger) { Alarm_On(); // 蜂鳴器響、LED閃爍、繼電器動作 } else { Alarm_Off(); } }同時不同的告警源應該有不同的表現(xiàn)方式。溫濕度超限屬于“環(huán)境預警”蜂鳴器慢速間歇鳴響煙霧和火焰屬于“火情告警”蜂鳴器快速長鳴人體入侵屬于“安防事件”蜂鳴器短促三聲循環(huán)。這樣值守人員光聽聲音就能判斷現(xiàn)場出了什么類型的問題不用每次跑過去看屏幕。5. Proteus仿真從工程到跑通的完整過程Proteus仿真最大的價值在于可以不焊接一塊板子就把代碼邏輯驗證一遍。但這個環(huán)節(jié)恰恰是無數(shù)人卡殼的地方——很多人連仿真圖都搭不起來。下面把從我這邊實測跑通的完整流程拆開講。5.1 仿真環(huán)境的搭建與元件準備Proteus版本建議用8.9以上對STM32F103C8T6的支持比較完善。新建工程后在元件搜索欄里依次添加搜索關鍵字元件說明STM32F103C8T6MCU主控在“ST Microcontrollers”分類下DHT11溫濕度傳感器舊版本Proteus沒有需要更新庫文件LM016LLCD1602液晶屏標準字符液晶模型MQ-2氣體傳感器部分版本用MQ-2模型或電壓源替代BUZZER有源蜂鳴器需要配合三極管驅動LED-RED / LED-GREEN指示燈告警狀態(tài)顯示RESISTOR / CAPACITOR電阻電容按原理圖參數(shù)設置BUTTON按鍵閾值設置/復位POT-HG電位器LCD對比度調(diào)節(jié)如果搜索不到DHT11有一個替代思路用兩個電壓源模擬DHT11輸出或者用Proteus自帶的DHT55傳感器模型來驗證邏輯。但這樣沒法驗證時序代碼對不對所以還是建議安裝帶完整元件庫的版本或者從Proteus官網(wǎng)更新庫文件。5.2 編譯生成hex并加載到Proteus代碼在Keil里編譯生成hex文件的方法在Keil工程中點擊魔術棒Options for Target。在Output選項卡勾選“Create HEX File”。編譯工程在輸出目錄下生成.hex文件。然后在Proteus中雙擊STM32F103C8T6元件在彈出的屬性對話框里將Program File路徑指向剛生成的hex文件。這里要注意兩個坑Crystal Frequency設置必須設置為8MHz與工程代碼里的SystemInit配置的外部晶振一致。如果設為默認值0仿真時鐘直接亂了延時函數(shù)會出錯。電源引腳Proteus的STM32模型雖然會自動供電但如果仿真中使用了PA0等模擬輸入引腳記得在VSSA/VDDA引腳上正確接電源否則ADC讀到的數(shù)據(jù)是亂的。加載完成后點擊運行。正常的現(xiàn)象是LCD顯示當前溫度和濕度調(diào)節(jié)仿真中的DHT11濕度值或溫度值LCD數(shù)據(jù)跟著變化按下對應按鍵觸發(fā)超限蜂鳴器和LED開始告警。5.3 仿真中踩到的三個坑第一個坑是DHT11仿真時序與實物不一致。Proteus的DHT11模型對延時的敏感度比實物更高實物上30us的容錯窗口在仿真里可能只有10us。解決方法是微調(diào)代碼里的延時參數(shù)把Delay_us(30)改成Delay_us(50)左右前提是你用的是帶仿真模型的DHT11。如果怎么調(diào)都讀不到數(shù)據(jù)還有一個土辦法把DHT11換成兩個可變電阻模擬溫濕度變化用ADC讀取來代替單總線讀取先把整體流程跑通再回來搞時序。第二個坑是LCD1602顯示亂碼或全屏方塊。最常見原因是仿真里LCD的對比度調(diào)節(jié)引腳Vo直接接地了沒有接電位器。加上一個10k電位器把Vo電壓調(diào)到1V左右LCD工作電壓的10%-20%顯示就正常了。第三個坑是蜂鳴器不響。Proteus里的蜂鳴器分有源和無源兩種有源蜂鳴器只要通電就會發(fā)聲無源需要PWM才能響。仿真里如果上電不響先檢查型號是不是SOUNDER有源/無源模型不同再看驅動管是否型號匹配。這里有一個小技巧Proteus仿真的蜂鳴器很多時候是“邏輯上已經(jīng)響起、但電腦聲卡沒輸出”——看仿真里的電流表和驅動管狀態(tài)就能確認。6. 從仿真到實物部署經(jīng)驗與擴展方向仿真跑通只是完成了一半實物搭建和現(xiàn)場部署才是真正檢驗系統(tǒng)可靠性的地方。這個環(huán)節(jié)有很多仿真里根本不會暴露的問題非常值得單獨拿出來說。6.1 實物搭建中容易被忽略的細節(jié)DHT11在實物調(diào)試里的頭號問題是IO口方向切換的時序。STM32的GPIO配置為輸入和輸出之間切換需要大約幾個時鐘周期標準外設庫里的GPIO_Init調(diào)用開銷比較大。一個可行的做法是把DHT11的數(shù)據(jù)線接到一個獨立IO用寄存器操作快速切換方向#define DHT11_PIN_OUT() { GPIOB-CRH 0xFFFF0FFF; GPIOB-CRH | 0x00003000; } #define DHT11_PIN_IN() { GPIOB-CRH 0xFFFF0FFF; GPIOB-CRH | 0x00004000; }這樣配置方向只需要兩條寄存器指令比調(diào)用庫函數(shù)快幾十倍實測在48MHz主頻下能穩(wěn)定讀取DHT11。第二個是供電問題。MQ-2的加熱絲最大工作電流在150mA左右如果和STM32共用一組USB供電電源線上的紋波會影響到ADC采樣。建議的做法是MQ-2單獨從5V端取電并在模塊電源引腳就近加一個100uF電解電容和一個104瓷片電容把加熱絲的瞬態(tài)電流波動吸收掉。第三個是繼電器帶負載的問題。繼電器觸點驅動排風扇這種感性負載時觸點閉合斷開的瞬間會產(chǎn)生電弧長期使用會造成觸點燒蝕。在繼電器輸出端并聯(lián)一個RC吸收電路典型值100Ω 104電容串聯(lián)能有效延長繼電器壽命。6.2 糧倉現(xiàn)場的實用建議如果這套系統(tǒng)真的要用在糧倉環(huán)境里有幾個點比代碼和原理圖更關鍵傳感器的布點位置不能只放一個點。糧倉的不同高度和位置溫濕度差異很大靠近門窗的位置濕度高、糧堆中心溫度高。至少要在倉內(nèi)東南西北四個角落各裝一個節(jié)點再在糧堆表層和距表層50cm深處各埋一個測溫點才能形成有效的監(jiān)測網(wǎng)絡。這套單節(jié)點方案可以作為每個點位的基礎單元后續(xù)通過RS485總線把多個節(jié)點組網(wǎng)把數(shù)據(jù)匯總到上位機。傳感器的防護很關鍵。糧倉內(nèi)粉塵濃度高DHT11的感濕元件如果直接裸露在環(huán)境里用不了幾個月就會被粉塵覆蓋測量值嚴重偏移。建議給傳感器加一個透氣防塵罩或者把傳感器放在一個開有小孔的塑料盒子里。MQ-2也面臨同樣的問題它的防爆網(wǎng)罩結構本身能防塵但網(wǎng)罩上的粉塵也需要定期清理。告警閾值不能拍腦袋定。不同的糧食品種對溫濕度要求不同小麥的安全水分是12.5%左右稻谷是14%左右對應的倉儲環(huán)境濕度閾值最好參考《糧油儲藏技術規(guī)范》來設置。我預留了通過按鍵調(diào)節(jié)閾值的功能就是為了讓使用者根據(jù)實際存儲品種靈活調(diào)整。6.3 后續(xù)擴展方向這套系統(tǒng)在擴展性上留了很多接口。軟件層面主循環(huán)的調(diào)度結構可以很容易地加入新傳感器——只需要在硬件驅動層增加一個文件在Alarm_Task里增加一個判斷條件。硬件層面如果要做遠程監(jiān)控可以在串口1上掛一個ESP8266模塊把溫濕度和告警狀態(tài)通過MQTT協(xié)議上報到云平臺實現(xiàn)手機遠程查看。要做低功耗的話STM32F103C8T6可以進入待機模式配合RTC定時喚醒用外部中斷喚醒做入侵檢測一塊18650電池可以支持幾個月。如果要組網(wǎng)做多節(jié)點方案建議把通信鏈路從單總線換成RS485DHT11的數(shù)據(jù)通過傳感器節(jié)點上的小MCU預處理后再通過RS485總線上傳。這樣既解決了長距離布線的抗干擾問題也讓每個節(jié)點具備本地獨立判斷能力不會因為總線上某個節(jié)點故障而影響整個網(wǎng)絡。我在實際做的過程中最大的感受是仿真和實物之間的差距就是理論學習和工程實踐的差距。仿真幫你驗證了邏輯但實物會告訴你什么是電源紋波、什么是時序容錯、什么是接觸不良。這套系統(tǒng)從畫原理圖到最終在糧庫角落穩(wěn)定運行前前后后調(diào)試了將近兩周踩的坑遠比這篇文章里寫得多。但正是因為這些坑整個系統(tǒng)的每一行代碼、每一顆電阻的取值才能講得清楚來龍去脈。這也是我決定把它們整理成開源項目的初衷——不要讓后人重復踩同樣的坑。 基于STM32的糧倉環(huán)境監(jiān)測與安防系統(tǒng)設計與仿真實現(xiàn)
1. 糧倉環(huán)境的真實痛點監(jiān)測什么、為什么重要前幾年幫老家一個糧庫做過一次巡檢系統(tǒng)改造當時陪我下倉的老保管員說了句話讓我印象特別深“這個倉要是半夜悶熱返潮一倉糧能毀掉一半等第二天早上發(fā)現(xiàn)神仙來了也救不回?！奔Z食存儲這事兒最怕的不是老鼠是看不見的溫濕度和突發(fā)火情。很多團隊做STM32畢設或者農(nóng)業(yè)物聯(lián)網(wǎng)項目時習慣把糧倉環(huán)境監(jiān)測當成“溫濕度采集 OLED顯示”的簡化任務但真正跑過現(xiàn)場的人都知道糧倉環(huán)境安防遠遠不止讀兩個數(shù)據(jù)那么簡單。這套系統(tǒng)的定位很明確用STM32做一套適合糧倉場景的本地環(huán)境監(jiān)測與安防終端采集溫度、濕度、煙霧濃度、火焰信號和人體入侵信號超限時聲光告警同時驅動排風扇等執(zhí)行設備。代碼、原理圖、Proteus仿真全部開源適合正在找STM32項目練手的嵌入式學習者也適合想做農(nóng)業(yè)物聯(lián)網(wǎng)課程設計或者小規(guī)模糧倉改造的工程師參考。項目本身不復雜但把“環(huán)境監(jiān)測”和“安防”兩套邏輯完整地揉進一個STM32F103C8T6里涉及到的單總線時序、ADC采集、多路告警調(diào)度和仿真聯(lián)調(diào)都值得掰開揉碎講一遍。1.1 溫度和濕度是糧食安全的頭號殺手糧食在存儲過程中最核心的生命活動是呼吸作用。溫度每升高10℃糧食呼吸強度大概會翻倍呼吸消耗干物質不說還會釋放水分和熱量讓糧堆局部“出汗”。當溫度掉到25℃以上、相對濕度超過70%的時候霉菌和儲糧害蟲的繁殖速度會進入指數(shù)區(qū)間。換句話說糧倉里最需要盯的兩個指標就是溫度和濕度這倆數(shù)據(jù)一旦越線霉變和蟲害幾乎不可避免。傳統(tǒng)做法是保管員每天定時拿手持溫濕度計逐倉巡查記錄成紙質表格。這里有兩個致命問題一是夜間和非工作時間出現(xiàn)溫濕度異常根本沒人知道等第二天開門已經(jīng)晚了二是大倉不同部位溫濕度差異很大單點手持測量覆蓋不全。這套系統(tǒng)在每個監(jiān)控節(jié)點實時采集溫濕度超過閾值立刻告警等于把“人盯數(shù)據(jù)”變成了“系統(tǒng)盯數(shù)據(jù)”。1.2 煙霧、火焰、非法入侵安防的另一半糧倉的安防需求很容易被忽略。糧粉在特定濃度下是易燃易爆的電氣線路老化、人員違規(guī)吸煙都有可能引發(fā)火情同時糧倉一般位置偏遠夜間防盜壓力也不小。單純做“環(huán)境監(jiān)測”不做“安防”只能算完成了一半。所以這套系統(tǒng)在溫濕度采集之外增加了三個安防維度煙霧濃度檢測通過MQ-2氣體傳感器實時監(jiān)測煙霧發(fā)生火情時能在早期發(fā)現(xiàn)?；鹧鏅z測紅外火焰?zhèn)鞲衅髯R別火光作為煙霧告警的交叉驗證減少誤報。人體入侵檢測被動式紅外熱釋電傳感器HC-SR501感知闖入者夜間告警提醒值守人員。四路信號在STM32里統(tǒng)一調(diào)度用不同的告警策略區(qū)分“環(huán)境異常”和“安防事件”這樣不會一有風吹草動就亂響也不會漏報真正的問題。這個需求拆解的過程恰恰是很多教程沒講透的部分——拿到原理圖先別急著畫板子先搞清楚系統(tǒng)到底要感知哪些物理量。2. 系統(tǒng)架構與硬件選型這套方案為什么這么配硬件選型是項目能不能順利跑起來的第一道坎。很多初學者一上來就想上頂級芯片結果外圍電路復雜、調(diào)試困難項目爛尾。這套系統(tǒng)選件的基本原則是在滿足性能的前提下優(yōu)先選資料多、成本低、容易買到的器件。2.1 主控選型STM32F103C8T6憑什么夠用主控選了STM32F103C8T6這是一顆基于ARM Cortex-M3內(nèi)核的芯片主頻72MHz64KB Flash20KB SRAM。有人會問糧倉監(jiān)測是不是得用更高端的芯片來保證可靠性實測下來的結論是沒必要。從資源占用角度算一筆賬資源用途占用情況GPIODHT11、LCD1602/OLED、按鍵、LED約15個引腳ADCMQ-2煙霧傳感器模擬輸出1個通道定時器系統(tǒng)節(jié)拍、延時延時1-2個串口調(diào)試日志輸出1個把這些全部算進去Flash和SRAM的占用率都不超過一半余量足夠后續(xù)擴展。而且這顆芯片可以說是STM32生態(tài)里資料最豐富、Proteus仿真支持最成熟的型號之一遇到問題搜解決方案一搜一大把非常適合作為教學和工程驗證的載體。2.2 傳感器與執(zhí)行器選型清單整個系統(tǒng)的硬件清單如下模塊型號/方案作用選型理由溫濕度采集DHT11采集溫度和相對濕度單總線協(xié)議接線簡單夠用煙霧檢測MQ-2檢測煙霧/可燃氣濃度模擬數(shù)字雙輸出靈敏度可調(diào)火焰檢測紅外火焰?zhèn)鞲衅髂K識別火光數(shù)字電平輸出接口簡單人體感應HC-SR501感知人體紅外輻射被動式熱釋電誤報率低顯示LCD1602或OLED SSD1306本地顯示溫濕度與告警狀態(tài)16x2字符顯示調(diào)試直觀告警有源蜂鳴器 LED聲光告警有源蜂鳴器單片機直接驅動不了需要三極管輸出控制繼電器模塊驅動排風扇隔離大負載安全可靠電源USB 5V AMS1117-3.3V系統(tǒng)供電穩(wěn)壓簡單成本極低這里重點解釋一下DHT11和DHT22的選擇。DHT11的精度是±2℃、±5%RH在糧倉這種場景下夠不夠坦白說做精細化糧庫監(jiān)測這個精度偏粗更推薦DHT22±0.5℃、±2%RH。但DHT11的優(yōu)勢在于單總線時序簡單、代碼量小、仿真模型成熟作為項目學習和技術驗證完全夠用。如果需要高精度方案軟件層只需要替換驅動函數(shù)上層邏輯不用動——這也是把傳感器驅動和業(yè)務邏輯分開寫的價值所在。2.3 整體工作流程系統(tǒng)上電后先自檢初始化LCD顯示啟動界面然后進入主循環(huán)定時器產(chǎn)生2秒節(jié)拍觸發(fā)溫濕度采集DHT11的數(shù)據(jù)手冊要求兩次讀取間隔大于1秒太頻繁會讀取失敗。周期性讀取煙霧濃度ADC值檢測火焰?zhèn)鞲衅骱腿梭w感應模塊的電平狀態(tài)。將采集數(shù)據(jù)刷新到LCD。在告警判斷函數(shù)里做閾值比較和消抖處理。超限時觸發(fā)聲光告警并通過繼電器啟動排風扇/打開應急照明。這套流程的邏輯非常清晰后面代碼部分會詳細展開。3. 原理圖設計每個模塊背后的設計邏輯原理圖是這套系統(tǒng)最容易被“抄完就忘”的部分。很多人拿到原理圖直接用但不知道為什么這里要加上拉電阻、那里要加RC濾波。把這些設計邏輯講清楚才是真正吃透項目。3.1 電源與最小系統(tǒng)穩(wěn)定是底線電源部分采用了USB 5V輸入 AMS1117-3.3V穩(wěn)壓的方案。為什么不用ST-Link直接給3.3V因為MQ-2的加熱回路需要5V供電DHT11和LCD1602的典型工作電壓也是5V所以系統(tǒng)必須同時存在5V和3.3V兩路電源。AMS1117-3.3的輸出端要加10uF和100nF去耦電容一個負責低頻穩(wěn)壓一個負責高頻噪聲濾除。STM32F103C8T6的每個VDD引腳旁邊也建議就近放一個100nF去耦電容這是很多初學者容易漏掉的小細節(jié)不加也能跑但ADC采樣精度和系統(tǒng)穩(wěn)定性會打折扣。最小系統(tǒng)部分有幾個關鍵字——8MHz外部晶振配兩個22pF負載電容、復位電路用10k上拉電阻加100nF電容、BOOT0和BOOT1通過10k下拉電阻接地保證從Flash啟動、SWD下載口引出PA13/PA14。這里特別提醒一點SWD接口一定要把GND也引出來否則下載器經(jīng)常連不上目標板。3.2 傳感器接口電路上拉、分壓、隔離DHT11的輸出引腳是漏極開路結構數(shù)據(jù)線上需要接一個4.7k-10k的上拉電阻到VCC。上拉電阻太小會讓總線驅動能力不足太大會導致上升沿變緩實測4.7k最穩(wěn)。MQ-2模塊的AO引腳輸出的是模擬電壓直接接到STM32的PA1引腳即可。但注意MQ-2的AO輸出范圍是0-5V而STM32的ADC輸入范圍是0-3.3V——市售MQ-2模塊上往往自帶一個可調(diào)電位器和比較器模塊的DO輸出是TTL電平可以直接接但AO輸出直接接ADC引腳是有風險的。穩(wěn)妥的做法是用兩個電阻做分壓比如10k和20k串聯(lián)將5V分壓到3.3V以內(nèi)或者直接購買3.3V兼容版的MQ-2模塊。HC-SR501的輸出是3.3V兼容的數(shù)字電平可以直接接GPIO。這個模塊上有兩個可調(diào)電位器分別調(diào)節(jié)感應距離0-7米和延時時間5秒-300秒用在糧倉安防場景建議把延時調(diào)到最小、靈敏度調(diào)到中間檔。3.3 告警與驅動電路GPIO怎么帶動大負載STM32的GPIO最大輸出電流只有約20mA直接驅動蜂鳴器和繼電器的線圈肯定不夠必須加驅動電路。蜂鳴器用S8050 NPN三極管驅動GPIO通過1k基極電阻接三極管基極蜂鳴器接在集電極和VCC之間發(fā)射極接地。GPIO輸出高電平時三極管導通蜂鳴器響起。繼電器驅動用的是ULN2003達林頓管陣列這個芯片內(nèi)部自帶續(xù)流二極管可以直接驅動繼電器線圈。這里有一個反復被問的問題為什么不用三極管因為繼電器線圈是感性負載斷電瞬間會產(chǎn)生很高的反向電動勢如果不加續(xù)流二極管會擊穿驅動管。ULN2003內(nèi)部集成了這個保護設計上省心很多。如果是單路繼電器用一個NPN三極管加一個1N4007續(xù)流二極管也完全可以。4. 代碼實現(xiàn)驅動、調(diào)度與告警邏輯整套代碼是在Keil MDK5環(huán)境下基于STM32標準外設庫完成的。工程結構分為四層硬件驅動層DHT11、ADC、LCD、業(yè)務邏輯層采集任務、告警任務、調(diào)度層主循環(huán)定時器標志位、配置層時鐘、GPIO、中斷初始化。4.1 工程結構與代碼布局建議的工程文件組織方式文件/文件夾職責core/啟動文件、系統(tǒng)時鐘配置user/main.c、stm32f10x_it.c 中斷服務函數(shù)hardware/dht11.c、adc.c、lcd1602.c、alarm.c、key.csystem/系統(tǒng)初始化、延時函數(shù)把硬件驅動和業(yè)務邏輯分開最大的好處是換傳感器或者改邏輯時不用動底層驅動。比如從DHT11換成DHT22只需要重寫dht11.c里的讀寫時序上層調(diào)用函數(shù)接口不變。4.2 DHT11單總線時序的軟件實現(xiàn)DHT11的時序是整個代碼里最講究的部分。單總線協(xié)議沒有時鐘線靠嚴格的延時和電平翻轉來傳輸數(shù)據(jù)容錯窗口通常在10-30us級別所以延時函數(shù)的精度直接影響通信成敗。讀取一次溫濕度的完整流程主機把總線拉低至少18ms發(fā)出起始信號。主機釋放總線并延時20-40us等待DHT11響應。DHT11拉低總線80us作為應答然后拉高80us表示即將發(fā)送數(shù)據(jù)。隨后DHT11依次發(fā)送40位數(shù)據(jù)8位濕度整數(shù)、8位濕度小數(shù)、8位溫度整數(shù)、8位溫度小數(shù)、8位校驗和。每位數(shù)據(jù)的解碼規(guī)則是先有50us低電平緊接著高電平。高電平持續(xù)26-28us表示邏輯0高電平持續(xù)70us表示邏輯1。核心讀取代碼uint8_t DHT11_ReadByte(void) { uint8_t i, data 0; for (i 0; i 8; i) { // 等待50us低電平結束 while (DHT11_PIN 0); // 延時約30us后采樣電平 Delay_us(30); if (DHT11_PIN 1) { data (data 1) | 0x01; } else { data (data 1) 0xFE; } // 等待高電平結束 while (DHT11_PIN 1); } return data; }讀取完整數(shù)據(jù)的流程uint8_t DHT11_ReadData(uint8_t *temp, uint8_t *humi) { uint8_t buf[5]; uint8_t i; // 主機拉低至少18ms發(fā)送起始信號 DHT11_PIN_OUT(); DHT11_PIN_LOW(); Delay_ms(20); DHT11_PIN_HIGH(); Delay_us(30); DHT11_PIN_IN(); // 檢查DHT11應答信號 if (DHT11_PIN 1) return 1; // 無應答 while (DHT11_PIN 0); // 等待應答低電平結束 while (DHT11_PIN 1); // 等待高電平結束 // 連續(xù)讀取5字節(jié)含校驗 for (i 0; i 5; i) { buf[i] DHT11_ReadByte(); } // 校驗和驗證 if (buf[4] ! (buf[0] buf[1] buf[2] buf[3])) return 2; // 校驗失敗 *humi buf[0]; *temp buf[2]; return 0; }這個代碼里有幾個細節(jié)值得注意一是Delay_us(30)必須放在判斷之前放在判斷之后讀到的高電平就包含了70us和26us兩種可能無法區(qū)分0和1二是主循環(huán)調(diào)用DHT11的間隔不能小于1秒否則傳感器無法完成內(nèi)部測量會一直返回0。這也是為什么把采集放到2秒定時器節(jié)拍里。4.3 ADC采樣與煙霧濃度換算MQ-2的AO輸出接到STM32的PA1引腳對應的ADC通道是ADC1_IN1。配置ADC1工作在連續(xù)轉換模式采樣時間為55.5周期確保阻抗匹配。讀取代碼uint16_t ADC_ReadChannel(uint8_t channel) { ADC1-SQR3 channel; // 選擇轉換通道 ADC1-CR2 | (uint32_t)1 22; // 啟動轉換 while (!(ADC1-SR (1 1))); // 等待轉換完成 return ADC1-DR; // 返回12位ADC值 }煙霧濃度的判斷不能只看單次ADC值。MQ-2在剛上電的幾十秒內(nèi)讀數(shù)會飄因為內(nèi)部加熱絲需要時間達到工作溫度。我的做法是在開機后等待MQ-2預熱完成約60秒啟動時保存一個基線值然后用當前讀數(shù)相對基線的偏差作為判斷依據(jù)這樣可以抵消不同環(huán)境下的濃度基準差異。uint8_t SMOKE_GetLevel(uint16_t baseline, uint16_t current) { // 偏差超過200個ADC碼值認為有煙霧 if (current baseline 200) return 1; return 0; }4.4 告警消抖與狀態(tài)機設計告警邏輯最容易犯的錯誤是一讀到超限就立刻觸發(fā)告警。傳感器瞬間波動、電磁干擾、甚至灰塵飄過探測口都會造成毛刺直接觸發(fā)的后果就是蜂鳴器亂叫值守人員很快就會失去信任。所以告警函數(shù)里做了一次數(shù)值消抖連續(xù)3次采樣都超限才確認告警。void Alarm_Task(void) { static uint8_t confirm_count 0; uint8_t danger 0; // 條件判斷 if (temp TEMP_ALARM_THRESHOLD || humi HUMI_ALARM_THRESHOLD || smoke_adc smoke_baseline SMOKE_DEVIATION || fire_detected || pir_detected) { confirm_count; if (confirm_count 3) { danger 1; } } else { confirm_count 0; } if (danger) { Alarm_On(); // 蜂鳴器響、LED閃爍、繼電器動作 } else { Alarm_Off(); } }同時不同的告警源應該有不同的表現(xiàn)方式。溫濕度超限屬于“環(huán)境預警”蜂鳴器慢速間歇鳴響煙霧和火焰屬于“火情告警”蜂鳴器快速長鳴人體入侵屬于“安防事件”蜂鳴器短促三聲循環(huán)。這樣值守人員光聽聲音就能判斷現(xiàn)場出了什么類型的問題不用每次跑過去看屏幕。5. Proteus仿真從工程到跑通的完整過程Proteus仿真最大的價值在于可以不焊接一塊板子就把代碼邏輯驗證一遍。但這個環(huán)節(jié)恰恰是無數(shù)人卡殼的地方——很多人連仿真圖都搭不起來。下面把從我這邊實測跑通的完整流程拆開講。5.1 仿真環(huán)境的搭建與元件準備Proteus版本建議用8.9以上對STM32F103C8T6的支持比較完善。新建工程后在元件搜索欄里依次添加搜索關鍵字元件說明STM32F103C8T6MCU主控在“ST Microcontrollers”分類下DHT11溫濕度傳感器舊版本Proteus沒有需要更新庫文件LM016LLCD1602液晶屏標準字符液晶模型MQ-2氣體傳感器部分版本用MQ-2模型或電壓源替代BUZZER有源蜂鳴器需要配合三極管驅動LED-RED / LED-GREEN指示燈告警狀態(tài)顯示RESISTOR / CAPACITOR電阻電容按原理圖參數(shù)設置BUTTON按鍵閾值設置/復位POT-HG電位器LCD對比度調(diào)節(jié)如果搜索不到DHT11有一個替代思路用兩個電壓源模擬DHT11輸出或者用Proteus自帶的DHT55傳感器模型來驗證邏輯。但這樣沒法驗證時序代碼對不對所以還是建議安裝帶完整元件庫的版本或者從Proteus官網(wǎng)更新庫文件。5.2 編譯生成hex并加載到Proteus代碼在Keil里編譯生成hex文件的方法在Keil工程中點擊魔術棒Options for Target。在Output選項卡勾選“Create HEX File”。編譯工程在輸出目錄下生成.hex文件。然后在Proteus中雙擊STM32F103C8T6元件在彈出的屬性對話框里將Program File路徑指向剛生成的hex文件。這里要注意兩個坑Crystal Frequency設置必須設置為8MHz與工程代碼里的SystemInit配置的外部晶振一致。如果設為默認值0仿真時鐘直接亂了延時函數(shù)會出錯。電源引腳Proteus的STM32模型雖然會自動供電但如果仿真中使用了PA0等模擬輸入引腳記得在VSSA/VDDA引腳上正確接電源否則ADC讀到的數(shù)據(jù)是亂的。加載完成后點擊運行。正常的現(xiàn)象是LCD顯示當前溫度和濕度調(diào)節(jié)仿真中的DHT11濕度值或溫度值LCD數(shù)據(jù)跟著變化按下對應按鍵觸發(fā)超限蜂鳴器和LED開始告警。5.3 仿真中踩到的三個坑第一個坑是DHT11仿真時序與實物不一致。Proteus的DHT11模型對延時的敏感度比實物更高實物上30us的容錯窗口在仿真里可能只有10us。解決方法是微調(diào)代碼里的延時參數(shù)把Delay_us(30)改成Delay_us(50)左右前提是你用的是帶仿真模型的DHT11。如果怎么調(diào)都讀不到數(shù)據(jù)還有一個土辦法把DHT11換成兩個可變電阻模擬溫濕度變化用ADC讀取來代替單總線讀取先把整體流程跑通再回來搞時序。第二個坑是LCD1602顯示亂碼或全屏方塊。最常見原因是仿真里LCD的對比度調(diào)節(jié)引腳Vo直接接地了沒有接電位器。加上一個10k電位器把Vo電壓調(diào)到1V左右LCD工作電壓的10%-20%顯示就正常了。第三個坑是蜂鳴器不響。Proteus里的蜂鳴器分有源和無源兩種有源蜂鳴器只要通電就會發(fā)聲無源需要PWM才能響。仿真里如果上電不響先檢查型號是不是SOUNDER有源/無源模型不同再看驅動管是否型號匹配。這里有一個小技巧Proteus仿真的蜂鳴器很多時候是“邏輯上已經(jīng)響起、但電腦聲卡沒輸出”——看仿真里的電流表和驅動管狀態(tài)就能確認。6. 從仿真到實物部署經(jīng)驗與擴展方向仿真跑通只是完成了一半實物搭建和現(xiàn)場部署才是真正檢驗系統(tǒng)可靠性的地方。這個環(huán)節(jié)有很多仿真里根本不會暴露的問題非常值得單獨拿出來說。6.1 實物搭建中容易被忽略的細節(jié)DHT11在實物調(diào)試里的頭號問題是IO口方向切換的時序。STM32的GPIO配置為輸入和輸出之間切換需要大約幾個時鐘周期標準外設庫里的GPIO_Init調(diào)用開銷比較大。一個可行的做法是把DHT11的數(shù)據(jù)線接到一個獨立IO用寄存器操作快速切換方向#define DHT11_PIN_OUT() { GPIOB-CRH 0xFFFF0FFF; GPIOB-CRH | 0x00003000; } #define DHT11_PIN_IN() { GPIOB-CRH 0xFFFF0FFF; GPIOB-CRH | 0x00004000; }這樣配置方向只需要兩條寄存器指令比調(diào)用庫函數(shù)快幾十倍實測在48MHz主頻下能穩(wěn)定讀取DHT11。第二個是供電問題。MQ-2的加熱絲最大工作電流在150mA左右如果和STM32共用一組USB供電電源線上的紋波會影響到ADC采樣。建議的做法是MQ-2單獨從5V端取電并在模塊電源引腳就近加一個100uF電解電容和一個104瓷片電容把加熱絲的瞬態(tài)電流波動吸收掉。第三個是繼電器帶負載的問題。繼電器觸點驅動排風扇這種感性負載時觸點閉合斷開的瞬間會產(chǎn)生電弧長期使用會造成觸點燒蝕。在繼電器輸出端并聯(lián)一個RC吸收電路典型值100Ω 104電容串聯(lián)能有效延長繼電器壽命。6.2 糧倉現(xiàn)場的實用建議如果這套系統(tǒng)真的要用在糧倉環(huán)境里有幾個點比代碼和原理圖更關鍵傳感器的布點位置不能只放一個點。糧倉的不同高度和位置溫濕度差異很大靠近門窗的位置濕度高、糧堆中心溫度高。至少要在倉內(nèi)東南西北四個角落各裝一個節(jié)點再在糧堆表層和距表層50cm深處各埋一個測溫點才能形成有效的監(jiān)測網(wǎng)絡。這套單節(jié)點方案可以作為每個點位的基礎單元后續(xù)通過RS485總線把多個節(jié)點組網(wǎng)把數(shù)據(jù)匯總到上位機。傳感器的防護很關鍵。糧倉內(nèi)粉塵濃度高DHT11的感濕元件如果直接裸露在環(huán)境里用不了幾個月就會被粉塵覆蓋測量值嚴重偏移。建議給傳感器加一個透氣防塵罩或者把傳感器放在一個開有小孔的塑料盒子里。MQ-2也面臨同樣的問題它的防爆網(wǎng)罩結構本身能防塵但網(wǎng)罩上的粉塵也需要定期清理。告警閾值不能拍腦袋定。不同的糧食品種對溫濕度要求不同小麥的安全水分是12.5%左右稻谷是14%左右對應的倉儲環(huán)境濕度閾值最好參考《糧油儲藏技術規(guī)范》來設置。我預留了通過按鍵調(diào)節(jié)閾值的功能就是為了讓使用者根據(jù)實際存儲品種靈活調(diào)整。6.3 后續(xù)擴展方向這套系統(tǒng)在擴展性上留了很多接口。軟件層面主循環(huán)的調(diào)度結構可以很容易地加入新傳感器——只需要在硬件驅動層增加一個文件在Alarm_Task里增加一個判斷條件。硬件層面如果要做遠程監(jiān)控可以在串口1上掛一個ESP8266模塊把溫濕度和告警狀態(tài)通過MQTT協(xié)議上報到云平臺實現(xiàn)手機遠程查看。要做低功耗的話STM32F103C8T6可以進入待機模式配合RTC定時喚醒用外部中斷喚醒做入侵檢測一塊18650電池可以支持幾個月。如果要組網(wǎng)做多節(jié)點方案建議把通信鏈路從單總線換成RS485DHT11的數(shù)據(jù)通過傳感器節(jié)點上的小MCU預處理后再通過RS485總線上傳。這樣既解決了長距離布線的抗干擾問題也讓每個節(jié)點具備本地獨立判斷能力不會因為總線上某個節(jié)點故障而影響整個網(wǎng)絡。我在實際做的過程中最大的感受是仿真和實物之間的差距就是理論學習和工程實踐的差距。仿真幫你驗證了邏輯但實物會告訴你什么是電源紋波、什么是時序容錯、什么是接觸不良。這套系統(tǒng)從畫原理圖到最終在糧庫角落穩(wěn)定運行前前后后調(diào)試了將近兩周踩的坑遠比這篇文章里寫得多。但正是因為這些坑整個系統(tǒng)的每一行代碼、每一顆電阻的取值才能講得清楚來龍去脈。這也是我決定把它們整理成開源項目的初衷——不要讓后人重復踩同樣的坑。