Zoo Communication Protocols for GPS Trackers (Part 2)



    This is a continuation of the article about network protocols used with GPS trackers. If in the first part we discussed frame decoders, then in the second part we look at options for encoding various types of useful data. Many manufacturers of GPS monitoring devices develop their own application-level protocols for transferring data from the device to the server, and sometimes developers resort to various sophisticated and not always clear solutions for encoding data.

    For those who have not read or forgot the first part, I recall that there are two main groups into which all protocols can be divided: text and binary. In text protocols, information is transmitted in the form of ASCII codes, and in binary, respectively, all data is encoded in big-endian or, less commonly, in little-endian binary form.

    Byte order (endianness)


    The order from senior to junior (big-endian) is standard for TCP and UDP, it is used in the headers of data packets and in many protocols of a higher level. Therefore, the byte order from high to low is often called the network byte order, and it is the de facto standard for encoding binary data in network protocols.

    short i = 1; // 0x00 0x01 - big-endian (network byte order)
                 // 0x01 0x00 - little-endian

    The problem is that central processors most often use the order from the youngest to the oldest (little-endian), and therefore many manufacturers of GPS trackers decided to encode the data in the same format that the data is stored in memory (i.e. little-endian) . The list of such manufacturers is quite large, so I will give only a few examples: Baltic Car Equipment (BCE, Lithuanian company), Cellocator (a large international company with headquarters in Israel) and GalileoSky (a well-known Russian manufacturer of GPS trackers with headquarters in Perm).

    Some manufacturers go even further and encode part of the data with one byte order, and part with another. For example, devices from the Chinese company Topflytech and the Polish manufacturer Tytan GPS send all data in standard network byte order, except for floating point numbers that are sent in a little-endian format. In fairness, it should be noted that Tytan GPS fixed the problem in the second version of its protocol.

    Geographical coordinates


    Coordinates (latitude from -90 ° to + 90 °, longitude from -180 ° to + 180 °) can be represented in various ways. GPS receivers usually return the value in degrees and minutes with decimal, with the positive coordinates represented by the letters “N” (north latitude) and “E” (east longitude), and the negative coordinates by the letters “S” (south latitude) and “ W ”(west longitude).

    The greatest variety of coordinate coding options can be found in text protocols. The sign of the coordinates can be represented either by a letter or by a sign before the value in degrees (in some cases, a positive sign is explicitly indicated). The value can be represented either in degrees with decimal fractions, or in integer degrees and minutes with a decimal fraction. Dots in decimal may be omitted, and the separator between latitude and longitude may also be absent. Here, for example, are several presentation options for Pentagon coordinates:

    38.870989, -77.055961 // degrees decimal
    3852.25934, N, 07703.35766, W // degrees (2 characters for latitude and 3 characters for longitude) and minutes in decimal
    W77.055961, N38.870989 // hemisphere and degrees decimal
    + 38.870989, -77.055961 // explicit indication of north latitude by a plus sign
    3852.2593N07703.3577E // no separator between coordinates

    In binary protocols, geographic coordinates are usually represented either by an integer that must be divided by a certain factor to get the coordinates, or by a floating-point number (usually 4 bytes).

    0x04 0x2b 0x9f 0xa4 -> 69967780 -> (/ 60/30000) -> 38.870989 // integer
    0xc2 0x9a 0x1c 0xa7 -> -77.055961 // floating point number (float)

    The coordinate sign may be stored separately from the coordinate value. For example, in the protocol from Tzone Digital Technology, the bits of the latitude and longitude signs are combined with the direction value in 2 bytes of data:

    0x03 0x0E // 0 0 0 0 0 0 1 1 0 0 0 0 1 1 1 0
              // | | | direction (9 bits) - 270 degrees
              // | | sign of longitude - minus (west longitude)
              // | latitude sign - plus (north latitude)

    Another interesting option for encoding coordinates in binary is the binary-decimal code (binary-coded decimal or just BCD). The essence of coding is that each decimal place of a number is written in the form of its four-bit binary code. For example, the latitude of the Pentagon in the protocols of the Chinese companies KHD or Gator will look like this:

    0x03, 0x85, 0x22, 0x59, 0x34 -> 38 degrees 52.25934 minutes

    Note that the hexadecimal notation exactly matches the decimal value. It turns out that the data encoded in BCD is relatively easy to read by a person, but, unfortunately, this type of encoding complicates the reading of these data by the computer, and also increases the size of the message.

    date and time


    The vast majority or even all protocols when transmitting coordinates to the server contain one or more time stamps. Usually this is the time for determining the coordinates of the GPS receiver, but sometimes the date and time of the internal clock of the GPS tracker at the time when the package was formed can be. Some trackers send two or even more timestamps.

    In text protocols, time and date are almost always broken down into separate components. Here are some examples of presenting the time of the last time transfer in Russia (October 26, 2014, 2 a.m.):

    2014/10 / 26.02: 00: 00 // date and time with delimiters
    020000.000, ... 261014 // time accurate to milliseconds
    141026 ... 020000 // date and time without delimiters
    20141026020000
    14/10/26 2:00 // date and time accurate to minutes

    An important point worth noting is that usually time is transmitted in GMT (UTC or GMT time zones). This is important because the server and tracker can be in different time zones. Some GPS trackers allow you to configure the time zone. At the same time, part of them reports the selected time zone to the server, and part - not. For those that do not report, you must manually set the zone on the server.

    One interesting example of a problem with time zones is the nameless protocol used in many cheap Chinese-made trackers. The tracker sends the local date (year, month, day) and time (hours, minutes, seconds), as well as time accurate to milliseconds GMT. The interesting thing in this case is that having this data, you can calculate the GMT date for time zones from GMT-12 to GMT + 12. For example, if at the input we have 2016-01-01 01:00:00 (local time) and 59: 00: 00.000 (GMT), then the output will be 2015-12-31 59: 00: 00.000 (GMT). Unfortunately, this method does not work for time zones with a deviation from the greenwich for more than 12 hours.

    Another noteworthy time representation is used in the standard TAIP protocol. Time is presented in weeks, days, and seconds from January 6, 1980. The significance of this date is not entirely clear, but it is the standard for many GPS receivers.

    Some protocols transmit to the server only the current time of day. In this case, the only thing that can be done is to substitute the current date according to the server version. Accordingly, this can lead to problems if the time of the server and device is different or for any delay in data transfer. For example, the device can transmit the time 23:59:59, and when you receive this message on the server, there will already be the beginning of the next day. One way to work around this problem is to compare the received timestamp with the current server time, and if the difference is more than an hour or several hours, then you need to add or subtract one day from the received date.

    In binary protocols, the date and time are either divided into separate components as well as in textual ones, or stored as a UNIX timestamp (the number of seconds or milliseconds since midnight (00:00:00 GMT) on January 1, 1970).

    Conclusion


    All the information presented in this article was accumulated during the work on the GPS monitoring server. The project is completely Open Source, and if anyone is interested, then the source code with the implementation of all the above protocols can be found on GitHub .

    Also, someone may be interested in the documentation for protocols for GPS trackers . Unfortunately, I cannot publish all available documents in the public domain, as some of them are confidential.

    Also popular now: