史小雨，程鵬飛，蔡艷輝，李為喬

(1.廣州中海達衛(wèi)星導(dǎo)航技術(shù)股份有限公司，廣東廣州511400;2.中國測繪科學(xué)研究院，北京100830;3.北京奧騰巖石科技有限公司，北京100176)

差分GPS數(shù)據(jù)通信格式RTCM 3.1及其解碼算法的實現(xiàn)

史小雨1，程鵬飛2，蔡艷輝2，李為喬3

(1.廣州中海達衛(wèi)星導(dǎo)航技術(shù)股份有限公司，廣東廣州511400;2.中國測繪科學(xué)研究院，北京100830;3.北京奧騰巖石科技有限公司，北京100176)

目前差分GPS作為提高定位精度與可靠性的一種重要手段而受到越來越多的關(guān)注，該技術(shù)在數(shù)據(jù)傳輸時通常使用國際通用的RTCM SC-104協(xié)議。簡要介紹RTCM 3.1版本的數(shù)據(jù)格式，針對該版本設(shè)計解碼算法并編程實現(xiàn)，最后通過對Trimble實測數(shù)據(jù)的解析與驗證，證明解碼算法的正確性和程序的可靠性。

差分GPS;RTCM 3.1;數(shù)據(jù)解碼;數(shù)據(jù)通信

一、引 言

隨著社會的發(fā)展，人們對定位的要求也在不斷的提高，為了提高定位的精度和可靠性，差分GPS (DGPS)越來越受到人們的歡迎。利用這種技術(shù)，用戶可以使用一臺單頻接收機實時地獲得米級(測碼偽距差分)或者厘米級(測相偽距差分)的定位精度。在基準站與流動站數(shù)據(jù)傳輸時通常使用國際通用的RTCM SC-104協(xié)議，該協(xié)議由國際海運事業(yè)無線電委員會提出。在發(fā)布了2.x版本后，該委員會意識到這個版本有如下缺點:① 每24位數(shù)據(jù)之后都跟著6位奇偶檢校碼，這是對帶寬的一種浪費;②字與字之間的奇偶檢校碼彼此之間不獨立;③雖然用了多個位進行奇偶檢校，信息的完整性還是不能得到很好的保證;④30位的字處理起來相當(dāng)麻煩。因此，在作了適當(dāng)修改之后，新版本的RTCM 3.0于2004年推出。查閱相關(guān)文獻后，筆者發(fā)現(xiàn)介紹和解碼新版本電文的材料比較少，所以本文主要介紹RTCM SC-104新發(fā)布的3.1電文及其解碼算法［1］。

二、RTCM 3.1電文

RTCM 3.1標準是對2.x版本的一次升級，可以支持單基準站或網(wǎng)絡(luò)基準站的GPS與GLONASS信息操作，同時可以直接支持正在開發(fā)的新系統(tǒng)(如Galileo)，或是對現(xiàn)有系統(tǒng)的改進(如新的L2C和L5波段)。此外，新的標準還可以支持增強系統(tǒng)。作為版本3的新標準，3.1標準中包含GPS網(wǎng)絡(luò)差分改正數(shù)，可以支持大區(qū)域內(nèi)的移動接收機獲取精確的RTK信息。新的GPS和GLONASS信息提供了衛(wèi)星軌道參數(shù)以輔助快速捕獲，為了傳輸純文本數(shù)據(jù)也提供了一種Unicode文本信息，同時預(yù)留了一部分消息讓用戶自己定義，用戶可以方便地向電文中加入自己定義的信息。具體的內(nèi)容如表1所示。

表1 RTCM 3.1電文類型［1］

續(xù)表1

RTCM 3.1以數(shù)據(jù)庫的形式來設(shè)計，與NMEA 2000有些相像。不同的是NMEA 2000是為了不同電子單元的網(wǎng)絡(luò)化而設(shè)計的，而版本3的差分GNSS標準則是為集中發(fā)布數(shù)據(jù)而設(shè)計的。對于版本3的廣播信息而言，每個位都可能包含經(jīng)常重復(fù)的信息，因此當(dāng)限制了字節(jié)隊列的長度時，強制要求每個數(shù)據(jù)區(qū)都占用幾個整字節(jié)是不太現(xiàn)實的。此外，在NMEA 2000數(shù)據(jù)庫中數(shù)據(jù)字典和數(shù)據(jù)域有很大的差別，而在RTCM 3.1中二者的差別就變得很小。所以，與其同時用數(shù)據(jù)字典和數(shù)據(jù)域表，不如把二者統(tǒng)一為一個數(shù)據(jù)域定義更合適［1］。

