樊星男

（太原學院 機械與電氣工程系，太原030032）

溫濕度監(jiān)控在農業(yè)、醫(yī)療、建筑、文物保存和檔案管理等領域都有廣泛的應用[1]。傳統(tǒng)的有線布線方式應用在較大空間范圍內進行多點分布式測量時容易對空間內建筑造成損壞，影響美觀且費用較高。因此，設計一個組網方便、數據傳輸及時可靠的分布式無線溫濕度采集系統(tǒng)具有良好的實用價值。

隨著物聯(lián)網技術的不斷成熟和發(fā)展，針對上述需求，在此采用ZigBee 無線局域網實現多點分布式溫濕度測量，采用WiFi 無線局域網實現數據與上位機之間的無線的傳輸。ZigBee 技術是一種近距離、低復雜度、低功耗、低速率、低成本的雙向無線通訊技術，其使用的2.4 GHz 頻段全球通用[2]；WiFi技術是目前應用非常廣泛的一種無線上網技術，通過傳輸控制協(xié)議TCP（transmission control protocol）連接，可以方便、穩(wěn)定地實現溫濕度監(jiān)測系統(tǒng)與上位機軟件的數據通信。

1 系統(tǒng)整體設計

所設計的基于ZigBee 和WiFi 的溫濕度無線監(jiān)測系統(tǒng)，上位機軟件采用VB 6.0 設計開發(fā)，可以實時地將數據顯示到界面上，同時還可以將數據保存到Access 數據庫中，方便查詢歷史數據；針對WiFi局域網中IP 地址不固定導致TCP 無法連接問題，上位機軟件利用用戶數據報協(xié)議UDP（user datagram protocol）組播實現了“系統(tǒng)發(fā)現”功能，當監(jiān)測系統(tǒng)的WiFi 模塊和上位機軟件在同時接入IP 局域網的情況下，二者之間能自動地建立TCP 連接而無需進行IP 地址設置等操作。

該監(jiān)測系統(tǒng)由監(jiān)測終端節(jié)點、 協(xié)調器、WiFi 模塊和上位機軟件等4 個部分組成。①監(jiān)測終端根據預設參數接入ZigBee 局域網，實時監(jiān)測被測空間的溫度和濕度并將數據送到協(xié)調器；②協(xié)調器根據預設參數建立ZigBee 局域網，接收各終端發(fā)送來的數據，并將數據通過串口發(fā)送到WiFi 模塊；③WiFi 模塊根據預設值接入WiFi 網絡，然后通過 “系統(tǒng)發(fā)現”功能連接到遠端的TCP 服務器，并將從串口接收到的數據發(fā)送到遠端；④上位機軟件建立TCP 服務器，并通過“系統(tǒng)發(fā)現”功能將自身的IP 地址和TCP 服務器端口號發(fā)送到WiFi 模塊，當建立TCP連接后將TCP 客戶端發(fā)送來的數據實時顯示到界面，同時將這些數據保存到數據庫。系統(tǒng)的整體設計框圖如圖1所示。

圖1 無線監(jiān)測系統(tǒng)整體設計框圖Fig.1 Overall design block diagram of wireless monitoring system

2 系統(tǒng)硬件設計

2.1 終端節(jié)點硬件設計與實現

終端節(jié)點的硬件組成如圖2所示，終端節(jié)點由CC2530、傳感器、指示、電源、串口及天線等6 個模塊組成。

圖2 終端節(jié)點的硬件構成Fig.2 Hardware composition of terminal node

CC2530 是一個ZigBee 片上解決方案芯片，該芯片結合領先的RF 收發(fā)器，內有一個業(yè)界標準的增強型8051CPU，系統(tǒng)內8 kB 運存、256 kB 閃存。該芯片還結合了德州儀器的ZigBee 協(xié)議棧Z-Stack，提供了一個強大和完整的ZigBee 解決方案[3-4]。

節(jié)點傳感器模塊選用SHT11 溫濕度傳感器。該傳感器將溫濕度檢測、信號放大調理、A/D 轉換、I2C總線、CRC 數據校驗集于一體，能夠實現溫濕度值的精確測量和傳輸[5-6]。SHT11 與CC2530 電路原理如圖3所示。

圖3 SHT11 電路連接原理Fig.3 Principle of SHT11 circuit connection

