Gps Protocols – Part 1

A sample case – TKStar TK901

I had to deal with several GPS protocols and similar devices during the last years and I find more cases every day. Newer devices, clones, cheaper options, different kind of applications such as pet trackers, personal trackers, trucks, vehicles and even devices used to spy (despite of how controversial it sounds) are implementing protocols to communicate with different services.

I chose the TKStar TK901 because it represents a normal scenario where the device is new, not very well known or tested and it doesn’t fit any specific standard protocol (even when standard is such a strong statement in a sea of non-standard solutions). 

This device is intended to be used as a portable tracker, also advertised as anti-theft which is at least arguable in terms of effectiveness. I found it useful as a personal tracker but it has to be very visible (in a thin-layered backpack or so) to acquire signal properly. I guess the size of the device makes its antenna not so strong, or the battery consumption that is very low (most devices do not last more than some hours and this one can work for days).

Find below a link to the device if you are interested on buying it:

Protocol and Control

Most GPS protocols have commonalities despite of how messages are implemented. The biggest differences are always related to device’s quality, better quality mostly always leads to richer protocols. Besides, richer protocols are required in better devices to represent events or extended information.

For example, trucks’ devices come with several possible integrations such as panic button, RFID recognition to detect tags associated to a driver, fuel alarms, door alarms and so on. Another common extension in protocols is the ability to control configuration and behavior sending messages to the device. 

The majority of the simplest devices allows to configure them using SMS  commands (normal messages), giving the ability of changing the server and port they will report to, behavior such as speed alarm, sending SMS in case of some events, switching GDPR to 3G, control which phone number is allowed to administer the equipment and several other combinations.

At the minimum shared level, all of them will report at least the position. In general they will also report 2g/3g network information such as base stations, area codes, signal strength and satellite positioning information (which minimum level is whether or not is positioned).

The TK901 protocol is very simple. First, it can report a heartbeat/login message. Heartbeats are very common, they normally consist of a very small packet indicating minimum information intended to keep the socket open (GPS mostly always stay connected but servers usually close communications after some period of inactivity). TK901 heartbeat looks like the following example:

[3G*9010008512*000A*LK,0,0,100]

As a general rule which is not obviously written in stone, most protocols contain a start/end marker and a command. The base message format of TK901’s messages is

[3G*device_id*flags*command,....]

In this case, LK is a heartbeat message and it only reports few things. The most important property is the number 100 at the end, battery level, very common among GPS with internal battery (some of them must be connected to a car battery for example and don’t have internal battery)

Another common message found among similar devices is cellular network information. This device follows a common pattern:

[3G*9010008512*0047*GS,3,1,310,260,7121,25812,1,310,260,7121,12473,1,310,260,7121,25813,255]

GS is the command of network information and reports LAC, MCC, MNC, Station number and signal strength of all stations the GPS can detect. In that way it works exactly like a cellular phone (well, nowadays all of them are smart phones!). This information is important to analyze communication problems, blind areas, weak signal areas and so forth.

The third message I will mention here is pretty much shared across all GPS types, position information.

[3G*9010008512*0068*UD,210819,012719,V,00.000000,N,000.000000,E,000.00,0,0,0,25,100,0,0,00000000,1,1,310,260,7121,25812,17,0]

Command in this case is indicated as UD. 

Position messages

GPS devices try to report as much as possible using positioning messages. From my experience we will find very often the following properties:

  • Date and time the message was sampled in the GPS. It is possible to receive messages from many days ago if the GPS was accumulating packets to send not having signal. It is also configurable so it might be wrongly configured. 
  • Positioned or not. It means the device has GPS signal. Some devices are able to report they do not have signal but they were able to approximate the position using cellular antennas
  • Latitude and longitude. It is very important to remark the format can differ. A popular format for most properties is NMEA which I heavily suggest to read before dealing with these kind of devices. Some devices like the one I mentioning here use decimal coordinates. 
  • N/S and E/W indicators for latitude and longitude. Coordinates are always positive, the indicator is fundamental to construct a geographic point to process or store. This is part of the NMEA specification but even when coordinates are decimal, indicators will be reported too.
  • Speed. From my experience I found NMEA (Nautical miles), ground miles and metrical system (kilometers)
  • Direction angle (0-360). The direction the GPS is moving onto.
  • Event. Depending on the GPS type it is possible to receive one or more events, such as shock alarm, speed alarm, etc. In fact, events use to trigger a position report as well. 

The current device is very simple and there is no protocol documentation at the time being. Analyzing packages and correlating them to known protocols is a very fast way to get to understand and implement a protocol that lacks of documentation.

Final words

Take this article as an introduction to a very extensive world of similar devices. It is very normal to find similar types of communication in all sort of IoT devices as well.

Published by maxriosflores

Solution Architect for a decade. I designed, built and implemented software solutions for more than 25 years and every single day more interested on technology. I learned to code in a Texas Instruments with 16kb at 8 years old. I shared this passion with friends coding CZ Spectrums, MSX's and C64's. I worked in computers since my early 17's with super old tools like plain C and Quick Basic. I love math and computers as much as outdoors and family life.

Leave a comment

Your email address will not be published. Required fields are marked *