表1中，分別定義了GPS和GLONASS的RTK消息，這樣就避免了向消息中附加標記信息，因為這樣做改變了消息中數(shù)據(jù)元素的長度或意義。但是還有一些可變性的數(shù)據(jù)元素是無法避免的，這是因為衛(wèi)星的數(shù)目不能確定。不過由于衛(wèi)星數(shù)是唯一的變化量，所以傳輸層定義的消息長度使通過消息長度確定衛(wèi)星數(shù)目成為可能。對于長度不超過限定的消息來說，數(shù)據(jù)發(fā)布者需要將最后沒有用完的字節(jié)位補0。

三、解碼算法的設(shè)計

針對新版本數(shù)據(jù)格式的特點，設(shè)計相應(yīng)的解碼算法，主要由以下幾個部分組成。

1.數(shù)據(jù)管理

從接收機獲取的是字節(jié)流，必須要對接收到的數(shù)據(jù)進行有效的管理才能進行解碼工作。數(shù)據(jù)管理主要包括:數(shù)據(jù)的接收、存儲、刪除等操作。由于消息的處理實行先進先出的原則，所以用隊列管理接收到的數(shù)據(jù)比較有效。接收到數(shù)據(jù)后，把數(shù)據(jù)放到隊列里，當(dāng)判斷收到的數(shù)據(jù)足夠解碼一條消息時，就將有效部分取出并交給解碼部分進行解碼操作，解碼成功就將該部分數(shù)據(jù)從隊列中刪除。

隊列的設(shè)計可以有兩種選擇方案:循環(huán)隊列和一般順序隊。循環(huán)隊列的操作比較方便，可以有效地進行數(shù)據(jù)存儲和刪除等操作，并且不浪費內(nèi)存。但循環(huán)隊列的容量在定義的時候已經(jīng)確定，不能進行擴充，如果遇到網(wǎng)絡(luò)狀態(tài)不好時，大量擁堵信息同時到達會使隊列直接崩潰，如果把隊列的容量直接開得很大又會加大系統(tǒng)的開銷，所以本次程序的設(shè)計使用的是一般的順序隊。一般順序隊在使用時存在數(shù)據(jù)“假溢出”的現(xiàn)象，為了解決這個問題設(shè)計一種動態(tài)隊列來存儲實時收到的數(shù)據(jù)。這種設(shè)計既可以最大限度地節(jié)省內(nèi)存，也可以應(yīng)對數(shù)據(jù)擁堵的問題［2］。

2.CRC檢校

與2.x版不同的是，新的版本使用高通CRC (cyclical redundancy check)算法，該算法的24位奇偶位可以有效地探測信息缺失和一些隨機誤差。CRC又稱循環(huán)冗余碼校驗，是數(shù)據(jù)通信領(lǐng)域中最常用的一種差錯校驗碼，它是利用除法及余數(shù)的原理來作錯誤偵測的。在RTCM3.1版中，這部分工作由如下多項式產(chǎn)生的碼完成

這種碼被稱為CRC-24Q(Q表示高通公司)。這種碼的生成多項式形式如下(利用二進制多項式算法)

p(X)是簡單的不可被約分的多項式

用戶接到消息之后，既可以利用產(chǎn)生多項式生成校驗碼與已有的進行比對，也可以將消息序列左移24位加上接收到的校驗碼，然后與事先定義好的多項式進行二進制除法，如果余數(shù)為0，則表明信息是完整的［1］。

3.解碼設(shè)計

由于在新的版本中省去了字節(jié)掃描、字節(jié)滾動和字節(jié)取補碼這些操作，所以解碼部分的難度相比原版本有所減少。根據(jù)文獻［1］的描述，一條完整消息包括一個固定的引導(dǎo)字、消息的長度信息、消息體和24位的CRC檢校碼。在判斷消息的完整性后，就可以進行解碼工作了。首先判斷消息的類型，然后將不同的類型交給不同的函數(shù)進行解碼，再將解碼出來的數(shù)據(jù)存入事先定義好的數(shù)據(jù)塊中［4］。具體解碼過程如圖1所示。

圖1 解碼算法流程圖

四、程序設(shè)計

