What does a tracker frame look like?
A tracker sends small binary packets, called frames, over TCP or UDP. Each protocol marks the start and end of a frame, puts a header in front, and adds a check value so the server can spot damage.
7E0002 0000 007261019004 0378 FF7E
- Start and end flag 7E
- Header: message ID, attributes, phone number, serial
- Body (empty for a heartbeat)
- XOR check byte
In a JT808 frame every byte between the two 7E flags is covered by one XOR byte. A GT06 frame uses a CRC instead, so a single flipped bit is almost always caught.
How is a JT808 frame built?
Read the parts in this order. Sizes are in bytes.
| Part | Size | What it holds |
|---|---|---|
| Start flag | 1 | Always 7E. |
| Message ID | 2 | 0200 is a location report, 0002 a heartbeat. |
| Body attributes | 2 | Bits 0 to 9 body length, bits 10 to 12 encryption, bit 13 sub-package, bit 14 version flag. |
| Protocol version | 1 | Only when bit 14 is set (2019 style). |
| Phone number | 6 (10 in 2019 style) | The terminal number as BCD digits. |
| Serial number | 2 | Counts up with every message the terminal sends. |
| Sub-package fields | 4 | Total parts and part number. Only when bit 13 is set. |
| Body | 0 to 1023 | Depends on the message ID. The length has 10 bits. |
| Check byte | 1 | XOR of every byte from the message ID to the last body byte. |
| End flag | 1 | Always 7E. |
Inside a frame, a 7E byte is written as 7D 02 and a 7D byte as 7D 01, so the flag never appears in the middle. The decoder undoes this first, then calculates the XOR on the real bytes.
What is inside a location report?
Message 0200 carries a fixed block of 28 bytes. Optional items follow it.
| Field | Size | Reading |
|---|---|---|
| Alarm flags | 4 | One bit per alarm. Bit names are in the tool and can be edited in the page settings. |
| Status flags | 4 | Bit 0 ACC on, bit 1 positioned, bit 2 south latitude, bit 3 west longitude. |
| Latitude | 4 | Degrees × 1,000,000 typical |
| Longitude | 4 | Degrees × 1,000,000 typical |
| Altitude | 2 | Meters. |
| Speed | 2 | Raw ÷ 10 = km/h typical |
| Direction | 2 | Degrees from north, 0 to 359. |
| Time | 6 | BCD, YYMMDDhhmmss, on the device clock. |
| Additional items | variable | Repeats of item ID, length, value. 01 mileage, 02 fuel, 03 recorder speed, 30 signal, 31 satellites, 64 ADAS, 65 DSM. |
How is a GT06 frame built?
GT06 frames are shorter and end with a CRC and two stop bytes.
78 780D01012345678901234500018CDD0D 0A
- Start bits 78 78 and stop bits 0D 0A
- Length and serial number
- Protocol number 01: login
- IMEI as BCD digits
- CRC-16/X25
| Part | Size | What it holds |
|---|---|---|
| Start bits | 2 | 78 78. Long frames use 79 79 and a 2-byte length. |
| Length | 1 | Bytes from the protocol number to the CRC. |
| Protocol number | 1 | 01 login, 12 location, 13 status, 16 alarm, 80 server command. |
| Information | variable | Depends on the protocol number. |
| Serial number | 2 | Counts up. The server repeats it in its reply. |
| CRC | 2 | CRC-16/X25 over the length, protocol number, information and serial number. |
| Stop bits | 2 | 0D 0A. |
In a location packet the position is a raw number divided by 1,800,000 (typical). Bits 0 to 9 of the course and status word are the course, bit 10 set means north, bit 11 set means west, and bit 12 set means the GPS is fixed.
Which checksum or CRC does a device use?
Makers do not always name the variant. The Checksum and CRC tab tries all of these on your bytes and marks the one that matches the value in the frame.
| Algorithm | Bits | Polynomial | Start value | Reflected | Final XOR | Check value |
|---|---|---|---|---|---|---|
| XOR-8 | 8 | - | - | - | - | - |
| SUM-8 | 8 | - | - | - | - | - |
| CRC-8 | 8 | 07 | 00 | no | 00 | F4 |
| CRC-8/MAXIM | 8 | 31 | 00 | yes | 00 | A1 |
| CRC-8/ROHC | 8 | 07 | FF | yes | 00 | D0 |
| CRC-8/EGTS | 8 | 31 | FF | no | 00 | F7 |
| CRC-16/X25 | 16 | 1021 | FFFF | yes | FFFF | 906E |
| CRC-16/IBM | 16 | 8005 | 0000 | yes | 0000 | BB3D |
| CRC-16/MODBUS | 16 | 8005 | FFFF | yes | 0000 | 4B37 |
| CRC-16/CCITT-FALSE | 16 | 1021 | FFFF | no | 0000 | 29B1 |
| CRC-16/KERMIT | 16 | 1021 | 0000 | yes | 0000 | 2189 |
| CRC-16/XMODEM | 16 | 1021 | 0000 | no | 0000 | 31C3 |
| CRC-32 | 32 | 04C11DB7 | FFFFFFFF | yes | FFFFFFFF | CBF43926 |
The check value is the result for the ASCII text 123456789. If your tool gives the same number, it uses the same algorithm. XOR-8 and SUM-8 have no polynomial: XOR combines the bytes with exclusive-or, SUM adds them and keeps the last 8 bits.
Worked example
Two short frames. Paste them into the decoder to follow the steps.
7E 00 02 00 00 00 72 61 01 90 04 03 78 FF 7E
- Message ID 0002 is a heartbeat. The attributes 0000 say the body is empty and not encrypted.
- The phone number is the BCD digits 007261019004 and the serial number is 0378, which is 888.
- XOR of the 12 header bytes is FF, and the frame carries FF. The check passes.
78 78 0D 01 01 23 45 67 89 01 23 45 00 01 8C DD 0D 0A
- The length byte 0D is 13: protocol number, 8 IMEI bytes, serial number and CRC add up to 13.
- Protocol number 01 is a login. The 8 bytes 01 23 45 67 89 01 23 45 are the IMEI with a leading zero: 123456789012345.
- CRC-16/X25 over 0D 01 01 23 45 67 89 01 23 45 00 01 is 8CDD. The packet carries 8CDD, so it passes.
What usually goes wrong?
- Check wrong on every frame. The decoder reads the wrong protocol, or the bytes include a log time stamp or a line prefix. Set the protocol and remove the prefix.
- Check wrong on one frame. A byte changed on the way, or someone edited the frame by hand. Use the corrected frame the decoder shows.
- Frame cut. A capture tool may split a long frame in two. Join the lines before you decode.
- No CRC variant matches. Change the bytes to skip first. Many devices cover only part of the frame. If nothing matches, ask the device maker for the parameters.
- A position is off by a factor of 10. The device uses another scaling. Change the divisor in the Scaling tab.
Assumptions and limits
- Message names, bit tables and scaling follow public protocol documents. They are typical, not a copy of the standard. Check them against the edition your device uses.
- The decoder reads message 0200, 0704, 0100, 0102, 0002, 8001 and 8100 in JT808, and protocol numbers 01, 12 and 13 in GT06. Every other message is listed and checked, and its body is shown raw.
- Vendor extension blocks differ between makers. The tool shows an unknown block as raw bytes and never guesses its meaning.
- A passing check shows that a frame arrived intact. It does not show that the position is accurate or that the device follows a standard.
- The calculations run in your browser. Pasted bytes and inputs are sent to our server, and kept for up to 45 days, only if you ask for the emailed report. A share link you copy yourself also carries the bytes when they are short.
- The decoder does not describe the protocol of a Tracom model. Paste a frame from any device and read it with the published layouts.
Sources
- Public gateway documentation: JT808 message fields
- Open-source JT808 server with links to the specification PDFs
- Ministry of Transport of China: JT/T 808 draft for comment
Last checked 3 November 2026. The 7E flags, the 7D 02 and 7D 01 escaping and the XOR check byte match the official draft above. The CRC check values and the two worked examples were recalculated for this page. The final JT/T 808-2019 text, the message tables and the GT06 layout, which has no official standard, are still to verify against the edition your device uses.