Design of GPS terminal supporting GPRS based on IP2022 chip

This paper will introduce a GPS system that supports GPRS, and give a detailed description of the hardware and software design involved. Through this model, the remote transmission of GPS positioning information data can be achieved relatively well.

1 System Model

Figure 1 is the system model of this solution. The positioning data collected from the GPS terminal is transparently transmitted to the remote GPS server through the GPRS network. The remote GPS server can obtain the positioning information by decoding the GPS data. The detailed process can be summarized as follows:

① First, the GPS terminal sends a GPRS login request including the APN number and logs into the GPRS network;

② The SGSN located in the mobile network finds the registered Radius server according to the APN in the login request and sends the user authentication information to the Radius server;

③ The Radius authentication server confirms whether the request is from a legitimate user based on the authentication information passed. If it is a legitimate user, it will assign an IP address to the user according to the configuration;

④ The Radius server sends a confirmation message carrying the user address to the GGSN;

⑤ After the GPS terminal obtains the IP address, it can establish a TCP connection with the GPS server according to the configuration (as a server or client);

⑥ After the connection is established, the positioning information data collected by the GPS terminal will be transparently transmitted to the GPS server through the established TCP data connection;

⑦ When the GPS server has control commands or other data to send downward, it can be transmitted to the GPS terminal through the TCP connection;

⑧ The GPS terminal can establish a data connection with the user management server as a server or client according to the configuration. The user management server monitors, manages and remotely updates the system kernel program of the GPS terminal through this connection.

2 GPS Terminal Design

2.1 Hardware Design

The circuit block diagram of the GPS terminal is shown in Figure 2. The core of the GPS terminal is a network processor responsible for TCP/IP data transmission: the IP2022 chip. IP2022 is a high-performance network processor from UbiCom, with a processing power of 100MIPS and optimized specifically for network applications. Two full-duplex serializer/deserializer (Ser/Des) hardware units are integrated in the IP2022 chip, which can be directly connected to various commonly used interfaces. This function enables it to implement on-chip 10Base-T Ethernet, USB, and various other fast serial protocols. Because of the Ser/Des hardware unit, IP2022 is also easy to convert from one protocol to another, so it is more suitable for implementing GPS terminals.

The IP2022's software modules include USB, UART, I2C, SPI, and a complete TCP/IP stack, which can provide high-speed computing, flexible I/O control, and efficient data processing while executing applications.

In this system, two Ser/Des hardware units of IP2022 and its TCP/IP protocol stack are mainly used. The two full-duplex Ser/Des hardware units are converted into two standard RS232 interfaces through the serial port conversion circuit (core is MAX232), which facilitates communication with the GPS module and GPRS module.

The system clock module provides the clock pulses required for the hardware system to work. This part is relatively simple, but there are two aspects that need to be paid attention to. The first is the choice of crystal oscillator. Although IP2022 also supports passive crystal oscillators, it is found in actual applications that active crystal oscillators are more compatible with IP2022, so it is better to choose active crystal oscillators when possible. The second is the choice of crystal oscillator frequency. Since the baud rate of serial communication is the frequency division of the crystal oscillator frequency, if the crystal oscillator frequency is not selected properly, garbled characters will appear during serial communication. According to experiments and calculations, the 4.9152MHz crystal oscillator can well support a variety of commonly used baud rates.

Program writing and debugging are achieved through the online programming interface. IP2022 supports online programming and debugging. This part mainly leads out the programming interface of IP2022, provides appropriate isolation protection, and connects to the parallel port of the debugging machine through the SPI and parallel port conversion circuit.

In this system, there are two internal voltages, one is 3V required by the interface device, and the other is 2.5V required by IP2022. These two voltages are converted by the power conversion module. Since the GPRS module has a large instantaneous current when sending data, the power conversion module also provides sufficient power and necessary protection.

The GPRS data module realizes the function of GPRS transmission, which is equivalent to an ordinary modem. The more popular one on the market is Motorola's G18. When communicating with the GPRS data transmission module, it does not use direct manipulation of the GPRS data transmission module interface, but connects through RS232, which greatly reduces the dependence on the GPRS data transmission module. Users can select the GPRS data module according to their needs.

The GPS receiver uses Motorola's M12, which is connected to the RS232 interface unit through a serial port.

2.2 Software Design

In the GPS terminal software design, in order to facilitate future expansion, a strict layered structure is adopted. The specific software structure is shown in Figure 3.

2.2.1 Serial port driver module

The serial port driver module is used to complete the operation of the serial port, provide the upper layer with the function of configuring the serial port parameters, and report to the upper layer through the IndicateReceive and IndicateSend callback functions when data is received or sent. The upper layer software can call Send and Receive to send and receive.

2.2.2 Network driver module

The GPRS module in the hardware only provides a hardware channel, and the data connection with the server must be completed through software. During communication, the software first connects to the GPRS network through the GPRS module's unique commands (usually AT+CGMD), then establishes a data link through the PPP protocol, and finally communicates with the remote server through the TCP/IP protocol. This part and the network operation functions are implemented in the network driver module. Similar to the serial port driver module, the network driver module also provides some data transmission services.

2.2.3 Bridge Module

