GT06 Protocol Explained: The Complete 2026 Developer Guide

Short answer: The GT06 protocol is a binary TCP message format used by millions of GPS vehicle and asset trackers to talk to a server. A GT06 frame is bracketed by 0x7878 and 0x0D 0x0A, carries a single-byte protocol number that identifies the message type, and ends with a CRC-16/X-25 checksum. This guide walks the byte structure, the login handshake, and the integration bugs we see most often.

If you build software that talks to GPS trackers, the GT06 protocol is the one you cannot avoid. It is the de-facto wire format for vehicle tracking hardware that ships out of Shenzhen — and that means it is the wire format for tens of millions of devices in the field.

We've manufactured GT06-compatible hardware at SKYWONDER since 2011 — 20+ million units across 50+ countries — so this guide is the byte-level walkthrough we wish someone had handed us when we first integrated. That includes our own GT06 4G tracker, a no-monthly-fee hardwired model that speaks the protocol natively — so you can integrate it against any GT06 server without translation layers. Frame structure, message types, the CRC most developers get wrong on the first try, and a real worked example of decoding a position packet.

What is the GT06 protocol?

The GT06 protocol is a binary, length-prefixed TCP messaging format that GPS trackers use to send location, status, and alarm data to a server, and to receive commands back. It was published by Concox (now Jimi IoT) around 2013 and has since been adopted, with variations, by dozens of Chinese GPS hardware manufacturers including SKYWONDER.

In plain terms: when a tracker boots and finds a cellular network, it opens a TCP socket to your server, sends a login packet identifying itself by IMEI, and then streams position and status packets every few seconds. Your server validates each packet, stores the data, and replies with ACKs and the occasional command. The protocol number — a single byte in every frame — tells you which kind of packet you are looking at.

Why do so many GPS trackers use GT06?

The Berg Insight 2025 report puts the installed base of active commercial fleet management systems in North America alone at 19.2 million units, projected to reach 33.2 million by 2029 (Berg Insight, Fleet Management in the Americas, November 2025). A meaningful share of those devices — and a much larger share of the global tracker market — speak some flavor of GT06.

There are three reasons GT06 won.

It is compact. GT06 is binary, not text. A position packet is roughly 30 bytes on the wire versus 200+ bytes for an equivalent NMEA-over-TCP message. When you are paying per megabyte on a global SIM, that 6× difference compounds across millions of devices.

It is open enough. Concox published the spec; nobody enforces a license. Manufacturers — us included — could ship hardware compatible with existing tracking platforms without negotiating royalties. Open-source servers like Traccar and OpenGTS implement GT06 natively, which means a reseller can buy a tracker on Monday and have it reporting to a self-hosted server on Tuesday.

It is well-documented in code. Even where the original PDFs are dated, the Traccar Java decoder maintains working implementations for every common variant. Developers read the code instead of the spec, and the code is current.

What does a GT06 message look like on the wire?

Every standard GT06 frame is wrapped in fixed start and stop bytes, with a length-prefixed payload in between. There are two frame variants — a 1-byte-length "standard" frame and a 2-byte-length "extended" frame — distinguished by the start bits.

The standard GT06 frame. Extended frames swap 0x7878 for 0x7979 and the 1-byte length for a 2-byte length.

GT06 standard frame fields

A practical detail that catches new implementers: the length byte does not include the start bits, the length byte itself, the CRC, or the stop bits. It counts only the bytes from protocol number through information serial number. If you write a buffer-allocator that assumes "length = total frame size," every frame after the first will look corrupted.

How does the GT06 login handshake work?

A GT06 login is the first frame a tracker sends after the TCP socket opens. According to Concox's published v1.8.1 specification, the protocol number is 0x01 and the payload is the device's IMEI encoded as 8 bytes in BCD (Binary-Coded Decimal). Your server must reply within the device's idle timeout — typically 30 to 60 seconds — or the tracker disconnects and retries.

Here is the exact byte sequence:

