（福州大学物理与信息工程学院，福建福州350002）
关键词：RDSS；RNSS；集成;控制
中图分类号：TN927+.2文献标识码：ADOI：10.19358/j.issn.1674-7720.2017.10.005
引用格式：柯秋立，苏凯雄.北斗通信终端软件的设计与实现［J］.微型机与应用，2017,36（10）：15-17,22.
0引言
本文针对此需求，设计一种控制软件系统，对北斗RDSS、RNSS综合业务进行报文控制，包括数据通信、授时、终端移动数据获取等功能，并且具有较好的人机交互效果。
1北斗卫星导航终端系统概述
如图1所示，一个完整的北斗卫星导航终端系统，主要由北斗用户终端模块（该模块同时具有北斗一代的RDSS业务功能与GPS、北斗二代的RNSS业务功能）、Windows平台、后台数据处理线程、人机界面四个部分组成。整个北斗导航终端系统的功能主要是RDSS/RNSS数据帧的接收解析与封装发送。数据帧接收过程：北斗用户终端首先将天线接收到的北斗信号经过模块内部的信号处理，转换成串口数据并输出到PC。串口数据进入PC后由后台线程根据帧协议解析，得到用户应用数据。该应用数据将被人机界面进行可视化处理。数据帧发送过程：用户在人机界面发送命令时，该命令对应的应用数据被后台线程封装成协议帧并输出到串口。北斗用户终端将得到的串口数据经过内部信号处理后，通过天线发送出去。
2软件系统实现
软件系统的设计主要由两部分组成：后台线程设计和用户界面设计。下面针对这两部分的具体实现做详细阐述。
2.1后台线程实现
后台线程的设计主要涉及RDSS/RNSS协议帧的接收、解析算法，解析与显示快速响应算法。算法涉及RDSS/RNSS两种报文，基于两种不同的协议规范，一种是北斗用户机接口协议（4.0），另一种是NMEA0183协议。
2.1.1用户接口协议
用户接口协议规范了通信应用数据帧的格式。北斗一代接口数据传输协议（4.0）在该控制软件中主要用于规范北斗通信数据和定位数据，而NMEA0183协议主要用于规范卫星的位置数据和终端设备的移动数据。
北斗用户机接口协议（4.0）如图2所示。“用户地址”是指作为发送方的北斗卡号码，而接收方的北斗卡号码被包含在“信息内容”字段中。
由北斗用户机接口协议（4.0）可知，该协议数据帧是以字节为单位来表示信息，所以要将该数据帧原有的字节类型转换为方便计算机处理的基本数据类型［2］。
北斗用户机接口协议（4.0）中，在北斗终端设备之间进行数据通信的方式有“代码”、“汉字”两种。在北斗终端设备实际通信过程中，当通信数据出现中英文数字混合的情况时，应选择“代码”方式发送；如果单纯发送数字，由于数字的范围是0~9,为了更有效地利用有限带宽，可以在“代码”通信方式中进行拓展，用4bit来表示一个数字，而不是原来ASCII规范的1B来表示一个数字。
NMEA0183协议（NationalMarineElectronicsAssociation）是为海用电子设备制定的标准格式，定义了接收机输出信息的标准。该协议用逗点隔开数据流，数据流长度为30~100字符不等，通常以每秒间隔选择输出［3］。常用的NMEA0183协议语句功能如表1所示。
2.1.2数据接收算法
数据帧接收模块的输入为字节数据流，模块通过不断地读取串口缓冲区，经内部处理，输出完整的协议帧语句。数据接收模块的内部流程图如图3所示。
由于RNSS（北斗二代、GPS）数据帧采用NMEA0183协议规范，RDSS（北斗一代）数据帧采用北斗用户机接口协议（4.0）规范，因而数据帧的接收需要适配两种协议规范。
根据图2北斗用户机接口协议（4.0）规范，该类数据帧的完整接收策略为：接收方先接收该帧的长度数据，作为该帧数据量大小的标准；然后，接收帧体并计数，当计数值与长度数据相等时就表示该帧接收完整。
根据NMEA0183协议规范，该类数据帧的完整接收策略为：接收到帧头“$”时表示有效数据开始，一直接收，直到收到帧尾“\\r\\n”时表示一个数据帧结束。
2.1.3数据解析算法
数据解析涉及北斗用户机接口协议（4.0）和NMEA0183协议，而且由于两类数据流都是由同一个串口来进行数据通信，因而数据解析时，算法必须适配两种协议。
部分数据解析的算法流程图如图4所示。
解析即在数据帧里提取相应字段的信息并显示。首先需要将数据帧从字节流形式通过ASCII规范转换为字符串形式以便编程处理［4］。将数据帧转换为字符串形式后，利用编程语言的字符串分割方法便可以很容易地得到各个字段的应用数据信息。
2.1.4快速响应方法
数据接收与数据解析，这两个流程之间的同步形式直接决定了软件响应的速度。该软件将这两个流程分别设计成两个独立的线程，并且采用缓冲技术，极大地提高了响应速度。
首先，在内存空间开辟n个缓存区。
之后，数据接收线程将完整的数据帧填入缓存区1。缓存区1填完之后，数据接收线程将新的完整数据帧填入缓存区2。重复这个过程直到最后一个缓存区n被填完，又重新开始填充缓存区1。数据接收线程将一直循环这样的流程。
与此同时，数据解析线程首先判断缓存区1是否填满，如果已经填充完成，那么就将该数据帧进行解析；如果还没完成，那么等待。缓存区1的数据帧解析完成之后，立刻又对缓存区2的数据帧进行解析。直到最后一个缓存区n的数据帧被解析完，又重新从缓存区1开始解析数据帧。数据解析线程将一直重复这样的流程。
2.2前台界面设计
用户界面的输入主要有“定位申请”和“通信申请”命令，而接收的信息主要有用户通信信息、用户移动数据（速度、经纬度等）和卫星数据（卫星数、卫星俯仰角等）。本次用户界面设计采用VisualStudio2010为开发工具。利用WindowsForm框架［5］将解析得到的应用数据如卫星信号载噪比数据、卫星俯仰角数据在柱状图、星座图上进行显示，而对于其他简单的应用数据，则使用文字显示。最终得到如图5所示界面。
3软件系统测试
本次软件设计的测试平台是PCWindows操作系统环境，北斗终端用户机采用FB3511。该软件将对用户机的报文进行控制处理。运行软件，待锁定北斗卫星信号后开始进行测试。
(1)定位功能功能测试
按下“单次定位”按钮，“北斗报文显示”框给出经纬度信息，如图6。输出的经纬度信息与测试地经纬度一致，表明RDSS定位报文控制功能正确实现。图中，“单次定位”命令未能及时响应，这是由于该北斗卡限制报文发送频度为60秒所致。
(2)通信功能测试
在“收方地址”填入本机卡号307577，即发给本台设备。在信息发送框填入“你好，北斗helloBD”，在“北斗报文显示”框里面就会收到该信息，如图7。收发信息一致，表明RDSS收发报文功能正确实现。
(3)设备移动信息功能测试
4结论
该软件系统采用了WindowsForm框架和多线程并发技术进行软件设计，合理规划各个数据处理流程的分工，将数据处理的负荷合理分配到各个部分。实际测试表明，该软件能够对RDSS/RNSS两种协议报文进行可靠、准确的控制，做到快速响应，为后续的软件应用研究奠定基础。
参考文献
［1］黄建华.北斗RDSS机制下的导航地图更新设想及实践［J］.测绘通报,2012(5):44-46,49.
［2］文斌,宁志强,陈爱萍.基于“北斗一代”的ZigBee无线网关设计［J］.电讯技术,2011,51(9):92-95.
［3］朱炳瑜,肖纯贤,陈永虎,等.智能车载系统的设计［J］.南开大学学报(自然科学版),2011,44(6):14-17.
［4］薛雅娟,陈维锋,郭勇,等.C#.NET环境下GPSOEM板接收机数据的提取［J］.成都信息工程学院学报,2006,21(5):645648.
［5］林淑真,杨秀芝,苏凯雄,等.基于Web的锂电池组管理系统［J］.微型机与应用,2015,34(21):21-23,33.