根據(jù)上述算法，利用C++語言編程實現(xiàn)了該算法。在程序中設(shè)計了3個類:CBuffer、CMessage和CRTCM31。

1)CBuffer類主要負責(zé)數(shù)據(jù)的管理，包括接收、存儲和刪除。當(dāng)接收到數(shù)據(jù)后，就將其存入CBuffer類中的成員變量中，該變量是一個動態(tài)數(shù)組，可以存儲任意字節(jié)的數(shù)據(jù)。當(dāng)判斷接收數(shù)據(jù)有效且夠一條消息時，就將有用信息提取出來，并將其從數(shù)組中刪除，以節(jié)省內(nèi)存空間。

2)CMessage類包括了3.1版本中所有消息的解碼工作，以及結(jié)果的輸出，并且可以隨著版本的修改而作出相應(yīng)的擴充。當(dāng)接收到有效信息后，就根據(jù)不同的消息類型交給不同的解碼函數(shù)進行相應(yīng)的解碼工作，并可以按用戶需求輸出不同的解碼結(jié)果。

3)CRTCM31類則是對前兩個類的封裝，負責(zé)整個解碼工作的完成，它包含了對接收數(shù)據(jù)的有效性和完整性檢查，消息數(shù)據(jù)的提取等。當(dāng)判斷接收的數(shù)據(jù)有效就將數(shù)據(jù)提取出來交給CMessage類進行解碼，否則繼續(xù)接收數(shù)據(jù)，直到?jīng)]有消息再進來為止。

五、實例驗證

使用Trimble接收機產(chǎn)生的RTCM數(shù)據(jù)進行了驗證。由于電文信息是已知的，所以可對解碼的結(jié)果進行驗證。電文與信息如圖2、表2所示。

圖2 原始電文

表2 電文數(shù)據(jù)信息

解碼結(jié)果如圖3所示，與表2基本一致。由于RTCM 3.1版中對載波相位數(shù)據(jù)進行了數(shù)學(xué)上的處理，在不破壞其整數(shù)特性的同時減少數(shù)據(jù)傳輸?shù)淖止?jié)數(shù)，所以載波相位值會與原始值有所不同，但不影響數(shù)據(jù)處理。

六、結(jié)束語

本文介紹了GPS差分數(shù)據(jù)通信中常用的RTCM SC-104協(xié)議的3.1版本，該版本新增了部分電文信息，補充了2.x版的不足，確保了GPS差分數(shù)據(jù)準確實時的傳輸，提高了數(shù)據(jù)的安全可靠性。分析了GPS差分數(shù)據(jù)格式，并設(shè)計其解碼算法流程，利用VC++編程實現(xiàn)其算法。通過對實測的Trimble數(shù)據(jù)進行解碼，并檢驗其解碼結(jié)果，符合標準，驗證了解析RTCM數(shù)據(jù)算法的正確性和程序的可靠性。

［1］ RTCM Special Committee No.104.RTCM Standard 10403.1 for Differential GNSS［S］.Arlington:Radio Technical Commission for Maritime Services，2006.

［2］ 劉振鵬，張曉莉，郝杰.數(shù)據(jù)結(jié)構(gòu)［M］.北京:中國鐵道出版社，2003.

［3］ 王華，程鵬飛，蔡艷輝.基于Internet的GPS RTK數(shù)據(jù)傳輸?shù)挠行苑治觯跩］.測繪科學(xué)，2006，31(1): 67-68.

［4］ 李思超，葉甜春，徐建華.DGPS RTCM數(shù)據(jù)格式簡介及其解碼算法實現(xiàn)［J］.電子測量技術(shù)，2008，31(12): 11-14.

［5］ 郭洪濤，任超.差分GPS數(shù)據(jù)通訊格式RTCM 3.0及應(yīng)用發(fā)展［J］.全球定位系統(tǒng)，2010，35(3):63-65.

［6］ 嚴新生，過靜珺，朱小冬，等.RTCM SC-104差分電文解碼［J］.工程勘察，2007(6):61-65.

DGPS Data Communication Format RTCM 3.1 and Its Decoding Arithmetic Realization

SHI Xiaoyu，CHENG Pengfei，CAI Yanhui，LI Weiqiao

0494-0911(2012)06-0004-03

P228.4

B

2011-06-01

國家自然科學(xué)基金(40974008)

史小雨(1988—)，男，河南南陽人，碩士生，主要研究方向為衛(wèi)星定位與導(dǎo)航。