摘要：在手機報警受限的情況下，為了使求助者能向校園保衛處緊急報警并且準確定好自己所處的位置，本文研制了求助者隨身攜帶的微型無線遙控器和相應的配套系統。當求助者按下緊急求助按鈕時，立即向保衛處發出求助信號，同時在保衛處的監控界面上直觀顯示求助者所在的位置。測試表明，從求助者按下緊急求助按鈕到保衛處頁面刷新顯示為40～50 s，位置精度為20～40m。

引言

學校安全工作是全社會安全工作的重要組成部分之一。它直接關系到青年學生能否安全、健康地成長，關系到千千萬萬個家庭的幸福安寧和社會穩定。廣東海洋大學湖光校區校園面積大，有些地方比較偏僻，往往是警情多發地段。遇到緊急情況，求助者通過手機報警，但往往很難準確描述其所在位置。若求助者手機報警受到限制，就更加無法對外發出求助。

為了解決以上的問題，讓求助者能通過第二種方式向校園保衛處緊急報警并且準確定好自己所處的位置，本文研制了求助者隨身攜帶的微型無線遙控器和相應的配套裝置。當求助者按下緊急求助按鈕，立即向保衛處發出求助信號，同時在保衛處的監控界面上直觀顯示求助者所在的位置。

1 系統整體實現

該系統的整體架構如圖1所示。在某需要監控的區域布置中心站，在中心站周圍布置多個分站，形成一個星狀網絡。一旦各個站點布置的位置確定，其經緯度的位置信息便確定下來。區域內的各個分站的信息直接或者間接傳送到中心站，中心站接著把該信息傳送到數據中心。為了增加分站布置的靈活性，本文對分站之間信息的接力傳遞進行了技術上的實現，但從實時性和可靠性的角度看，盡量避免分站之間信息的接力傳遞，從信息起始發起的分站到中心站之間的分站不應超過2個。

求助者按下隨身攜帶的微型無線遙控器的緊急求助按鈕，當離其最近的分站接收到該求助信號時，該分站首先啟動報警器蜂鳴，這樣做是為了獲得周圍群眾的幫助，然后該分站通過某種預定的路徑，直接或者間接地把該信息傳送到中心站。最后中心站通過GPRS網絡把該信息傳送到互聯網上的數據中心，并存儲在數據庫服務器中。

在WEB服務器上發布警情監控的網站，學校保衛處作為客戶端之一訪問該網站。該頁面不斷實時刷新顯示最新的警情信息。學校保安人員也可以通過手機訪問該網站，從而協助其準確到達案發地點。

監控開始時，客戶端在瀏覽器上鍵入“http：//210.38.139.35/warn/default.htm”地址。假設現有不同用戶在不同地方按下緊急求助按鈕，圖2為顯示界面。

圖2中標注“警衛”的地方就是學校固定警力分布的位置，標注“警報”的位置就是當前警情位置，其以不停的跳動和聲音提示最新警情。只有保衛處用戶才有權限去處理該警情信息，其他用戶只有瀏覽權限。這樣保衛處根據求助地點和警衛的位置，作出最優的指揮。同時警衛人員可以利用手機訪問該網站，作為位置協助找到求助者。

2 系統硬件

2.1 nRF24LE1模塊

nRF24LE1是NORDIC公司新推出的一款芯片。nRF24LE1采用了NORDIC公司最新的無線和超低功耗技術，在一個極小封裝中集成了2.4 GHz無線傳輸、增強型51 Flash高速單片機、豐富外設及接口等，是一個性能和成本的完美結合，很適合應用于各種2.4GHz的產品設計。

在本系統中的微型無線遙控器、分站和中心站的無線收發裝置選用的都是nRF24LE1模塊，它們之間的信息傳遞是通過各自的nRF24LE1模塊進行的。其中，分站和中心站采用的nRF24LE1模塊帶有外置功率放大天線，開闊地傳輸距離約為200～400 m，而微型無線遙控器采用的nRF 24LE1網模塊帶有內置天線，開闊地通信距離為10～30 m。

2.2 EM310模塊

中心站最后還需要把警情信息通過GPRS網絡傳送到互聯網上的數據中心。GPRS網絡的接入采用華為公司生產的EM310模塊。EM310模塊內置了TCP/IP協議棧，由AT指令控制并使得應用程序可以很容易地接入網絡。該方案的優點在于最小化了將網絡連接集成入一個新的或已存在的應用程序所需的成本和時間。

在本系統中，EM310模塊是由中心站的nRF24LE1通過AT指令控制操作的，它們之間的接口就是典型的三線制串行通信。

3 系統軟件的實現

3.1 微型無線遙控器軟件

考慮到遙控器的功耗和體積，采用紐扣電池供電。平時不需要報警的時候，電源按鈕處于被關閉狀態，當有緊急情況時，電源按鈕被按下，系統開始工作，啟動發送警報，其工作流程如圖3所示。

求助信號發送出去后，離其最近的分站接收到該信號，分站啟動大功率蜂鳴器工作，同時發送一個應答包給該遙控器。當遙控器接收到該應答包后，停止發送警報，同時觸發LED指示，表示警報信息已經被成功捕獲，否則重新發送。這樣設置是為了加強系統的可靠性，萬一分站的蜂鳴器壞了，求助者無法通過蜂鳴器嗚叫來確認求助信息是否被成功捕獲。

3.2 分站軟件

與無線遙控器供電方式不同，分站采用連續的供電方式，其工作流程圖如圖4所示。分站不斷循環檢測是否有警報信息需要處理。若有警報信息需要處理，首先發出應答包，接著往預定的目標地址發送警報數據包。該目標地址可以是其他分站，也可以是中心站，是根據實際需要設定的。

