低功耗電子號牌在排隊系統中的設計與實現

楊東軒 劉 碩 王 嵩

(北京工商大學網絡中心 北京 100048)

0 引 言

目前在一些辦事大廳等場景廣泛使用排隊叫號系統，不少系統仍采用紙質的叫號方式。這種紙質方式既不利于環境保護又在內容顯示上無法實時更新。有些手機APP的叫號方式又有許多使用的局限性，包括可能暴露客戶信息等情況[1,2]。本文結合物聯網技術和基于低功耗Wi-Fi的電子手持號牌設計，給出使用該電子手持號牌較為完整的叫號系統設計與實現方法。

1 系統架構

系統主要由電子號牌和服務器兩部分組成，它們同處于一個無線局域網之中。電子號牌以低功耗Wi-Fi芯片CC3200為核心，接收來自服務器端的無線數據，提醒用戶當前的業務信息。服務器端由Linux系統及相關軟件構成，負責控制電子號牌的發放、叫號信息的數據廣播以及與對外提供系統交互接口。系統架構如圖1所示。

圖1 系統架構圖

目前市場較為常見的電子號牌一般都采用315 MHz左右的較低頻率無線調頻技術，使用數碼管顯示號碼，一般只有一個信號發射端用來手工發號和叫號，不能更改號牌的號碼，也不提供二次開發的接口。它們的無線發射端和接收端不具備組網功能，且信號覆蓋范圍固定，僅適用于快餐業務領域的叫號使用。

本文實現的電子號牌在系統構成方面更加復雜、應用范圍也更為廣泛。號牌具有文本顯示能力，包括顯示業務類型、辦理進度、時間和電量等信息。而且還有震動功能提醒客戶。由于服務器端和客戶端是使用Wi-Fi進行通信的，因此系統的覆蓋范圍可以根據AP的安裝位置進行靈活擴展。

2 電子號牌設計

系統設計初期，將電子號牌的外觀尺寸限定在普通的銀行卡尺寸大小，這就對其內部的電路設計提出了很高的要求。在核心器件低功耗Wi-Fi芯片的選型上，選擇了德州儀器的CC3200芯片，與同一應用領域的其他廠家的芯片相比[3-4]，它具有外設接口豐富、工作電壓范圍更寬、開發周期較短等優點，如表1所示。

表1 同類低功耗Wi-Fi芯片對比

2.1 號牌硬件設計

硬件電路包含CC3200最小運行系統、OLED點陣顯示屏、振子電機驅動、霍爾效應開關傳感器及充電管理模塊。CC3200最小系統包含了能使該芯片正常運行的最少電路設計以及能支持其無線通信的天線電路設計。由于該主控芯片集成了一個ARM-Cortex M4內核的處理器和一個Wi-Fi網絡處理器[5]，因此在電路板的布局和走線方面要嚴格按照TI公司給出的設計手冊進行，其中電源部分和射頻鏈路部分的設計尤為重要。為了滿足芯片啟動、發射和接收數據時的電流需求，電源相關引腳的走線必須滿足表2中的條件。

表2 CC3200引腳通過電流

射頻部分的布局則會影響信號的輸出功率、誤差向量幅度以及頻譜掩模。在射頻電路中，天線起到了將PCB引線中的導波轉換為自由空間中電磁輻射的作用，因此在布局中要盡量把陶瓷天線器件放到PCB板的邊緣，確保沒有其他信號線穿過天線底部。由于射頻部分走線要滿足其在2.4 GHz頻段工作時的阻抗為50 Ω，因此需要選擇適合的傳輸模型。本文選用具有地面結構的共面波導CPW-G(Coplanar Waveguide With GND)模型，該模型結構如圖2所示，其中εr為相對介電常數，W為間隙寬度，S為走線寬度，h為電解質厚度[6]。

圖2 CPW-G模型結構

在顯示功能方面，選用像素尺寸為128×64的OLED點陣顯示屏，該屏幕可以同時顯示32個漢字或者64個半角字符，足以容納叫號業務所需顯示的內容。相比目前流行的LCD、QLED和LPD顯示技術，OLED具有自發光、厚度極薄、響應時間快、低功耗等優點[7]。該款屏幕在2.8 V供電情況下，全像素點亮時的電流為28 mA，休眠狀態時則為1 μA。屏幕與主控芯片之間采用SPI串行總線連接，電路原理如圖3所示。

圖3 OLED屏幕電路