Since the serial port is a slow connection, the communication between the host and the serial port is sometimes even a single-byte operation. If each such small communication is sent through a separate TCP packet, for example, one byte of data, this will generate some 41-byte packets: 20 bytes of IP header, 20 bytes of TCP header and 1 byte of data. If it is on a high-speed network (such as a local area network), these small packets usually do not cause trouble, but if it is on a network such as GPRS (the average round-trip time is as high as hundreds of ms), it will increase the possibility of congestion and make the network efficiency extremely low. In the usual TCP/IP implementation, the Nagle algorithm is generally used to solve this problem. However, there is no such function in the Ubicom protocol stack, so this algorithm must be implemented by yourself. Considering the lack of dependence on the underlying hardware structure, the author implements it in the bridge module instead of in the network driver module. In the algorithm implementation, when serial port data arrives, for small packets, it is not sent immediately, but waits for a period of time (about 200s). If no small data arrives during this period, it will be sent, otherwise the data will be accumulated and sent. Of course, some systems require immediate issuance, so this function can also be canceled through configuration. After this implementation, the efficiency has been greatly improved. The specific effect can be referred to the experimental data below.

2.2.4 Auxiliary modules

In the introduction of some modules above, we can see that some key data must support user configuration, such as serial port communication speed, stop bit, APN to which GPRS in the network driver module is connected, account, password, working mode (whether to run as a server or client), static IP or dynamic IP, etc. This part of data is stored in the external memory by the configuration module and loaded by the configuration module every time the system starts. The auxiliary module also includes an important submodule: the remote management module, which realizes the remote management of the GPS terminal, including remote tracking and remote update program. The operation status of the system is counted by the statistics module, and then can be reported through the remote management module.

2.2.5 System Monitoring Module

For an unattended system placed in a remote location, the most important point is fault tolerance. It must be able to automatically recover to normal operation in the event of any error. This part is achieved through the system monitoring module. In GPS terminals, common exceptions include TCP connection interruption and network connection interruption. These two errors are different and the solutions are also different. TCP connection interruption means that the TCP connection enters an abnormal state and data cannot be sent and received on the connection. The reason for this error is that the GPRS network sometimes enters a pseudo-dead state, which results in the inability to send and receive data even though it is still on the network. This error can be discovered by setting a send and receive timeout timer on each connection. When there is data transmission, the counter is reset. If the counter times out, it indicates that the TCP connection is interrupted. At this time, different treatments should be taken according to the working mode. If it is working in client mode, it is necessary to connect to the server again. If it is working in server mode, it is only necessary to simply disconnect.

It is difficult to detect network disconnection, which is usually detected by monitoring the lack of data communication for a long time. If such an error occurs, the network connection needs to be reconnected.

Since software will inevitably have some undetected errors, when such errors occur, the hardware watchdog circuit will reset the system and remotely transmit the information that such errors have occurred to the server the next time the software is started.

3. Design of server-side software

The GPS server program can establish a connection with a remote GPS terminal in two ways, one is TCP and the other is serial communication. When using serial communication, you need to compile a virtual serial port driver to simulate a TCP connection into a serial port, so that the server can operate the remote GPS terminal like operating M12.

The communication protocol between the GPS server and the remote GPS terminal uses the original M12 communication command. The core module performs transparent data forwarding between the GPS server and M12. M12 supports two communication data formats: one is the Motorola binary data instruction format. When using the Motorola binary format, the communication rate can be guaranteed to be 9600bps; the other is the NMEA-0183 format, whose communication rate is only 4800bps. At the same time, when initializing GPS, it is also necessary to add the command converted from Motorola binary to NMEA-0183. Therefore, it is recommended to use the Motorola binary data format.

In this design, the key links are two aspects: one is the establishment of connection, and the other is the initialization of M12. The positioning information data format returned by the GPS terminal is as follows:

@@Eamdyyhmsffffaaaaoooohhhhmmmmvvhhddtntimsd imsdimsdimsdimsdimsdimsdimsdsC。

Time information: m month, d day, yy year, h hours, m minutes, s seconds.

Location information: aaaa latitude, oooo longitude, hhhh ellipsoid height.

The byte before the end of all information is the checksum, which is the "exclusive OR" of all information bytes.

After receiving the data, the positioning information and time can be obtained by decoding the data.

4 Server-side considerations

In GPRS networking, one concept that must be paid attention to is APN. When logging in to GPRS, different APNs are used, and the methods that can be used between the GPS terminal and the server are also different.

If the public APN (cmnet) is used, the server only needs to have a fixed public IP. In this case, the Radius server is provided by the mobile company, and the IP of the GPS terminal after accessing the Internet is also randomly assigned by the Radius server of the mobile company. The GPS terminal and the server must go through NAT (Network Address Translation) before they can communicate, and the IP address of the GPS terminal seen from our data server is not its real address. Therefore, the connection between the GPS terminal and the data server can only be initiated by the GPS terminal. In other words, the GPS terminal can only work in the client state. Although it can save costs when using the public network, security issues need to be considered because it is directly connected to the Internet at this time, and clients cannot directly access each other.

A method corresponding to the public APN is to use a private APN, that is, the user applies for an APN number from China Mobile. When this method is used, all users who log in to this APN can access each other through IP addresses. Therefore, when the amount of data is relatively small, even a user who also uses a GPRS terminal can be used as a server. The setting of the Radius server is relatively flexible. You can use the Radius server of China Mobile or build a set of Radius servers yourself. The biggest advantage of building a Radius server yourself is that GGSN will send the verification information to us, and we can assign a static IP address to it based on the number or other information, which is very suitable for GPS terminals to run as servers.

The Radius server can use some commercial servers, but from a practical point of view, writing a set of Radius servers by yourself may be more suitable for GPRS.

5 Conclusion

The system has been fully tested. In terms of transmission efficiency, the system performs very well. It only takes about 3 seconds to connect to the network. When using the Class 12 GPRS module, the transmission rate can reach 38kbps upload speed and 44kbps download speed. For general data acquisition equipment, it can ensure timely data transmission. When the GPRS network fails temporarily, it can be back online within 10 seconds after the network is restored, basically ensuring uninterrupted transmission, so it can meet the needs of GPS users.