基于IP2022芯片可支持GPRS的GPS终端设计

　　本文将介绍一种支持GPRS的GPS系统，并且对其中所涉及到的硬件、软件设计方案给出了详细的描述。通过该模型，可以比较好的实现GPS定位信息数据远程传输。

　　1 系统模型

　　图1是本方案的系统模型。从GPS终端采集来的定位数据，经过GPRS网络透明地传输到远程GPS服务器，远程GPS服务器通过对GPS数据的解码便可以获得定位信息。其详细的流程可以概括如下：

　　

　　① 首先，GPS终端发出包括有APN号码的GPRS登录请求，登陆到 GPRS网络;

　　② 位于移动的SGSN根据登陆请求中的APN，找到登记的Radius服务器，并将用户认证信息送至Radius服务器;

　　③ Radius认证服务器根据所传递过来的认证信息，确认是否是合法用户发来的请求，如果是合法用户，则根据配置为其分配一个IP地址;

　　④ Radius服务器向GGSN发送携带用户地址的确认信息;

　　⑤ GPS终端得到了IP地址，就可以根据配置(作为服务器端或者客户端)与GPS服务器建立起TCP连接;

　　⑥ 连接建立后，GPS终端采集到的定位信息数据就会通过建立的TCP数据连接透明地传输到GPS服务器;

　　⑦ 当GPS服务器有控制命令或其它数据要向下发送时，可以通过TCP连接传送到GPS终端;

　　⑧ GPS终端根据配置可以作为服务器端或者客户端建立与用户管理服务器的数据连接，用户管理服务器通过该连接对GPS终端进行监控、管理以及远程更新系统内核程序。

　　2 GPS终端的设计

　　2.1 硬件设计

　　GPS终端的电路框图如图2所示，GPS终端的核心是一块负责TCP/IP数据传输的网络处理器：IP2022芯片。IP2022是UbiCom公司的高性能网络处理器，具有100MIPS的处理能力，并专门针对网络应用进行了优化。在IP2022芯片中集成了两个全双工的串化器/解串器(Ser/Des)硬件单元，能直接与各种常用接口相连。这种功能使其能够实现片内10Base-T以太网、USB以及其它各种快速串行协议。由于拥有Ser/Des硬件单元，IP2022也便于从一种协议转换到另一种协议，因此比较适合于实现GPS终端。

　　

　　在本系统中，主要应用了IP2022的两个Ser/Des硬件单元以及其TCP/IP协议栈。两个全双工的Ser/Des硬件单元经过串口转换电路(核心为MAX232)转换成为两个标准的RS232接口，通过这两个RS232接口便于与GPS模块以及GPRS模块的通信。

　　系统时钟模块为硬件系统提供工作所需要的时钟脉冲，这部分比较简单，但是需要注意两个方面。一是晶振的选择，虽然IP2022也支持无源晶振，但是在实际应用中发现还是有源晶振与IP2022的兼容性好一些，所以在可能的情况下还是选择有源晶振比较好。二是晶振频率的选择，由于串口通信的波特率是对晶振频率分频而成，如果晶振频率选择不当，在串口通信时会出现乱码。经试验和计算所得，4.9152MHz的晶振可以很好的支持多种常用波特率。

　　程序的写入和调试是通过在线编程接口实现的，IP2022支持在线编程和调试，该部分主要把IP2022的编程接口引出，加以适当的隔离保护，并通过SPI和并口的转换电路与调试机的并口相连接。

　　在本系统中，内部电压有两种，一种是接口设备所需要的3V，另一种是IP2022所需要的2.5V。这两种电压是经过电源转换模块转换而成。由于GPRS模块在数据发送的时候瞬间电流很大，电源转换模块也提供了足够的功率和必要的保护。

　　GPRS数据模块实现GPRS传输的功能，相当于普通的Modem，市面上比较流行的有Motorola的G18在与GPRS数据传输模块通信时，没有采用直接 *** 纵GPRS数据传输模块接口，而是通过RS232连接，极大的降低了对GPRS数据传输模块的依赖性，用户可以根据需要，来选定GPRS数据模块。