1. Read the start bits — confirm 0x78 0x78. If you see 0x79 0x79 instead, you are decoding an extended frame and the length field is 2 bytes.

2. Read the length byte — typically 0x0D (13 decimal) for a standard login: 1 (protocol) + 8 (IMEI) + 2 (info serial) + 2 (CRC) = 13.

3. Read the protocol number — 0x01 for Login.

4. Read 8 bytes of IMEI — packed BCD, two digits per byte. For IMEI 123456789012345, the bytes are 0x01 0x23 0x45 0x67 0x89 0x01 0x23 0x45 (left-padded with a leading zero).

5. Read the 2-byte information serial number — copy it; you will need it for the ACK.

6. Read the 2-byte CRC — verify it against your own CRC-16/X-25 computation over the length byte through the information serial.

7. Reply with the login ACK — exactly 10 bytes: 0x78 0x78 0x05 0x01 [serial_hi] [serial_lo] [crc_hi] [crc_lo] 0x0D 0x0A. The CRC is computed over 0x05 0x01 [serial].

One subtlety worth flagging: some firmware variants treat any reply within the timeout as acceptance, even a malformed one. Send the correct ACK anyway. Trackers that get sloppy ACKs from a server will sometimes increment a retry counter on the next reboot and eventually fall back to a hard-coded factory server — which is exactly the scenario that will surface as a customer support ticket six weeks later.

How do you decode a GT06 GPS position packet?

Let's walk a real example. Here is a GPS+LBS packet (protocol number 0x12) as it would arrive on a TCP socket:

78 78 1F 12 14 05 15 0E 1F 18 CC 02 80 99 1B 09 67 6F E6 00 9F 02 78 00 14 01 CC 27 23 9F 00 1A 6E 31 0D 0A

Decoding it field-by-field:

• 78 78 — start bits (standard frame).

• 1F — length byte = 31. The CRC is computed across the next 31 bytes.

• 12 — protocol number: GPS + LBS (cell-tower fallback).

• 14 05 15 0E 1F 18 — date/time. Year+2000, month, day, hour, minute, second, all single bytes. This decodes to 2026-05-21 14:31:24 UTC.

• CC — high nibble = GPS info length (12), low nibble = satellite count (12).

• 02 80 99 1B — latitude, big-endian 32-bit integer, divide by 30,000 to get arc-minutes, then convert to decimal degrees.

• 09 67 6F E6 — longitude, same encoding.

• 00 — speed in km/h.

• 9F 02 — course/status flags (2 bytes).

• 78 00 14 01 CC 27 — MCC, MNC, LAC, Cell ID — the LBS fallback identifiers.

• 23 9F — information serial number.

• 00 1A 6E 31 — wait, that's wrong; the CRC is only 2 bytes. Let me re-walk: the last 4 bytes before stop bits are [crc_hi] [crc_lo] 0x0D 0x0A. So CRC = 6E 31 and stop = 0D 0A. The extra bytes above are part of the LBS extension on some variants — always check the length, not your assumption.

That last note is the single biggest reason a developer thinks GT06 is "inconsistent": the LBS portion is variable-length across firmware variants. Always trust the length byte over the field positions you have memorized.

What GT06 protocol numbers do you need to handle?

The original Concox spec defined fewer than a dozen protocol numbers. The real-world dialect — cross-referenced against the production Traccar decoder — has grown to several dozen, because every variant adds its own message types for OBD, dashcam, RFID, peripheral, and BMS data. Here are the ones you actually need to implement first.

The 12 GT06 protocol numbers you'll see in 80% of real traffic

If you implement those 12, you cover the vast majority of real-world packets. Beyond those, expect drift between manufacturers — for example, our hardwired vehicle trackers like the GT06, GX3, GX7, GT10, and H8 add a small set of SKYWONDER-specific status flags inside 0x16 that won't appear on a stock Concox firmware.

How does GT06 compute its CRC?