電源和串口模塊選用PL2303 芯片。該芯片是一個高度集成的RS232-USB 接口轉換器，解決了PC 上只有USB 口而沒有RS232 口的問題，同時也解決了供電問題，利用常見的5 V 輸出電源適配器就能供電。用戶通過這個串口可以使用PC 設置終端節(jié)點的一些運行參數。

指示模塊包括LED1 和LED2 指示燈，當節(jié)點通電后LED1 常亮，當節(jié)點接入ZigBee 網絡后LED2常亮，否則LED2 周期閃爍[7]。

2.2 協(xié)調器節(jié)點硬件設計與實現

協(xié)調器節(jié)點硬件組成如圖4所示，協(xié)調器節(jié)點的硬件組成與終端節(jié)點基本一致。為了能夠方便對協(xié)調器進行設置，在串口部分使用了跳線，協(xié)調器串口跳線原理如圖5所示。當開關撥到上部時，PL2303 與CC2530 相連，實現上位機對CC2530 的設置；當開關撥動到中部是CC2530 與RTL8710 相連，實現CC2530 和RTL8710 的數據傳輸；當開關撥動到下部時，PL2303 與RTL8710 相連，實現上位機對RTL8710 的設置。系統(tǒng)正常工作時應將開關撥到中部位置。當協(xié)調器通電后LED1 常亮，當協(xié)調器創(chuàng)建網絡完畢后LED2 常亮，否則LED2 周期閃爍。

圖4 協(xié)調器節(jié)點硬件組成Fig.4 Hardware composition of coordinator node

圖5 協(xié)調器串口跳線原理Fig.5 Principle of coordinator serial port jump

2.3 WiFi 模塊硬件設計與實現

WiFi 模塊硬件組成如圖6所示。WiFi 模塊采用RTL8710 芯片，該芯片集成了一個ARM Cortex M3 MCU，802.11n 無線網絡控制器，串口等外設于一體，內置了輕量級TCP/IP 協(xié)議，為一個完整且自成體系的WiFi 網絡解決方案。

圖6 WiFi 模塊硬件組成Fig.6 Hardware composition of WiFi module

3 系統(tǒng)軟件設計

3.1 終端節(jié)點軟件設計與實現

當終端節(jié)點上電后，首先從Flash 固定地址讀取系統(tǒng)參數，如果能正常讀取且校驗成功則使用參數進行系統(tǒng)初始化，如果不能正常讀取則等待串口命令。終端節(jié)點的串口只有在設置系統(tǒng)參數時與PC連接，PC 按照一定的數據格式向節(jié)點發(fā)送命令，數據格式見表1。

表1 數據包格式Tab.1 Packet format

根據數據包格式，整個數據包以“幀頭”0x1B 開始?！邦愋汀北硎緮祿念愋?，如0x00 表示當前數據包是溫濕度值（該數據格式同樣用于ZigBee 數據傳輸）；0x01 表示當前數據包是設置設備編號參數?！伴L度”表示數據包中數據內容的長度，一個完整的數據包長度為（N+4）B。“凈荷”為實際傳輸的數據內容，在應用中根據需要可以繼續(xù)擴展，如在傳輸溫濕度值時凈荷的首字節(jié)用于表示設備編號，其后才是溫濕度測量值。“校驗位”為該字節(jié)前面（N+3）B數據之和的最低位字節(jié)。

當參數檢查通過后，終端節(jié)點進入正常程序運行，流程如圖7所示，定時器設置為10 s。

圖7 終端節(jié)點程序流程Fig.7 Terminal node program flow chart

SHT11 傳感器輸出的溫度數據需要經過一定的轉換才能使用。

①溫度轉換公式

式中：T 為溫度值，℃；SoT為主控芯片從SHT11 中讀取到的溫度數據；d1和d2為溫度轉換系數，其取值見表2。

表2 溫度轉換系數Tab.2 Temperature conversion coefficient

②相對濕度轉換公式

式中：RHlinear為相對濕度；SoRH為主控芯片從SHT11中讀取到的濕度數據；c1，c2和c3為濕度轉換系數，其取值見表3。

③溫度補償公式 由于濕度的測量受溫度影響，所以在測量濕度時還應考慮到傳感器的溫度補償。該補償公式為