　　GPS接收器采用了Motorola公司的M12，M12通过串口与RS232接口单元相连接。

　　2.2 软件设计

　　在GPS终端软件设计方面，为了便于以后扩展，采用了严格的分层结构，具体的软件结构如图3所示。

　　

　　2.2.1 串口驱动模块

　　利用串口驱动模块来完成对串口的 *** 作，向上层提供对串口参数配置的功能，并在有数据收到或者发送完毕的时候通过IndicateReceive、IndicateSend回调函数向上层报告，上层软件可以调用Send、Receive来进行收发。

　　2.2.2 网络驱动模块

　　在硬件中的GPRS模块只是提供了一种硬件信道，与服务器之间的数据连接必须通过软件完成。在通信时，软件首先通过GPRS模块特有的命令(一般为AT+CGMD)与GPRS网络连接，再通过PPP协议建立数据链路，最后就可以通过TCP/IP协议与远程的服务器通信了。这一部分与网络 *** 作的功能都放在网络驱动模块中加以实现。与串口驱动模块类似，网络驱动模块也提供了数据传输的一些服务。

　　2.2.3 桥接模块

　　由于串口是一个慢速连接，主机与串口的通信有时甚至是单字节 *** 作，如果对于每一个这样小的通信都单独通过一个TCP包发送的话，譬如说一个字节的数据，这将产生一些41字节的分组：20字节的IP头，20字节的TCP头以及1字节的数据。如果在高速网络上(例如局域网)，这一些小分组通常不会引起麻烦，但是如果在GPRS这样的网络上(平均往返时间高达数百ms)，则会增加拥塞出现的可能性，并将会使网络的效率极其低。在通常的TCP/IP实现中，一般采用Nagle算法来解决这个问题。但是在Ubicom的协议栈中没有这个功能，因此，必须自己实现这个算法。考虑到对下层硬件结构的无依赖性，笔者将其放在桥接模块中实现，而不是放在网络驱动模块中实现。在算法实现中，当有串口数据到来时，对于小分组，并不立即就将其发出，而是等待一段时间(200s左右)，如果在这段时间中再没有小数据到来，那么将其发出，否则将数据进行累计后发出。当然有些系统要求立即发出，那么也可以通过配置取消这种功能。经这样实现后，效率有了很大的提高，具体的效果可以参考后面的实验数据。

　　2.2.4 辅助模块

　　在上面一些模块的介绍中可以看到，其中有一些关键性的数据必须支持用户自己配置，例如串口通信速度、停止位、网络驱动模块中GPRS所要连接的APN、账户、密码、工作模式(是作为服务器运行还是客户端运行)、静态IP还是动态IP等。这一部分数据由配置模块存储在外部存储器里，每次系统启动的时候再由配置模块载入。在辅助模块中还包括一个重要的子模块：远程管理模块，它实现对GPS终端的远程管理，包括远程跟踪和远程更新程序。系统的运行情况通过统计模块进行统计，然后可以通过远程管理模块进行上报。

　　2.2.5 系统监控模块

　　对于放在远程的一个无人看管的系统来说，最重要的一点就是容错能力，必须能够在任何错误的情况下自动恢复到正常运行状态，这一部分就是通过系统监控模块实现的。在GPS终端中，经常出现的异常包括有TCP连接中断和网络连接中断，这两种错误是有区别的，解决的方法也不一样。TCP连接中断指的是TCP连接进入异常状态，不能在该连接上进行数据的收发工作。这种错误产生的原因是GPRS网络有时会进入伪死状态，而导致虽然还在网络上，但是数据的收发工作无法进行。通过在每个连接上设置一个收发超时计时器可以发现这种错误。当有数据传输时即复位计数器，如果计数器超时，则表明TCP连接中断，此时应该根据工作模式而采取不同的处理。如果是工作在客户端模式，需要再次与服务器连接，如果工作在服务器模式，则只需要简单的断开连接即可。