GT06 uses CRC-16/X-25, also known as CRC-16/IBM-SDLC or the ITU-T V.41 HDLC FCS — the same checksum used in PPP framing. The parameters are: polynomial 0x1021, initial value 0xFFFF, reflected input, reflected output, and a final XOR of 0xFFFF.

The CRC is computed over the length byte through the information serial number — not the start bits and not the stop bits. A reference implementation in Python:

def gt06_crc(data: bytes) -> int:
    crc = 0xFFFF
    for byte in data:
        crc ^= byte
        for _ in range(8):
            if crc & 1:
                crc = (crc >> 1) ^ 0x8408   # reversed polynomial
            else:
                crc >>= 1
    return crc ^ 0xFFFF

That polynomial constant — 0x8408 — is the bit-reversed form of 0x1021, which is what the reflected variant of CRC-16 actually computes against. If you blindly use a stock CRC-16-CCITT function from a generic library, you will get the wrong checksum. Every single time.

What are the most common GT06 implementation bugs?

From our developer-support inbox at SKYWONDER, across 14 years and 50+ partner countries, four bugs dominate the first-integration ticket queue.

From the field: the #1 GT06 integration bug

SKYWONDER engineering data, 2026. The single most common GT06 implementation bug we see is CRC misimplementation. Developers reach for a generic "CRC-16" library function without specifying the X-25 parameters GT06 actually requires (polynomial 0x1021, initial 0xFFFF, RefIn/RefOut true, XorOut 0xFFFF). The symptom is universal — every packet rejected, no obvious diagnosis — and it accounts for a meaningful share of every new partner's first-week support load.

The other three you should expect:

• Mis-reading the length byte. The length covers protocol number through information serial only. Implementers who assume it covers the entire frame size will desync after the first packet. Always advance your buffer by length + 5 bytes (start 2 + length 1 + CRC 2 + stop 2 = 5, minus the length-byte itself which is already counted, plus the start/stop bits which are not).

• Treating BCD as ASCII. The IMEI in the login packet is BCD-packed, not ASCII. A device with IMEI 123456789012345 sends 0x01 0x23 0x45 0x67 0x89 0x01 0x23 0x45 — eight bytes, not fifteen. Decoders that try to interpret those bytes as ASCII characters will log nonsense IMEIs and never match real devices.

• Ignoring the information serial. The 2-byte serial number must be echoed back in the ACK. If you reply with serial 0x0000 regardless of what the device sent, some firmware variants will treat the ACK as invalid and retransmit indefinitely — flooding your inbound queue without you understanding why.

• Hard-coding payload layouts per protocol number. The same protocol number can carry different payload layouts on different firmware variants. The Traccar source code has over 60 message-type constants because the wire format genuinely fragments per manufacturer. Build your decoder around the length byte first, the protocol number second, and the device's known firmware variant third.

Why this matters if you're evaluating GT06 right now

If you're at the stage of deciding whether to add GT06 support to your tracking server, the right question isn't whether to support it — it's which variants you'll see in the field. A reference card with the 12 most common protocol numbers, the CRC pseudocode, and the login ACK byte sequence on one page is a faster path to a working integration than reading the original PDF cold. Print the card; you'll come back to it.

How does GT06 compare to other Chinese tracker protocols?

GT06 is not the only binary protocol in the Chinese GPS tracker ecosystem. The two you will encounter alongside it are JT/T 808 — the Chinese national standard for commercial vehicle tracking, mandatory in many domestic Chinese fleet deployments — and the older GT02 from Concox.

The practical differences:

GT06 vs JT/T 808 vs GT02 — practical differences

If your platform is meant to ship internationally and integrate with Chinese-OEM hardware, GT06 is the right default. If you're specifically targeting regulated Chinese commercial fleets, you'll need JT/T 808 alongside it.

SKYWONDER B2B, OEM & white-label terms

If you are evaluating SKYWONDER hardware to integrate against your GT06 server, here is the practical summary integrators ask for most:

• Manufacturer since 2011 — 20M+ units shipped, partners in 50+ countries.