3.3 中心站軟件

中心站和分站的軟件實現在整體上有相似之處，稍微區別是當分站確認接收到警報數據包后，便向預定的目標地址(其他分站或者中心站)發送該警報包，而中心站接收到警報數據包后，通過EM310往預定的目標IP地址發送，其流程圖如圖5所示。

3.4 網站設計實現

本校園警情快速定位網站的地圖應用設計采用百度地圖的JavaScript API。其是一套由JavaScript語言編寫的應用程序接口，可幫助在網站中構建功能豐富、交互性強的地圖應用，支持PC端和移動端基于瀏覽器的地圖應用開發，且支持HTML5特性的地圖開發。

用戶通過瀏覽器訪問該網站，即向該網站發出了服務請求，該網站便向數據庫提取警情數據，同時向百度請求地圖服務，最后把兩者數據融合，返回給用戶，刷新瀏覽界面，用戶看到就是在百度地圖中對應的位置上標記的警情信息和固定警力信息。

4 關鍵技術討論

4.1 數據包定義

本系統通信的數據包類型有應答包和警報包。警報包又分為遙控器直接發出的警報包(稱為遙控器警報包)和分站轉發的警報包(稱為分站警報包)，數據包類型標識定義如表1所列。

為了形式上的統一，把各種數據包都規定為30個字節長度，數據包中各個字節的定義如表2所示。

某遙控器待發送的警報包數據存放在如下的數組中：

4.2 nRF24LE1數據包發送和接收

在nRF24LE1中，集成了一個功能齊全的2.4GHz收發器核nRF24L01+和一個加強型8051微控制器核。該微控制核和收發器核nRF24L01+是通過其專用的SPI接口進行通信，因此數據包收發是通過SPI讀寫操作來完成的。

TxMode函數的參數分別描述如下：TxAddress：存放目標地址數據的數組;TxAdrWidth：目標地址長度;TxData：存放待發送數據的數組;TxDataLength：待發送的數據長度。

無線遙控器發送的警報是一個廣播性質的數據，所有分站都有同等的機會接收該警報數據，因此在本系統中所有分站必須開啟一個能接收廣播類型數據的通道，也就是所有分站都具有同樣的接收廣播的地址。

nRF24LE1有6個接收數據的通道地址，能滿足這樣的要求，本系統僅僅用了2個接收數據的通道地址，一個是該分站專用的接收地址(即分站ID)，另一個是該分站跟其他分站相同的接收地址，配置操作略——編者注。

無線遙控器發送數據是廣播型，因此發送就是向共有的接收地址發送。另外還需要開通一個接收應答數據包的通道，因為應答包是有固定的指向，因此無線遙控器只需要開通一個專用的接收數據通道(即遙控器ID)，其相關配置略——編者注。

為了增加系統的可靠性和可控性，這里只是允許接收中斷，而且接收中斷在某種情況下，還根據需要進行關閉，然后再次開啟等。

4.3 隨機調整發包時間間隔參數策略

時間間隔調整是靠Delay函數里面的Temp參數的調整來確定的。Delay(Temp)延時時間大約為Temp值的1/10 s。延時參數Temp值等于基數10加上一個小于10的隨機數，具體實現如下：

Delay(Temp)實現的延時是以1 s為基礎加上一個小于1的隨機小數，總共有4個1 s左右的延時疊加，因此該延時是以4 s為基數進行調整的，該參數的配置是根據實驗測試并統計B從接收警報包，到轉發警報包，再到接收應答包的時間，再適當加上一定余量，權衡得出來的。

每一個設備都把自己認為重要的事情做好，并且又能夠互相配合，使得整個系統可靠性和實時性達到一個相對完美的配合。

4.4 遠程應用服務器操作策略

網絡組網方案是數據中心服務器端采用公網固定IP地址，EM310直接通過IP地址訪問Internet。其中，最關鍵兩個動作就是EM310連接遠程應用服務器操作和EM310往遠程應用服務器發送數據包。

本文從實時性角度出發，采用最簡的操作步驟，如表3所示。

4個步驟之間緊密相連，缺一不可。每個AT指令發送出去后，會返回一個字符串，只有確認返同字符串中有“OK”字符，才能認為該AT指令操作成功，才可以進入下一個步驟的操作，否則重新發送該AT指令。這種方法可以獲得最高的可靠性，同時也會帶來一定風險，程序會一直在循環等待。

考慮到實時性，本文采用的是并不是每個AT指令操作后都等待“OK”字符，而是直接進入第4個步驟，發送警報信息。在該指令發送后，經過適當的延時，然后去判斷返回的字符串中是否有“OK”字符，否則才開始從第1個步驟開始。

萬一警情信息發送不成功，需要重新連接服務器，即從第1個步驟重新開始。本文采用的并不是每個AT指令操作后都去作等待“OK”字符的動作，而是經過適當延時，直接進入下一個動作。因此必須預先對該延時參數有個估計，同時要保留一定余量。本文通過大量測試，權衡后得到如表4所列的參數。

結語

測試兩種情況從按下求助按鈕到地圖顯示的時間：一是分站直接到中心站;二是分站間接到中心站(本系統分站到中心站最多是2個)，結果是40～50 s。假設A轉發的數據包目標是分站B，在A接收范圍內按下一個求助按鈕，同時在B接收的范圍內，按下另一個求助按鈕。測試表明本系統能可靠把兩個警報包最終在百度地圖上顯示出來。因此，本系統所用的策略保障了一定的實時性和可靠性。