振子即微型的震動電機，通過將電能轉換為機械能起到震動提醒作用，是整個電路系統中最為耗電的部分。號牌采用的振子最大電流為120 mA，為了讓CC3200的GPIO口足以驅動該電機，采用NPN型的三極管作為驅動開關。如圖4所示，將電機的正負輸入端分別接到系統電源與三極管的集電極之間，為了防止電機停止時產生的反電動勢對其他電子器件造成損壞，還需要在電機的兩端并入一個二極管以作保護。

圖4 振動電機驅動電路

電子號牌沒有任何可供用戶操作的輸入設備，因此需要設計一個激活裝置來將整個電路系統從關閉狀態激活為開啟狀態。采用A3212型的超靈敏霍爾效應開關傳感器，可以在不使用物理觸控的條件下，通過磁場變化就可以改變該傳感器的輸出電壓。將該傳感器布局在PCB的邊緣，有助于更加靈敏地受到磁鐵的感應。如圖5所示，OUTPUT輸出引腳通過上拉電阻連接到主控芯片的GPIO口，該IO口用于將冬眠狀態的處理器喚醒為運行狀態。當垂直通過該傳感器的磁感應強度大于37 T的時候，輸出為低電平。

圖5 霍爾開關傳感器電路

使用一塊容量為700 mAH的鋰離子電池作為整個電路的供電來源，采用USB Micro接口作為號牌的充電接口，充電管理芯片的型號為TP4056。如圖6所示，當電路系統接入5 V的USB充電線后，USB接口的VBUS電源引腳通過限流電阻使NPN三極管CE兩端導通，發射極觸發主控芯片的GPIO口從而通知系統已經接入充電線。充電管理芯片的STDBY引腳為電池充電狀態，當電池充滿電后會內部下拉到低電平。

圖6 充電管理電路

2.2 低功耗策略實現

設備的主要耗電器件是屏幕、震動電機以及主控芯片，由于前兩者在運行期間的功耗基本是恒定不變的，因此為主控芯片制定合適的低功耗策略是關鍵所在。對于理想化的計算機系統而言降低核心處理器CPU的電壓和頻率均可以起到降低功耗的作用[8]，如果把CPU看作是一個基于電容器的系統，那么它的功耗滿足如下物理關系式：

(1)

式中：E為芯片消耗的能量，T為消耗能量所需的時間，U為運行電壓，f為芯片的工作頻率。

對于CC3200而言，雖然它的工作電壓范圍在1.76 V至3.6 V之間，但是為了簡化硬件設計，通常采用恒定的穩壓電源，因此只需要通過改變芯片的運行頻率就可以滿足功耗的調整了，其物理關系滿足下式：

(2)

式中：Ttask為單個任務運行的時間。

而芯片在不同的運行頻率下，所處的工作模式也不同。CC3200內部包含兩個獨立的系統，分別是Cortex-M4應用處理器(MCU)子系統和網絡處理器(NWP)子系統，每個子系統都有若干種工作模式。在號牌的軟件實現中，分別用到了MCU的激活模式、低功耗深度睡眠模式(LPDS)以及冬眠模式。在激活模式時，它將以80 MHz的頻率運行應用代碼，此時MCU的功耗最高；在LPDS模式時，只保留特定寄存器的配置，但可以從網絡事件中喚醒；在冬眠模式時，功耗最低且僅由頻率最低的實時時鐘驅動，僅能由時鐘定時器或外部事件觸發喚醒，喚醒后重新加載串行Flash中的應用代碼運行。NWP的工作模式由其自身根據當前的網絡狀態和MCU的電源策略自動控制，分別在激活模式、LPDS模式和冬眠模式中自主切換[9]。

在號牌的實際使用過程中，針對不同的工作場景切換不同的工作模式，在保障運行效率的情況下使芯片功耗降到最低。表3給出了所有工作場景下芯片對應的電源模式以及電路各主要部分的電流使用情況。在號牌未被發出時，處于冬眠狀態，此時功耗最低；當號牌被發出時，需要從冬眠狀態被喚醒，由于喚醒時機不確定，因此只能使用外部IO作為喚醒源；號牌在用戶手中的大部分時間是保持屏幕畫面不變的狀態，處于LPDS模式，但是當處于接收廣播消息、屏幕時間定時刷新等事件時，便會被喚醒；喚醒狀態的號牌處于激活模式，此時進行屏幕刷新、網絡數據處理等業務。

表3 電子號牌電源工作模式

2.3 號牌軟件設計