• Certifications — hardware certified to CE, FCC and RoHS; quality system certified to ISO 9001.

• Low MOQ for new partners — start small and scale; OEM customization including firmware-level protocol tweaks available at higher volumes.

• Predictable lead times, confirmed at quotation.

• Direct firmware and warranty support — including engineer-to-engineer help on protocol issues, with no distributor middle layer.

• Full product range — see the SKYWONDER product catalog for vehicle trackers, OBD trackers, wireless asset trackers, and AI dashcams. Every device speaks GT06 or a documented variant.

• Traqcare platform option — if you would rather not build a tracking server from scratch, our Traqcare GPS tracking software is the fastest path to a working white-label deployment.

For current MOQ, lead time, warranty terms, and B2B / OEM pricing for your country, contact our partnerships team.

Frequently Asked Questions

What is the GT06 protocol?

The GT06 protocol is a binary TCP messaging format used by GPS vehicle and asset trackers to send location, status, and alarm data to a server. It was developed by Concox (now Jimi IoT) and is now implemented by many Chinese GPS hardware manufacturers, making it one of the most widely deployed tracker protocols in the world.

Who invented the GT06 protocol?

GT06 was developed by Concox Information Technology (now part of Jimi IoT), a Shenzhen-based GPS tracker manufacturer. Concox first published the protocol publicly around 2013. The original GT06N specification has since been extended by dozens of manufacturers, including SKYWONDER, with additional message types for OBD, dashcam, and asset-tracking use cases.

Is the GT06 protocol open or proprietary?

The GT06 protocol is semi-public. Concox publishes the core specification freely and most manufacturers have adopted it without a formal license. However, there is no central standards body — extensions vary by manufacturer, which is why open-source decoders like Traccar maintain dozens of variant message types alongside the original.

What CRC algorithm does the GT06 protocol use?

GT06 uses CRC-16/X-25, also known as CRC-16-IBM-SDLC or the ITU-T V.41 HDLC FCS. The parameters are polynomial 0x1021, initial value 0xFFFF, reflected input and output, and final XOR 0xFFFF. The checksum is computed across the length byte through the information serial number — not the start or stop bits.

What is the difference between GT06 and GT02?

GT02 was an earlier 2G-era protocol from Concox with a simpler frame and fewer message types. GT06 introduced longer frames, the 2-byte information serial number, a richer CRC, and extended frame support via the 0x7979 start bits. New deployments in 2026 almost always use GT06 or a GT06 variant — GT02 is legacy only.

Can I use the GT06 protocol with non-Concox trackers?

Yes. Many manufacturers — including SKYWONDER — implement GT06 or a GT06-compatible variant on their hardware so that resellers and integrators can plug devices into existing tracking platforms like Traccar, GpsGate, OpenGTS, or their own server. Always confirm the exact variant and any vendor-specific extensions before integration.

How do I respond to a GT06 login packet?

Reply with a 10-byte ACK: 0x78 0x78 0x05 0x01 [2-byte serial echoed from the device] [2-byte CRC] 0x0D 0x0A. The length byte is 0x05 because the CRC covers length + protocol + serial = 5 bytes. If you fail to ACK within the device's timeout (typically 30 to 60 seconds), the tracker disconnects and retries.

About the author

Sam K. Martin leads B2B partnerships at SKYWONDER Technology Co., Ltd., a Shenzhen-based GPS tracker, 4G dashcam, and Traqcare fleet-platform manufacturer. SKYWONDER has manufactured tracking hardware since 2011, shipped more than 20 million units, and supports resellers, white-label brands, and OEM partners across 50+ countries. Sam works directly with new partners on hardware selection, protocol integration, and reseller economics.

Related reading: Protocol & Tech

• Best Anti-Theft Device for Cars in 2026: Tested + Buyer's Guide

• Best GPS Tracker for Android Phone 2026: Family Safety Guide

• How to Start a GPS Tracking Business in 2026 (From Zero to First 100 Customers)