Zoo Communication Protocols for GPS Trackers (Part 1)

The purpose of this article is to introduce the reader to various application-level network protocols that are used in GPS trackers. Almost every manufacturer of equipment for GPS monitoring considers it their duty to invent a new protocol for the interaction between the device and the monitoring server. Often, when developing these, engineers resort to sophisticated solutions to save traffic or simplify life for device firmware developers.

At the transport level, in most cases, TCP and sometimes UDP are used. The application level protocols themselves can be divided into two large groups: text and binary. In text protocols, information is transmitted in the form of ASCII codes, and after conversion to a string, you can quite often parse data even in the absence of documentation. Text protocols contain a fairly large amount of redundant information, so some manufacturers use binary protocols in which data is transmitted in a big-endian or little-endian binary format.

Frame decoders

In the case of using TCP before decoding messages, it is necessary to split the data stream into separate frames. The standard for text protocols is breaking messages using one or more special characters. The most common character used as a delimiter is a line feed character (ASCII code 0x0A). Binary protocol messages typically contain a fixed-length header that includes a packet length field indicating the size of the data, or the size of the entire message.

Now consider some of the most interesting non-standard cases.

Binary Data in a Text Protocol

In the old version of the protocol of Shenzhen Xexun Technology Co, a checksum in binary format is transmitted after the text data. The problem is also complicated by the fact that there is no separator character. After converting to text, the message looks something like this (binary data is indicated by a symbol):


To extract data in this case, I had to use the redundancy of the text format and look for tags (longer than 2 characters): GPRMC and imei.

Binary messages without length in title

There are a lot of such protocols, but in most cases the decoding logic is quite simple. For example, all messages can be of a fixed length or the length can be uniquely determined by the type of message (the type of message is contained in a fixed header). In this case, the Taiwanese company Orion Technology distinguished itself, which describes its protocol using the following grammar:


Only a small part of the document is shown, from which it is clear that to determine the frame length with GPS data (TRACKING), you must first look at the type of the entire message, then take the number of different records (USER-LOG) from the data header and finally read the header of each record and sum the lengths.

Binary protocol with delimiter character

Ulbotech decided that using a special code (0xF8) to separate packets would be a good idea. Apparently, realizing later that this code can also sometimes occur in binary data, they decided to replace each of its occurrences with a code of two bytes (0xF7 0x0F). The problem is that this code can also be found in binary data, and therefore the code 0xF7 is replaced by the next code of two bytes (0xF7 0x00).

For example, if the tracker sends the following sequence:
0xF8 0x00 0xF7 0x00 0xFF 0xF7 0x0F 0xF8

then after decoding we get (delimiter removed):
0x00 0xF7 0xFF 0xF8

Mixed Protocols

Some protocols used in GPS trackers contain both binary and text messages. There are a lot of examples, in most cases, location data is transmitted in text form, and keepalive messages are transmitted in binary form to indicate an active connection between the server and the client.

An example is a protocol called WondeX from the Taiwanese company Wonde Proud. The keepalive message looks like this (little-endian):
0xD0 0xD7 0x1A 0x01 0xC7 0x54 0x44 0x3C

In this case, the first byte of the message (code 0xD0 cannot be found in text data) can determine the type and further, depending on the type, determine the frame size. In the case of a WondeX binary message, the frame has a fixed length, and text messages use a line feed as a delimiter.


Determining the frame length is only the beginning. After that, you need to decrypt the data itself, and here you can meet even more innovative solutions. At first I wanted to include everything in one article, but after writing the part about frame decoders, I decided that this information was already enough for one article. I will be glad to hear feedback and find out if it makes sense to write a sequel.

All information in the article was accumulated during the work on the GPS monitoring server. The Open Source project, and if anyone is interested, the source code with the protocol implementation can be found on GitHub .

Also, someone may be interested in a collection of protocols for GPS trackers .

Also popular now: