A GPS tracker protocol is the language used by a tracking device to send a message containing the location and sensor data to the server: the message format, handshake and the acknowledgements. It is the protocol, not the brand name, that determines if it will work or not with your platform. This guide covers the common protocols (Teltonika and Queclink are just a few), as well as how to make sure that the to-be-purchased device complies with the protocol before you make your purchase.
To sum up, GPS tracker compatibility is founded on whether your platform will be compatible with the device's communication protocol, and the particular variant of that protocol. Prior to deployment, verify the model/firmware, the supported codec/protocol, server address/port settings, and location data/sensor data. Test prior to ordering a quantity of the same device.
This is a white label GPS tracking software white label that Fleet Stack provides. The information on the protocol below has been taken from vendor documentation and open source documents referenced as they are used, and verified in 2026.
Key takeaways
A protocol is a way of communication between a tracker and a server: two devices of different manufacturers may use the same protocol, and multiple protocols may be offered by the same manufacturer.
There are several protocols you will find in different types of trackers, such as GT06 (Concox family), Teltonika (Codec 8 / 8 Extended / 16) and Queclink (@Track).
Most trackers are connected to a server using the port and IP address, and use the IMEI (IMEISV) to identify themselves, which must be supported by a decoder on the platform.
Compatibility is primarily a Software issue: A device is compatible if the platform can interpret its protocol and variant, which is why an open platform has a list of supported-protocols to publish.
AIS-140 compliance is a hardware-certification and state-registration issue, and does not impact on protocol choice.
What is a GPS tracker protocol & why is it important?
A GPS tracker protocol is the message format that a device uses to report to a server. It specifies the method used to open a connection, the method for identifying the device (usually an IMEI number), the encoding of a position record and the method for acknowledging each message received by the server. If a platform is compatible with a tracker, it means the platform can interpret that protocol.
This is important for resellers because you can purchase great hardware that your platform won't read. It's not a better piece of hardware, it's a platform that supports the protocol. Usually, a tracker will return information such as:
The telemetry device connects to the server's IP address and port using TCP or UDP, and then passes the message to the server's decoder for that protocol, which then passes the data to your platform.
If you're on the hardware-selection side of this decision, learn more about the difference in accuracy, bands and durability in our GPS tracking device buyer's guide. This article discusses the layer below: how your software communicates with the device.
Transitions and compatibility with GT06 protocol (Concox and compatible devices)
GT06 is a small binary TCP protocol made by Concox which is used in most low end ranges of trackers. It is a device which establishes a TCP connection with the server and then transmits a login packet with its IMEI, followed by location and status packets, which the server acknowledges. It's one of the most popular protocols for budget vehicle or asset tracking that has a wide clone ecosystem and low overhead.
Pro tip: Many manufacturers refer to their devices as being "GT06 compatible" so two different brands may use the same protocol. It helps resellers, but always check to see if it is the exact variant; vendors add custom fields. The specification for the protocol GT06 defines the structure of the packets.
This protocol allows for the exchange of static data and is used across different Teltonika protocols, such as Teltonika protocol (Codec 8, Codec 8 Extended and Codec 16).
The Teltonika devices (Teltonika FMB/FMC families) transmit data over Teltonika's internal codecs via TCP or UDP. The device is connected and does an IMEI handshake before sending AVL data records, which are acknowledged by the server via record count. The main codecs, per Teltonika's own wiki, are:
| Codec | Used for | Note |
| Codec 8 (0x08) | Standard AVL data sending | The default protocol of the FM device |
| Codec 8 Extended (0x8E) | FMBXXX family | Extends length fields in the codec; variable sized IO elements |
| Codec 16 (0x10) | AVL IDs above 255 | 2-byte event and AVL IDs, plus a generation-type field |
| Codec 12 (0x0C) | GPRS command messages | For sending commands, not routine data |
The codec stays unchanged throughout the transport (either in TCP or UDP). Both TCP and UDP are based on record-count acknowledgement and handshake with IMEI. Any platform that claims to support "Teltonika" should list the codecs it can decode as these codecs will differ from device to device.
Queclink protocol (@Track and the GV / GL series)
Queclink trackers are based on the air-interface protocol of Queclink: @Track (GV and GL series: e.g. GL300). This is because the message set is readable and well documented, making integration and debugging easier than some binary protocols as is the case with @Track. @Track is popular in asset tracking and OEM projects due to the ease of reading and well documented message set.
Other protocols you will meet (Ruptela, Meitrack and more)
Other than the “big three,” there are some other protocols that are seen frequently in reseller catalogues:
- Rutile: a binary protocol from the Lithuanian manufacturer, which is used in European fleets, as well as installations with a high density of CAN-bus.
- Meitrack (MeiTrack / T-series): Across all Meitrack's vehicle and personal trackers.
- Coban / TK103 and GPS103: older protocols that are still used on very low cost trackers.
- There are several different messages – suntech, sinotrack, topflytech, etc.
You do not need to learn each protocol. You have to have a platform that interprets your devices' ones. Here is a reference of an open source platform such as Traccar, which supports a large number of device protocols (around 200 as listed on its site), including GT06, Teltonika, Queclink, Ruptela and Meitrack, which illustrates how diverse the devices are and why the decoder's coverage is the deciding factor rather than the brand.
How can I determine whether or not a GPS tracker will work on a platform?
Compatibility is a question of software - and its answer is simple and consists of four steps:
- Identify the protocol of the device, rather than its model name. It is usually indicated on the datasheet or by the manufacturer (e.g. "GT06" or "Teltonika Codec 8 Extended").
- 2. Look at your platform's list of protocols supported. Support for the protocol is required, but not enough: also protocol variant, compatibility of the firmware, of transport and of the message types handled by the decoder. For Fleet Stack, please refer to the supported devices list.
- 3. Check if the server address is programmable. It is important to be able to point the device at your server IP, port (and preferably towards your own domain, see migration).
- Prior to purchasing a batch, test one end to end: Connect, check positions and key sensors have arrived, and check reporting interval.
The following protocol-to-platform table summarizes what a platform will require to read the common devices:
| Cryptographic protocol | Typical protocol-wise devices | Transport must decode | Platform must decode the cryptographic protocol |
| GT06 | Concox and GT06-compatible budget trackers | TCP | GT06 (confirm variant) |
| Ruptela | Ruptela FM / Eco series | TCP | Ruptela |
| Meitrack | Meitrack T / MVT series | TCP / UDP | Meitrack |
- Teltonika codecs Family FMB, FMC families TCP / UDP Codec 8 / 8 Extended / 16
- This is a TCP / UDP protocol that is used for tracking.
- Legacy Coban-style trackers TCP TK103 / GPS103
Does GPS tracker protocols impact AIS-140?
No. AIS-140 is an Indian standard for vehicle location tracking devices focusing on device certification and registration with the respective backend and not on the communication protocol. Supporting a device's protocol does not imply that the device or deployment would be AIS-140 compliant but rather that your platform would get the data from a device, and only the required hardware and functions being met would determine the device's or deployment's compliance. Check against authoritative sources, and refer to our AIS-140 compliance guide.
As a self-hosting advantage, why protocol support?
Instead of waiting for a SaaS vendor's roadmap to add or request a decoder for a new protocol on a platform you control. This is a direct advantage if a customer brings in an unusual tracker. It may also help with migration: If your trackers are running on your own domain, switching the servers might be a DNS change instead of a trip to your site, but it would depend on how each of the devices handle DNS and the firmware and would need to be tested first. To learn more about the reseller model of the white label GPS tracking software, and the difference between self-hosted and cloud-based GPS tracking, you can read further in our guide to cloud vs self-hosted GPS tracking.
Migration tip: Using your own domain (track.yourbrand.com) instead of a raw IP to point to the trackers can make the move to a new server later on easier because all you need to do is repoint the DNS instead of each device. It will depend on the device's ability to receive DNS, the default DNS cache and reconnection settings and the firmware, so be prepared to test it with a few devices before committing to using it in a fleet.
Frequently asked questions
Which is the most popular protocol used for GPS trackers?
There's no single answer and we don't have market-share data to rank them. In reality, GT06 is very frequently used on low-cost trackers, as many manufacturers produce GT06 trackers, and Teltonika and Queclink can be found on mid-range and OEM trackers. Verify the protocol for your particular device.
Are both GPS trackers compatible with each other?
Yes. Protocol and brand do not necessarily go hand in hand, and many budget devices are GT06, no matter the brand. However, the protocol name does not indicate compatibility alone: there may be variant device types and different firmware versions, and the precise device specification and testing for the platform prior to deployment is recommended.
Is GPS tracking by TCP or UDP?
Most use TCP to a server IP and port and identify to it by IMEI. There are also some protocols like Teltonika's codecs or Queclink @Track which support UDP. The transport will not alter the format of the message.
Which protocol does my tracker employ?
Look on the device data sheet or contact the manufacturer; typically it will be listed on the device as a protocol name like GT06 or Teltonika Codec 8. If your tracker is still offline, check out our article on why a GPS tracker goes offline.
Is there any need for a different decoder for every protocol on a tracking platform?
Yes. If the device doesn't support a decoder for the protocol that the platform is trying to read, then it won't be read. That's why you can find a list of supported protocols on the pages of open platforms, and why it's not the brand of the device that determines compatibility.
Does protocol impact other compliance or AIS-140?
No. AIS-140 certification is applicable to hardware and the registration of the same to the back-end. A supported protocol is not compliance – it will allow the data to reach your platform. Refer to the above AIS-140 guide for requirements.
Fleet Stack offers white label GPS tracking software that is self-hosted. Information in this article regarding protocol and devices has been verified against vendor and open source documentation in 2026; purchase based on specific protocol information from the specific vendor of your device.

0 Comments
No comments yet. Be the first to comment!
Please to post a comment