　　对于网络连接中断的情况探测起来比较困难，一般是通过监测长时间没有数据通信来判断。如果一旦发生此类错误，则需要重新进行网络的连接工作。

　　由于软件难免会有一些未曾发觉的错误，在发生此类错误的时候则由硬件看门电路复位系统，并且在下次软件启动时将此类错误发生过的信息远程传送到服务器。

　　3 服务器端软件的设计

　　GPS服务器程序可以采用两种方式与远程的GPS终端建立连接，一种是采用TCP方式，另外一种是采用串口通信方式。在采用串口通信方式时，需要编制一个虚拟串口驱动程序，将一个TCP连接模拟成为一个串口，这样服务器就可以像 *** 纵M12一样对远程的GPS终端进行 *** 作了。

　　GPS服务器和远程GPS终端之间的通信协议采用了原始的M12通信命令，核心模块在GPS服务器和M12之间进行了数据透明转发的作用。M12支持有两种通信数据格式： 一是Motorola二进制数据指令格式，在采用Motorola二进制格式时，通信速率可以保证在9600bps;另一种是NMEA-0183格式，其通信速率只有4800bps，同时在初始化GPS时还需要加入由Motorola二进制转化为NMEA-0183的指令。因此建议使用Motorola二进制数据格式。

　　在此设计当中，关键的环节在于两个方面，一是连接的建立，二是M12的初始化。GPS终端返回的定位信息数据格式如下：

　　@@EamdyyhmsffffaaaaoooohhhhmmmmvvhhddtnTImsd imsdimsdimsdimsdimsdimsdimsdsC。

　　时间信息：m月，d日，yy年， h小时，m分，s秒。

　　位置信息：aaaa纬度，oooo经度，hhhh椭球高度。

　　在所有信息终止的前的一个字节为校验和，是所有信息字节的“异或”。

　　收到数据后，只要对数据进行解码，就可以获得定位信息以及时间。

　　4 服务器端的考虑

　　在GPRS联网中，必须注意的一个概念是APN。在登陆GPRS时，采用的APN不同，GPS终端和服务器之间所能采用的方式也有所不同。

　　如果采用公网APN(cmnet)，那么服务器端只要有一固定公网IP即可，此时Radius服务器由移动公司提供，GPS终端上网后的IP也是由移动公司的Radius服务器随机分配的。GPS终端与服务器必须经过NAT(Network Address TranslaTIon，网络地址变换)后才能通信，而从我们数据服务器看过去的GPS终端的IP地址也不是它的真正地址。因此，GPS终端与数据服务器之间的连接只能由GPS终端发起，换言之，即GPS终端只能工作在客户状态。在采用公网时虽然可以节省开支，但需要考虑安全性问题，因为这时候是与Internet直接连通的，并且客户之间也不可以直接访问。

　　与公网APN相对应的一种方式是采用私有APN，即用户向移动申请一个APN号。在采用这种方式时，所有登陆这个APN的用户可以通过IP地址互相访问，因此在数据量比较小的时候甚至可以采用一个也使用GPRS终端的用户做服务器。Radius服务器的设置比较灵活，可以采用移动公司的Radius服务器，也可以自建一套Radius服务器。自建Radius服务器的最大好处就是GGSN会将验证信息发送给我们，我们可以根据号码或者其它信息为其分配一个静态IP地址，非常适合GPS终端作为服务器运行。

　　Radius服务器可以采用一些商用的服务器，但从实践中看，自己编写一套Radius服务器可能更加适合GPRS。

　　5 结 论

　　对系统进行了全面的测试，在传输效率上面，本系统表现的非常良好，连接上网络的时间仅需要3s左右。在使用Class 12的GPRS模块时，传输速率可以达到38kbps的上传速度以及44kbps的下传速度。对于一般的数据采集设备能够保证数据的及时传输，在发生GPRS网络短暂失效时，可以在网络恢复后的10s内重新在线，基本上保证了无间断传输，因此可以满足GPS用户的需要。