電子號牌與服務器之間的通信方案采用無握手機制的UDP協議報文。軟件整體結構基于FreeRTOS嵌入式實時操作系統，采用TI官方提供的SimpleLink組件庫來實現網絡方面的編程，調用內置于芯片ROM的外設驅動庫(DriverLib)來對SPI、GPIO、ADC和定時器等外設進行編程。軟件的主函數運行流程如圖7所示。首先對CC3200的外設及硬件資源進行初始化，如OLED屏幕、外部輸入IO等；然后開始SimpleLink的任務調度器，該任務管理主處理器和NWP之間的消息通信；最后創建并執行分別用于事件處理、UDP服務器和UDP客戶端的子任務。

圖7 號牌軟件運行流程

大部分工作時間里號牌處于接收服務器發送UDP廣播數據的狀態，因此它將主要扮演UDP 服務器的角色，僅在第一次連接到服務器的時候才需要作為UDP 客戶端來向服務器發送激活消息。根據發送和接收不同的UDP報文，來驅動號牌在不同狀態之間切換。這些狀態包括：設備復位狀態、等待業務編號狀態、等待叫號狀態、被叫號狀態、過號狀態以及充電狀態。在大部分狀態改變的同時，號牌接收UDP報文的端口號也會隨之改變，在等待叫號狀態中，不同業務類型的號牌所監聽的UDP端口也不同。這樣就實現了以端口號劃分業務類型的目的，在服務器廣播指定端口的UDP報文的同時，其他業務類型的號牌則不會收到該端口的報文。不接收報文意味著硬件不會從LDPS模式中被喚醒，從而節約了不必要的功耗開支。UDP報文與號牌狀態之間切換的流程如圖8所示。

圖8 號牌狀態切換流程

號牌軟件系統中有三個主要的任務，分別是：Task_MainProcess()(主處理任務)，負責系統初始化、外設控制以及網絡報文數據處理；Task_UDPServer()(UDP服務器任務)，負責接收來自服務器發送的UDP報文；Task_UDPClient()(UDP客戶端任務)，負責向服務器發送UDP報文。當系統成功連接到指定SSID的AP后，首先會向服務器發送激活消息的數據包。在本次發送的數據中，加入該號牌的MAC地址作為唯一身份識別，用sl_NetCfgGet()獲取設備自身的MAC地址。無論是發送還是接收UDP數據包，都需要首先調用sl_Socket()創建UDP套接字，之后通過sl_SendTo()將封裝好的數據包發送出去。為了防止網絡阻塞、信號不好等意外情況導致目標地址無法正常收到數據，在發送每個UDP報文的時候都連續發送N次同樣的數據，一旦接收到服務器返回的數據，則停止發送并執行下一步操作，當第N次還沒有收到應答數據，則判斷其運行狀態異常，系統調用rn_setup_power_policy()進入冬眠模式以備回收處理。當服務器成功接收到號牌發送的激活消息后，會做出相應的回答。號牌系統通過sl_RecvFrom()接收UDP報文，并使用sl_Bind()綁定接收數據的端口。如前文所述，UDP客戶端任務根據接收到的報文類型來使號牌切換狀態同時改變接收報文的端口號，該任務的運行流程如圖9所示。

圖9 UDP客戶端任務流程

3 服務器端設計

服務器端的軟件采用GO語言編寫并運行于Linux系統之上。該語言編寫的代碼在編譯后生成一個靜態可執行文件，在服務器上部署時完全不需要關心應用所需的各種包和庫的依賴關系，大大減輕了維護的負擔。

3.1 數據模型設計

系統中主要用到了XML數據模型和關系型數據模型，前者用來存儲電子號牌硬件相關的數據，后者用來存儲業務相關的運行數據。將每個電子號牌的射頻標簽EPC編碼和MAC地址存儲在XML文件中，如果需要更換或新增電子號牌，只需要更新該XML文件即可，該文件的存儲格式如下：

F4:B8:5E:45:EB:82

使用如下代碼將XML數據讀入到程序內存中：

data, err:=ReadFile(CONFIG_XML)

err=xml.Unmarshal(data, &cardslice)

for _, v:=range cardslice.Item

cardmap[v.Epc]=v.Mac

業務數據存儲到MySQL數據庫中的“system”表中，該表僅存儲非冬眠狀態即正在使用中的電子號牌的業務數據。每當發出一張新的電子號牌，使用InsertDB()向表中插入一條新數據，并寫入EPC、MAC地址等基礎數據；當電子號牌狀態發生改變后通過UpdateDB()改變該記錄的數據；當電子號牌使用完畢并進入冬眠狀態后，通過DeleteDB()銷毀對應號牌的記錄。數據表“system”的結構和描述如表4所示。