式中：RHtrue為絕對濕度；t1，t2為溫度補償系數，其取值見表3。

表3 濕度轉換系數和溫度補償系數Tab.3 Humidity conversion coefficient and temperature compensation coefficient

結合該系統(tǒng)設計，SHT11 電壓VDD為3.5 V，溫度精度SoT為14 bit，濕度精度SoRH為12 bit，將系數結果代入式（1）—（3），可得

3.2 協(xié)調器軟件設計與實現

協(xié)調器是整個ZigBee 網絡的核心，它需要具有創(chuàng)建ZigBee 網絡，為節(jié)點分配地址，將從節(jié)點收到的數據通過串口透傳到WiFi 模塊，等功能，此外協(xié)調器同樣支持從串口接收PC 命令。其命令格式同表1，協(xié)調器軟件流程如圖8所示。

圖8 協(xié)調器程序流程Fig.8 Coordinator program flow chart

3.3 WiFi 模塊軟件設計與實現

WiFi 模塊是ZigBee 網絡和IP 網絡的轉換模塊，它將ZigBee 協(xié)調器發(fā)來的數據通過TCP 連接發(fā)送到上位機，同時WiFi 模塊還是“系統(tǒng)發(fā)現”功能的客戶端。WiFi 模塊程序流程如圖9所示。

圖9 WiFi 模塊程序流程Fig.9 WiFi module program flow chart

傳統(tǒng)的服務調用需要客戶端明確知道目標服務的地址，并基于這個地址創(chuàng)建服務調用。但是目前網絡接入設備和路由設備之間一般均為動態(tài)路由，所以網絡接入設備的IP 地址不固定，而IP 地址一旦發(fā)生變化就會使客戶端與服務器之間的服務調用無法建立。故在此設計了“系統(tǒng)發(fā)現”功能，即以WS_Discovery 機制Ad_Hoc 操作模式為基礎，通過簡化其協(xié)商流程和內容而來。

標準WS_Discovery（web services dynamic discovery）由服務器端（WS_Serve）和客戶端（WS_Client）組成。其協(xié)商流程如圖10所示。

圖10 WS_Discovery 協(xié)商流程Fig.10 WS_Discovery negotiation flow chart

當服務器啟動后，通過UDP 廣播定時向網絡發(fā)送Hello 消息報文，客戶端收到該報文后通過UDP廣播發(fā)送Probe 消息報文，該消息中包含客戶端所需要調用的服務；而服務端在收到Probe 消息后首先判斷能否滿足該消息中的條件，如果可以滿足則通過UDP 單播的形式向該客戶端發(fā)送PM（probe match）消息，該消息中包含目標服務的相關信息。當客戶端收到PM 消息后，就根據消息中攜帶的信息與目標服務建立連接，而如果客戶端從PM 消息中得到的信息還不足以建立服務，就會進一步向服務器發(fā)送Resolve 消息，并在消息中攜帶想要向服務器查詢的內容，服務器則會回復RM（resolve match）消息并在消息中攜帶被查詢內容；當服務器下線時，會向客戶端發(fā)送Bye 消息，通知客戶端服務停止。

標準WS_Discovery 機制需要經過多次消息交換，而且是以簡單對象訪問協(xié)議SOAP（simple object access protocol）對協(xié)商內容進行封裝，此協(xié)議為一種基于XML 的文本協(xié)議，因此會使得協(xié)商時數據量較大進而增加WiFi 模塊的內存負擔。所以，“系統(tǒng)發(fā)現”功能首先將協(xié)商流程簡化，并且將協(xié)商內容由文本變?yōu)槎M制，其消息格式同表1。

WiFi 模塊啟動后，創(chuàng)建UDP 并監(jiān)聽3700 端口（標準WS_Discovery 為3702）；當上位機啟動后，會通過UDP 定時向239.255.255.250 地址的3700 端口發(fā)送Hello 消息；當WiFi 模塊收到此消息，向服務器回復Probe 消息，該消息攜帶有與服務器約定好的服務編號；上位機收到Probe 消息并判斷服務編號是否合法，如果合法則向WiFi 模塊回復PM 消息，并在消息中攜帶TCP 連接的IP 地址和和端口號。WiFi 模塊收到PM 消息后就可以與TCP 服務器建立服務連接。

