GPS Vehicle Tracker Communication Protocol
Table of Contents
Preface. 5
Terminologies. 5
Protocol Overview.. 5
General Constrains. 5
Rules for IP Resolving. 6
Communication Flow.. 6
Packet Format. 6
Header 7
Protocol 7
Length. 7
Sequence. 7
Packet Body. 7
Login Packet (0x01) 8
GPS Packet (0x02) 9
Heartbeat Packet (0x03) 11
Alarm Packet (0x04) 12
ACC Packet (0x05) 13
SMS Uplink Command Packet (0x06) 14
Downlink Command Packet (0x80) 15
Common Downlink Message Packet (0x81) 15
BS Packet (0x91) 16
Extended Heartbeat Packet (0x07) 18
Time Calibration Packet (0x08) 20
Downlink Command List. 20
Preface
This document specifies the protocol used for the communication between vehicle trackers and our vehicle-tracking platform using GPS.
Terminologies
|
Abbreviations |
Terms |
|
CMPP |
China Mobile Peer to Peer |
|
GPS |
Global Positioning System |
|
GSM |
Global System for Mobile Communication |
|
GPRS |
General Packet Radio Service |
|
TCP |
Transport Control Protocol |
|
LBS |
Location Based Services |
|
IMEI |
International Mobile Equipment Identity |
|
MCC |
Mobile Country Code |
|
MNC |
Mobile Network Code |
|
LAC |
Location Area Code |
|
Cell ID |
Cell Tower ID |
|
RSSI |
Received Signal Strength Indicator |
|
UDP |
User Datagram Protocol |
|
SOS |
Save Our Ship/Save Our Souls |
|
CRC |
Cyclic Redundancy Check |
|
NITZ |
Network Identity and Time Zone, |
|
GIS |
Geographic Information System |
Protocol Overview
General Constrains
1. Byte Order
With field values that occupy more than one bytes in the protocol, they should be in network byte order, also known as Big Endian. You may visit the Wikipedia page on Big Endian for more information.
2. Any time value in packet body should be in UTC.
You may visit the Wikipedia page on UTC for more information.
3. The size of a data packet should be less than 1024 bytes.
Rules for IP Resolving
Trackers should implement the mechanism to cache IP for a specified domain, and generally use this cached IP to try to connect to the server without asking DNS server to resolve the domain. If connecting to the server fails for three times using a cached IP, then this is the time when asking DNS server for the new IP of the domain is needed.
The benefits of the IP cache strategy are as follows:
Asking DNS to resolve for a domain is time consuming, and using IP cache is faster.
To reduce the overload of DNS server and avoid domain resolving failures.
To insure connectivity to our platform in case of DNS server downtime.
Notice that there is some consideration about the limit on the number of times trying to connect using a cached IP with failures. Consider that if the sever IP has changed, then the cached IP is outdated, and trying to establish connection with the cached IP will fail. Plus, it takes about 20 to 60 seconds each time to try to establish connection. Therefore, if the times limit is too big, then the total amount of time wasted to establish connection with an outdated IP with failures should be tremendous. Given this consideration, and for the overall outcome of connectivity, we recommend that you set the times limit to be 3, that is, if a tracker tries to connect with a cached IP fails for 3 times, then it should request DNS server to resolve the domain for the correct IP.
Communication Flow
The communication flow between trackers and our vehicle-tracking platform is as follows:
Start a tracker and connect to our vehicle-tracking platform, then send a login packet to login the platform. Trackers should send a login packet as the first one packet after connection.
After login, the tracker may send GPS data to our server regularly if it has new data to transmit.
To ensure connectivity, the tracker should send Heartbeat packets to our server at regular time, and the server will send response packets back to the tracker to confirm connectivity.
If the Protocol Number and Message Sequence Number of a packet sent from a tracker are the same as that of a responded packet from our server respectively, then the two packets are matched.
Packet Format
|
Fields |
Header |
Protocol |
Length |
Sequence |
Body |
|
Bytes |
2 |
1 |
2 |
2 |
N |
The total size of a packet is 7+N bytes.
This format applies to both uplink and downlink packets.
Header
Header field occupies 2 bytes, and its value fixes to 0x67 0x67.
Protocol
Protocol field occupies 1 byte and defines the type of a packet. The table below lists all the protocols with descriptions.
|
Protocols |
Descriptions |
Response Required |
|
0x01 |
Login Packet |
Yes |
|
0x02 |
GPS Packet |
No |
|
0x03 |
Heartbeat Packet |
Yes |
|
0x04 |
Alarm Packet |
Yes |
|
0x05 |
ACC Packet |
Yes |
|
0x06 |
SMS Uplink Command Packet |
Yes |
|
0x80 |
Downlink Command Packet |
Yes |
|
0x81 |
Common Downlink Message Packet |
No |
|
0x91 |
BS Packet |
No |
|
0x07 |
Extended Heartbeat Packet |
Yes |
|
0x08 |
Time Calibration Packet |
Yes |
Length
Length field occupies 2 bytes. The value of Length field is calculated by adding the size of Sequence field and the size of Body field.
Sequence
Sequence field occupies 2 bytes.
After a tracker has been booted, the Sequence value of the first packet sent from the tracker is marked with ‘1’. For subsequent packets, Sequence value should be increased by 1 for each packet. When the value reaches 65535, it should be reset to 1 again.
Packet Body
In the following paragraphs, we will describe each type of packet by their Body fileds in detail.
Login Packet (0x01)
|
Format |
Body |
|
|
Tracker ID |
Language |
|
|
Bytes |
8 |
1 |
Before transmitting other packets, a tracker should send a Login packet to our vehicle platform for the authentication of the connection.
1. Tracker ID (8 bytes)
The value of Tracker ID field is an IMEI (which is a number with 12 or 15 decimal digitals) specified in hexadecimal notation.
e.g.
IMEI: 123456789012345
Tracker ID: 0x01 0x23 0x45 0x67 0x89 0x01 0x23 0x45
2. Language (1 byte)
|
Code |
Language |
|
0x00 |
简体中文 |
|
0x01 |
English |
This field specifies the language of information transmitting between a tracker and the server.
In cases where trackers need the server to response with literal information, then the Language field specifies the language of the information that the server should response.
e.g.
In case of SOS alarm, when the Language filed is specified as Chinese, then the message returned by the server may be:
SOS报警：广东省.深圳市.宝安区留仙一路.G4.离高新奇科技股份有限公司约86米.离高新奇工业区约88米
And when you specify the language to be English, then the message returned by the server may be:
SOS! http://maps.google.com/?q=22.577308,113.916685<DateTime:2013-01-22 19:40:00>
3. Packet Example
The packet a tracker send to the server may be as follows:
|
0x67 0x67 |
0x01 |
0x00 0x0B |
0x00 0x01 |
0x010x23 0x45 0x67 0x89 0x01 0x23 0x45 |
0x00 |
|
Header |
Protocol |
Length |
Sequence |
Tracker ID |
Language |
The decimal result of the value of the Tracker ID field above is 123456789012345.
The packet the server response to the tracker will be as follows:
|
0x67 0x67 |
0x01 |
0x00 0x02 |
0x00 0x01 |
|
Header |
Protocol |
Length |
Sequence |
Notice that the value of the Protocol field of the response packet is the same as that of the first packet sent from the tracker.
GPS Packet (0x02)
|
Format |
Body |
||||||
|
Time |
Latitude |
Longitude |
Speed |
Course |
BS |
Status |
|
|
Bytes |
4 |
4 |
4 |
1 |
2 |
9 |
1 |
1. Time
Time field occupies 4 bytes. The value is in UTC format and round to seconds.
2. Latitude
Latitude field occupies 4 bytes, and represents the latitude of the position of a tracker. Its value ranges from -162000000 to 162000000 in decimal notation; in sexagesimal notation, that is from -90 degrees (southward latitudes) to 90 degrees (northward latitudes). For transmission, the value of Latitude field should be specified in hexadecimal notation, and its unit is 1/500 seconds. The representation in sexagesimal notation using degrees and minutes can be converted to the representation using the unit 1/500 seconds as follows:
Firstly, convert the output latitude (expressed in degrees and minutes) of GPS module to a decimal fraction in unit minutes.
Secondly, multiply the result of the first step and 30000, and then convert the new result to its hexadecimal notation.
e.g.
North latitude 22°32.7658′should be converted to (22×60 + 32.7658)*30000=40582974, then to hexadecimal notation as x02 0x6B 0x3F 0x3E.
South latitude -22°32.7658′should be converted to (-22×60 + ( -32.7658))*30000=-40582974, and then to hexadecimal notation as 0xFD 0x94 0xC0 0xC2.
3. Longitude
Longitude field occupies 4 bytes, and represents the longitude of the position of a tracker. Its value ranges from -324000000 to 324000000 in decimal notation; in sexagesimal notation, that is from -180 degrees (westward longitudes) to 180 degrees (eastward longitudes). For transmission, the value of Longitude field should be specified in hexadecimal notation, and its unit is 1/500 seconds. The representation in sexagesimal notation using degrees and minutes can be converted to the representation using the unit 1/500 seconds. The way of conversion is the same as that of the Latitude field described above.
4. Speed
Speed field occupies 1 byte, and represent the velocity of a tracker measured using GPS. The value range of Speed field is 0x00～0xFF, corresponding to 0～255 miles/hour.
5. Course
Course field occupies 2 bytes, and represent the heading of a tracker measured using GPS. The value of Course field ranges from 0 to 360, and its unit is degree. The value is 0 for true north, and increases clockwise.
6. BS
|
Format |
MCC |
MNC |
LAC |
CI |
|
Bytes |
2 |
2 |
2 |
3 |
The abbreviation BS stands for Base Station, and occupies 9 bytes.
e.g. (One of the base stations in China)
|
0x01 0xCC |
0x00 0x01 |
0x27 0x49 |
0x00 0x0C 0xEE |
|
MCC |
MNC |
LAC |
CI |
7. Status
|
High |
|
|
|
|
|
|
Low |
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Status field occupies 1 byte, and represents the positioning state of a tracker. Notice that 1 byte consists of 8 bits, and we number the lowest bit as position 0, and the highest bit as position 7. At the time of transmission, higher position bits should be sent prior to lower position bits. The specification of each bit is as follows:
|
Position 0 |
0: GPS not positioned 1: GPS positioned |
|
Position 1 |
Reserve |
|
Position 2 |
Reserve |
|
Position 3 |
Reserve |
|
Position 4 |
Reserve |
|
Position 5 |
Reserve |
|
Position 6 |
Reserve |
|
Position 7 |
Reserve |
8. Server Response
The server does not need to response to GPS packets sent from trackers.
9. Note
Trackers generally do not need to send old data to the server if there is no new GPS positioning results, but except for some otherwise purposes, in circumstances such as alarming, etc.
Heartbeat Packet (0x03)
|
Format |
Body |
|
Status |
|
|
Bytes |
2 |
A tracker should send Heartbeat packets at a fixed-frequency to confirm connectivity between the tracker and the server.
1. Status
|
High |
|
|
|
|
|
|
Low |
|
15 |
14 |
… |
… |
… |
… |
1 |
0 |
Status field occupies 2 bytes, and represents the positioning state of a tracker. Notice that 1 byte consists of 8 bits, and we number the lowest bit as position 0, and the highest bit as position 7. As for the second byte, you should continue numbering the lowest bit of this byte as position 8, and so on. At the time of transmission, higher position bits should be sent prior to lower position bits. The specification of each bit is as follows:
|
Position 0 |
0: GPS not positioned 1: GPS positioned |
|
Position 1,2 |
10: ACC off 11: ACC on 00: State undefined |
|
Position 3,4 |
10: Defense unset 11: Defense set up 00: State undefined |
|
Position 5,6 |
10: Oil and electricity off 11: Oil and electricity on 00: State undefined |
|
Position 7,8 |
10: Battery charger unplugged 11: Battery charger plugged 00: State undefined |
|
Position 9 |
Reserve |
|
… |
… |
|
Position 14 |
Reserve |
|
Position 15 |
Reserve |
e.g.
With 0x00BB, that is 1011 1011 in binary notation, the status of the tracker should be “GPS positioned, ACC off, Defense set up, Oil and electricity off and Battery charger unplugged”.
2. Packet Example
The Heartbeat packet sent from a tracker to the server:
|
0x67 0x67 |
0x03 |
0x00 0x04 |
0x00 0x1A |
0x00 0x01 |
|
Header |
Protocol |
Length |
Sequence |
Status |
The response packet by the server:
|
0x67 0x67 |
0x03 |
0x00 0x02 |
0x00 0x1A |
|
Header |
Protocol |
Length |
Sequence |
Notice that the value of the Protocol field of the response packet is the same as that of the Heartbeat packet sent from the tracker.
Alarm Packet (0x04)
|
Format |
Body |
|||||||
|
Time |
Latitude |
Longitude |
Speed |
Course |
BS |
Status |
Alarm Type |
|
|
Bytes |
4 |
4 |
4 |
1 |
2 |
9 |
1 |
1 |
When something triggers some kind of alarm, a tracker sends Alarm packets to the server.
For the specification of Time, Latitude, Longitude, Speed, BS and Status, please refer to GPS Packet section for more information.
1. Alarm Type
|
Value |
Alarm Type |
|
0x01 |
Power off |
|
0x02 |
SOS |
|
0x03 |
Low battery |
|
0x04 |
Vibration |
|
0x05 |
Displacement |
|
0x06 |
Into dead zone |
|
0x07 |
Out of dead zone |
|
0x08 |
GPS antenna open circuit |
|
0x09 |
GPS antenna short circuit |
|
0x0a |
Light sensation |
|
0x0b |
Magnetic sensation |
|
0x0c |
Anti-dismantle |
|
0x0d |
Over speed |
|
0x0e |
Signal shielding |
2. Server Response
|
Format |
Body |
|
Alarm SMS |
|
|
Bytes |
N |
When the server receives an Alarm packet from a tracker, it will then send a response packet with an alarm text back to the tracker; And after receiving the response packet, the tracker may then send a SMS with the alarm text to a phone using the center phone number or SOS number specified in the tracker. Notice that, in some cases the alarm text from the server might be an empty string, where a tracker should have a check and not send the text to the user.
Alarm texts from the server are in UTF-8 Encoding.
e.g.
The alarm text may be “SOS! http://maps.google.com/?q=22.577308,113.916685<DateTime:2013-01-22 19:40:00>”.
ACC Packet (0x05)
|
Format |
Body |
||||||||
|
Time |
Latitude |
Longitude |
Speed |
Course |
BS |
Status |
ACC Type |
ACC Time |
|
|
Bytes |
4 |
4 |
4 |
1 |
2 |
9 |
1 |
1 |
N |
ACC Packet is an extension for GPS Packet, used for collecting the ACC state of a tracker. Whenever ACC state has changed, a tracker should send this packet to the server.
For the specification of Time, Latitude, Longitude, Speed, BS and Status, please refer to GPS Packet section for more information.
1. ACC Type
|
ACC Type |
ACC Time |
Description |
|
0x01 |
From Tracker(4 bytes，UTC, round to seconds) |
ACC on |
|
0x02 |
From Tracker(4 bytes，UTC, round to seconds) |
ACC off |
2. Server Response
|
Format |
Body |
|
(Empty) |
|
|
Bytes |
0 |
3. Note
Tracker side should take the responsibility to synchronize its local time with that from GPS.
SMS Uplink Command Packet (0x06)
|
Format |
Body |
||||||||
|
Time |
Latitude |
Longitude |
Speed |
Course |
BS |
Status |
Phone |
SMS Command |
|
|
Bytes |
4 |
4 |
4 |
1 |
2 |
9 |
1 |
21 |
N |
User may use a mobile phone to send SMS text as a command to a tracker (through the sim card installed in the tracker). After receiving a command from a phone, a tracker may execute it locally or pass it to the server to execute (see the rules below for more detail).
For the specification of Time, Latitude, Longitude, Speed, BS and Status, please refer to GPS Packet section for more information.
1. Phone
The value of Phone field is in ASCII encoding, and represents the number of a phone that sends a SMS text command to a tracker. If the length of a phone number expressed in hexadecimal notation is less than 21 bytes, then add copies of 0x00 to the right of the value to fulfill the length criteria.
2. SMS Command
SMS Command text is in UTF-8 encoding, it may be processed on the tracker side or on the server.
Rules that decide where to execute a command:
Command text that is in the command list defined in a tracker, such as “STATUS#”, will run on the tracker side.
Command text that does not include Chinese characters, and with a length bigger than 2 chars and less than 30 chars, should be passed to the server to process. Such as “position#” or “123” (User may send one of these two texts to get the location of a tracker).
3. Server Response
|
Format |
Body |
|
|
Phone |
Response |
|
|
Bytes |
21 |
N |
Response text from the server is in UTF-8 encoding. After receiving the response packet from the server, a tracker may pass the response text to the user by the phone number in that packet. If the response text is empty (0 bytes), a tracker may not need to pass anything to the phone specified.
Downlink Command Packet (0x80)
|
Format |
Body |
||
|
Flag |
Server Flag |
Content |
|
|
Bytes |
1 |
4 |
N |
Users may login our web site (www.cootrack.net) and use command-sending features on the site to control their trackers.
1. Flag
|
Flag |
Description |
|
0x01 |
Command |
|
0x02 |
Reserve |
2. Server Flag
Tracker side does need to process this field, but put it right in the response packet to send back to the server.
3. Content
The command text to send to a tracker, using UTF-8 encoding. See Downlink Command List section for the definition of each command.
4. Tracker Response
|
Format |
Body |
||
|
Flag |
Server Flag |
Response |
|
|
Bytes |
1 |
4 |
N |
Response text from tracker side to the server is in UTF-8 encoding.
Common Downlink Message Packet (0x81)
|
Format |
Body |
|
|
Flag |
Content |
|
|
Bytes |
1 |
N |
Users may login our web site (www.cootrack.net) and use corresponding features on the site to tell the server to send text to a tracker. The tracker may then display the text on a screen or pass it to a mobile phone according to the type flag in the packet.
5. Flag
|
Flag |
Type |
Description |
|
0x01 |
Relay |
Pass the text to a mobile phone |
Relay (0x01)
|
Format |
Phone |
Text |
|
Bytes |
21 |
N |
Note: If the value of Phone field is 21 copies of 0x00, that means the tracker should pass the text to a phone by the Center Number or SOS number specified in the tracker.
BS Packet (0x91)
|
Format |
Body |
||||||||||
|
Time |
TA |
MCC |
MNC |
BS Count |
BS 1 |
BS 2 |
BS 3 |
BS 4 |
BS 5 |
Status |
|
|
Bytes |
4 |
1 |
2 |
1 |
1 |
6 |
6 |
6 |
6 |
6 |
1 |
1. Time
Time field occupies 4 bytes. The value is in UTC format and round to seconds. Noticed that it should be transmitted in big-endian order (also referred to as network byte order).
2. TA (Timing Advance)
The TA value is normally between 0 and 63. TA values can only be captured during phone call or SMS sending phases, otherwise you may get a TA value of 255, and that is an invalid value. Multiply the TA value and 550 meters to get the distance between a tracker and a primary cell. You may refer to the Wikipedia page on Timing Advance for more information.
3. MCC
A mobile country code (MCC) is used in combination with a mobile network code (MNC) (also known as a "MCC / MNC tuple") to uniquely identify a mobile network operator (carrier). The value of MCC is between 0x0000 and 0x03E7 expressed in hexadecimal notation. You may refer to the Wikipedia page on MCC and MNC for more information.
4. MNC
Please refer to the Wikipedia page on MCC and MNC for more information.
5. BS Count
BS Count represents the number of base stations, of which the location data is included in the packet. So for example, if the BS Count value is 3, then there should be exactly 3 BS data fields following the BS Count field. The max value of this field is 5, and if a tracker can get location data from more than 5 base stations, it should report only the data from the 5 base stations which have stronger signals. The order of base stations in the packet depends on their signal strengths; that is the station with the strongest signal comes first during transmission.
Notice that the number of the following BS fields should be the same as the value specified in the BS Count filed. Therefore, if the BS Count value is 5, and you have got data from only 3 base stations, then you should fill the last 2 BS fields with value 0 specifically.
6. BS
|
LAC |
CI |
RSSI |
|
2 |
3 |
1 |
The BS field consists of LAC, CI and RSSI.
LAC is the abbreviation of Location Area Code. The value of LAC occupies 2 bytes and is in hexadecimal notation, ranges from 0x0001 to 0xFFFE (notice that 0x0000 and 0xFFFF are not included). A location area may contain one or more cells.
CI is the abbreviation of Cell ID, and represents the ID of a primary cell tower available. The value of CI ranges from 0x000000 to 0xFFFFFF.
RSSI is the abbreviation of Received Signal Strength Indicator, and represents the signal strength of the primary cell. The value of RSSI ranges from 0x00 to 0xFF. The sign of original value is negative, but the data sent should be an absolute value.
7. Status
|
High |
|
|
|
|
|
|
Low |
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Status field occupies 1 byte, and represents the positioning state of a tracker. Notice that 1 byte consists of 8 bits, and we number the lowest bit as position 0, and the highest bit as position 7. At the time of transmission, higher position bits should be sent prior to lower position bits. The specification of each bit is as follows:
|
Position 0 |
0: GPS not positioned 1: GPS positioned |
|
Position 1 |
0: Automatic Packet 1: Triggered by SMS |
|
Position 2 |
Reserve |
|
Position 3 |
Reserve |
|
Position 4 |
Reserve |
|
Position 5 |
Reserve |
|
Position 6 |
Reserve |
|
Position 7 |
Reserve |
8. Server Response
The server does not need to response to BS packets.
9. Note
Base station positioning is far less accurate than GPS positioning, so it is a consideration only when GPS positioning is not available.
Because of the rough precision of 100 meters to 10,000 meters of base station positioning, when a tracker receives a SMS request for positioning, it should try to collect Timing Advance data to assist the positioning, plus, the value of position 1 of the Status field should be 1 for SMS triggered positioning.
Moreover, because of the rough precision, trackers do not need to send base station positioning data every 10 seconds. The sending condition may be this: it is beyond 20 seconds since the last sending, and the positioning data of the three stations which have stronger signals has changed.
Extended Heartbeat Packet (0x07)
|
Format |
Body |
||
|
Status |
GSM Signal Level |
Quantity of Electricity |
|
|
Bytes |
2 |
1 |
1 |
5.3
5.4
5.5
5.6
5.7
5.8
5.9
Trackers send Heartbeat packets at a fixed-frequency to confirm the connectivity between tracker side and the server.
1. Status
|
High |
|
|
|
|
|
|
Low |
|
15 |
14 |
… |
… |
… |
… |
1 |
0 |
Status field occupies 2 bytes, and represents the positioning state of a tracker. Notice that 1 byte consists of 8 bits, and we number the lowest bit as position 0, and the highest bit as position 7. As for the second byte, you should continue numbering the lowest bit of this byte as position 8, and so on. At the time of transmission, higher position bits should be sent prior to lower position bits. The specification of each bit is as follows:
|
Position 0 |
0: GPS not positioned 1: GPS positioned |
|
Position 1,2 |
10: ACC off 11: ACC on 00: State undefined |
|
Position 3,4 |
10: Defense unset 11: Defense set up 00: State undefined |
|
Position 5,6 |
10: Oil and electricity off 11: Oil and electricity on 00: State undefined |
|
Position 7,8 |
10: Battery charger unplugged 11: Battery charger plugged 00: State undefined |
|
Position 9 |
Reserve |
|
… |
… |
|
Position 14 |
Reserve |
|
Position 15 |
Reserve |
e.g.
With 0x00BB, that is 1011 1011 in binary notation, the status of the tracker should be “GPS positioned, ACC off, Defense set up, Oil and electricity off and Battery charger unplugged”.
2. GSM Signal Level
The field GSM Signal Level occupies 1 byte. There are 5 signal levels:
|
Value |
Description |
|
0x00 |
No signal |
|
0x01 |
Extremely week |
|
0x02 |
A little week |
|
0x03 |
Good |
|
0x04 |
Strong |
3. Quantity of Electricity
The field Quantity of Electricity occupies 1 byte. The value of this field is a percentage number, expressed in hexadecimal notation, and ranges from 0x0000 to 0x0064.
e.g.
With 0x005D, that is 93 in decimal notation, so the quantity of electricity of the tracker is 93%.
4. Packet Example
A packet sent from tracker side to the sever may be as follows:
|
0x67 0x67 |
0x03 |
0x00 0x04 |
0x00 0x1A |
0x00 0x01 |
|
Header |
Protocol |
Length |
Sequence |
Status |
The packet responded from the server to the tracker may be as follows:
|
0x67 0x67 |
0x03 |
0x00 0x02 |
0x00 0x1A |
|
Header |
Protocol |
Length |
Sequence |
Notice that the Sequence value of the response packet is the same as that of the packet sent from the tracker.
Time Calibration Packet (0x08)
There is no Body field in Time Calibration packets sent from trackers.
1. Server Response
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
|
Format |
Body |
|
UTC |
|
|
Bytes |
4 |
The UTC value in the Body field of the response packet occupies 4 bytes, and is the time from GPS data.
2. Packet Example
A Time Calibration packet sent from a tracker to the server may be as follows:
|
0x67 0x67 |
0x08 |
0x00 0x02 |
0x00 0x1A |
|
Header |
Protocol |
Length |
Sequence |
The response packet from the server for the Time Calibration packet may be as follows
|
0x67 0x67 |
0x08 |
0x00 0x06 |
0x00 0x1A |
0x57 0x30 0x06 0x90 |
|
Header |
Protocol |
Length |
Sequence |
UTC Time |
Notice that the Sequence value of the response packet is the same as that of the packet sent from the tracker.