表4 系統數據表結構

3.2 業務邏輯

服務器端軟件的業務對象主要面向手牌硬件客戶端和上層叫號應用的調用，前者通過UDP協議與服務器端通信，后者通過HTTP API控制服務器做出相關動作。軟件開始運行后，首先初始化HTTP和UDP等網絡相關的監聽接口，并通過串口檢查硬件發卡設備是否工作正常。服務器端軟件的結構如圖10所示。

圖10 服務器端軟件結構

GO語言有眾多優秀的Web框架[10]，但是本系統的HTTP接口僅面向上層應用之間的調用，不需要復雜的路由配置和HTML模板引擎，因此只使用GO的標準庫接口便可以實現功能。使用http.HandleFunc()接口把一個URL路徑綁定給相應的函數，然后通過http.ListenAndServe()接口監聽8080端口的HTTP請求。當客戶的應用調用指定的URL訪問服務器后，服務器會調用相應的函數執行業務功能，同時以JSON格式的數據返回給客戶應用。以號牌發放流程為例，當HTTP端口收到來自客戶應用的發卡請求后會立即返回結果，因為發放操作涉及硬件控制，所以處理結果需要以異步主動查詢的方式獲取。如果發號機為空閑狀態，則通過ttyS設備控制串口做出發號操作，此時客戶的應用可以定期調用查詢接口以查詢操作是否成功。如果以上步驟成功，則號牌會自動激活并向服務器發送相關UDP報文來請求分配業務號碼。

服務器在監聽號牌上報的UDP報文的同時，還要根據HTTP接口調用的叫號操作向指定業務類型的號牌發送UDP廣播報文。使用以下代碼開啟UDP服務器：

addr, err:=net.ResolveUDPAddr(″udp″, ″:″+port)

conn, err=net.ListenUDP(″udp″, addr)

其中port為UDP服務器需要監聽的端口號，然后循環調用以下代碼監聽并讀取客戶端發送上來的UDP報文：

n, remoteAddr, err:=conn.ReadFromUDP(data)

與接收UDP報文的操作不同，HTTP接口的并發調用可能會引起多個同時發送UDP報文的操作，為了防止多線程之間在同時發送UDP報文的時候占用發送通道而發生異常，需要定義一個*sync.Mutex類型的互斥鎖來保證同時只有一個線程在發送報文，代碼如下所示：

broadipport:=fmt.Sprintf(″%s:%s″, ″192.168.1.255″, cardPort)

addr, err:=net.ResolveUDPAddr(″udp″, broadipport)

locker.Lock()

//阻塞其他發送報文的線程

_, err:=conn.WriteToUDP(data, addr)

locker.Unlock()

//釋放阻塞

從代碼可以看出發送報文并未指定任何目的IP地址而是使用廣播地址和指定的端口號來發送，因為系統規定不同的號碼業務對應不同的端口號，所以每次的叫號操作并不是把報文發送給特定IP的號牌客戶端，而是以端口號為分組的廣播發送。

3.3 接口協議

3.3.1 外部HTTP接口

本系統對于外部應用來說相當于一個黑箱，各種應用只需要調用服務器提供的HTTP接口便可以操作整個電子號牌系統。HTTP接口部分說明如表5所示。

表5 HTTP接口

3.3.2 內部UDP協議

服務器與號牌客戶端之間處于一個內部網絡環境，不需要對第三方提供服務，為了簡化通信，直接使用OSI分層中屬于傳輸層的UDP報文進行通信。自定義報文的格式共分為幀頭、類型和內容三個段。其中幀頭段固定為2個字節的0x55和0xAA；類型段為1個字節，用來區分當前報文的功能，分別有“設置號碼業務”類型和“叫號操作”類型；內容段的長度根據類型段來確定，如果類型為設置號碼業務，則內容段共15字節，包含需要開啟的端口號、業務代碼類型、需要設置的號碼、當前叫到的號碼以及當前的時間戳。如果是叫號操作類型，則內容段共12個字節，包含當前叫到的號碼以及該號碼的服務窗口名稱。

4 結 語

本文介紹了一種基于低功耗Wi-Fi的電子號牌系統的設計和實現方法。通過系統對外提供便捷的HTTP操作接口，可以與大部分目前的排隊叫號場景進行對接。系統的電子號牌不僅體積小，還可以在極低功耗的狀態下長時間休眠，有較好的使用價值和用戶體驗。