Implementing GPS System Supporting GPRS Using IP2022

frozenviolet

Implementing GPS System Supporting GPRS Using IP2022 [Copy link]

Abstract: With the development of mobile GPRS services, GPRS has become a better solution for remotely transmitting data collected on site back to the data center. This paper will introduce a GPS system and briefly introduce the key technologies involved, such as GPS terminal circuits, terminal software, and servers. The system can send GPS positioning information back to the GPS server through the GPRS network, and can transparently send the management data of the server to the GPS terminal, while supporting remote management of the GPRS terminal. The implementation of this system provides an effective solution for GPS users.


Keywords: GPRS GPS Remote data transmission IP2022


Introduction :

　　With the increasing application of GPS in social life, people's research on it is also becoming more and more in-depth. As an important part of GPS, the remote transmission of GPS data has also been changing with the development of communication technology, from the original cluster mode to the paging mode and then to the later SMS mode, all of which reflect people's pursuit of cost-effectiveness. With the development

　　of mobile GPRS services, the advantages of using GPRS for GPS data transmission are gradually emerging. Compared with traditional remote transmission methods (such as dialing by phone), GPRS data transmission has outstanding advantages. On the one hand, GPRS charges are relatively cheap, and a variety of tariff plans can be adopted. For users of large data volume services, monthly subscriptions are available. For users of small data volume services, charges can be made based on the amount of data communicated and the quality of service provided. On the other hand, in the GPRS network, users only need to establish a connection with the network once, and they can maintain this connection for a long time. They only occupy the channel and are charged when transmitting data. If they do not occupy the channel during the connection, they will not be charged. In this way, data collection points do not need to frequently establish connections, nor do they have to pay for transmission gaps. Moreover, GPRS can better support frequent, small-volume burst data services. In addition, the GPRS network has a fast access speed and provides seamless connection with existing data networks. Since the GPRS network itself is a packet data network that supports protocols such as TCP/IP and X.25, it can directly communicate with packet data networks (IP networks or X.25 networks) without the need for switching through networks such as PSTN [1]. Moreover, access is fast, taking only a few seconds, which is faster than circuit-based data services.

　　For high-level protocols, the TCP/IP protocol is used, making network access more direct and convenient than previous wireless data networks (clustering, two-way paging, GSM short messages).

　　This article will introduce a GPS system that supports GPRS, and give a detailed description of the hardware and software design scheme 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 to log in to the GPRS network;

② The SGSN located in the mobile 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, and if it is a legitimate user, it allocates an IP address to it 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 Design of GPS Terminal

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 100 MIPS and is optimized for network applications. Two full-duplex serializer/deserializer (Ser/Des) hardware units [2] 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. With 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 software modules of IP2022 include USB, UART, I2C, SPI, and a complete TCP/IP stack. It 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 pulse required for the hardware system to work. This part is relatively simple, but two aspects 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 realized through the online programming interface. IP2022 supports online programming and debugging. This part mainly leads out the programming interface of IP2022, provides proper 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 kinds of 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 instantaneous current of the GPRS module is very large 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 ones on the market are Motorola's G18.
When communicating with the GPRS data transmission module, the GPRS data transmission module interface is not directly manipulated, but connected 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 the serial port.

2.2 Software Design

　　In the design of GPS terminal software, a strict layered structure is adopted to facilitate future expansion. 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-specific 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 all 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

　　As 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 LAN), these small packets usually do not cause trouble, but if it is on a network such as GPRS (with an average round-trip time of up to hundreds of milliseconds) [3], it will increase the possibility of congestion and will make the network efficiency extremely low. In the usual TCP/IP implementation, the Nagle algorithm is generally used to solve this problem [4]. However, this function is not available in the Ubicom protocol stack, so this algorithm must be implemented by ourselves. Considering the independence from 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 200 seconds) [5]. If no small data arrives during this period, it is sent, otherwise the data is accumulated and sent. Of course, some systems require immediate sending, so this function can also be cancelled 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 module

　　In the introduction of some modules above, it can be seen that some key data must support user configuration, such as serial port communication speed, stop bit, APN to be connected to GPRS in the network driver module, 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 is started. The auxiliary module also includes an important submodule: remote management module, which realizes remote management of GPS terminals, including remote tracking and remote update program. The system operation status is counted by the statistics module and then reported through the remote management module.

2.2.5 System Monitoring Module

　　For a remote and unattended system, the most important point is fault tolerance. It must be able to automatically recover to normal operation in any error situation. This part is achieved through the system monitoring module. In GPS terminals, common abnormalities 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 the situation of network connection interruption. It is generally judged by monitoring the lack of data communication for a long time. If such an error occurs, it is necessary to reconnect to the network.

　　Since the software will inevitably have some undetected errors, when such errors occur, the hardware gatekeeper resets the system, and the information about such errors is remotely transmitted to the server when the software is started next time.

3 Design of server-side software

　　The GPS server program can establish a connection with the remote GPS terminal in two ways, one is TCP and the other is serial communication. When using serial communication, a virtual serial port driver needs to be compiled 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, and 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 instruction 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 the 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 hour, m minute, s second. Location information: aaaa latitude, oooo longitude, hhhh ellipsoid height.

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

　　After receiving the data, as long as the data is decoded, the positioning information and time can be obtained.

4 Considerations on the server side

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

　　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 network 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 Radius server yourself. The biggest advantage of building a Radius server yourself is that GGSN will send the verification information to us. We can assign a static IP address to it according to 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 Radius server yourself may be more suitable for GPRS.

5 Conclusion

　　The system has been fully tested. In terms of transmission efficiency, this system performs very well. It only takes about 3s 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.

　　Since this system is strictly isolated in functional modules in design, it can be expanded as a prototype system to support more GPS functions.