“系統(tǒng)發(fā)現” 功能消息的示例見表4。表中，1B為幀頭；A1，A2，A3 分別表示Hello 消息、Probe 消息、PM 消息的類型；類型字段后面給出消息凈荷的長度；各條消息的最后一個字節(jié)為校驗字節(jié)。

表4 “系統(tǒng)發(fā)現”協(xié)商消息示例Tab.4 Example of “system discovery”negotiation message

由表可知，Probe 示例消息中，客戶端所攜帶的服務編碼為000103040A0D0708；PM 示例消息中，TCP服務器的IP 地址為192.168.0.100，端口號為1000。

3.4 上位機軟件設計與實現

上位機軟件使用VB 進行設計，主要功能有數據校準和數據保存。

SHT11 在測量過程中，受到環(huán)境、電路的干擾，以及測量數據由多位小數向1 位小數轉換的過程會導致測量數據精度降低，與真值之間出現偏差[8]。為了校準該偏差，在此選用精創(chuàng)公司的工業(yè)級溫濕度記錄儀RC-4HC 的測量數據作為約定真值，通過大量的試驗比較SHT11 與RC-4HC 之間的測量數據，發(fā)現兩者之間確實存在一個較為穩(wěn)定偏差，而且不同的SHT11 與RC-4HC 之間的偏差值也有所不同，測量數據見表5。

表5 SHT11 與RC-4HC 的測量數據Tab.5 Measurement data of SHT11 and RC-4HC

通過計算測量值、真值和誤差的平均值，在測量值的基礎上再減去一個平均誤差值，從而極大地降低整體誤差。由表可知，溫度平均誤差為-0.19，取值為-0.2；濕度平均誤差-0.95，取值為-1。所以使用校準公式對測量值Tc和RHc進行校準，即：

上位機軟件的數據保存功能采用了VB 中Adodb 控件與Access 數據庫連接[9-10]。Access 數據庫共設計2 個表，分別用于保存測點參數、測點數據，見表6和表7。其中，表6的主鍵為測點號，表7的主鍵為編號。

表6 測點參數記錄Tab.6 Parameter record of measuring point

表7 測點數據記錄Tab.7 Data record of measuring point

4 測試結果及分析

系統(tǒng)最多有6 個測點，啟用3 個測點進行丟包測試。將3 個測點分別置于協(xié)調器周圍100 m 范圍內，WiFi 模塊和上位機在WiFi 路由器20 m 范圍內。為方便統(tǒng)計收發(fā)包數，設置測點在發(fā)送一定數量包后停止發(fā)送，測試數據見表8。

表8 系統(tǒng)丟包率測試數據Tab.8 System packet loss rate test data

測試共進行3 次，測點每10 s 發(fā)送1 個包，持續(xù)時間分別約為1，12，24 h；測點發(fā)送數為3 個測點發(fā)送總和。由表可知，在100 m 范圍內，ZigBee 丟包率很小，且丟包率不隨測量時間的變化而變化；基于WiFi 和TCP 的連接方式穩(wěn)定，IP 丟包率為0。

選取3 個測點對系統(tǒng)進行了功能測試，分別將測點1 置于戶外、測點2 置于樓道、測點3 置于室內。3 個測點的溫度報警上限均為30 ℃，下限為0 ℃；溫度預警上限為40%，下限為20%。監(jiān)測系統(tǒng)主界面如圖11所示。測點1 的溫度和濕度均低于下限值，分別發(fā)出溫度報警和濕度報警；測點2 僅濕度低于下限，只有濕度報警。

圖11 溫濕度監(jiān)測系統(tǒng)主界面Fig.11 Main interface of temperature and humidity monitoring system

用鼠標雙擊測點區(qū)域可以查看測點實時數據與曲線。測點的實時數據及曲線如圖12，圖中上方曲線為溫度曲線，下方曲線為濕度曲線。

圖12 測點實時數據及曲線Fig.12 Real-time data and curves of measuring points

5 結語

所設計的基于ZigBee 和WiFi 的無線監(jiān)測系統(tǒng)，以CC2530 和RTL8710 為核心芯片，實現了測點與監(jiān)測軟件的無線連接。經過測試，該系統(tǒng)能夠實現各測點溫濕度的實時監(jiān)測和顯示，顯示界面清晰明了，系統(tǒng)組網方便可靠，具有一定的實際應用價值。