NOTE: Java is not my primary language, so the following code may disgust people (in the same way java itself disgusts me).
After a few hours of reverse engineering the data packet on my newly purchased TK106 and a few more hours wrapping my head around java strict type casting and comparisons, I managed to hack out working usable code for the built-in tk10x server to parse and insert location data into the opengts database.
Attached is the TrackClientPacketHandler java source file.
parseInsertRecord_TK106 // the actual function
_getUTCSeconds_YMDhms_HMS // date mangling
Complete with bonus bits such as ignition state ( if wired correctly ) and current power status ( currently not used )
1: Device will occasionally loose gps coordinates and heading, but will transmit packet with the relevant bits zeroed out anyway, if it is the scheduled time.
Also happens on boot up if cellular network is acquired before gps.
2: Device transmits velocity in KPH, and I'm assuming im inserting them as KPH.
If the user interface is set to MPH, the actual KPH values are displayed.
If the user interface is set to KPH, the values are multiplied via ~1.6 to 'convert' them to KPH
eg, (database) "127.8" == (ui) "127.8 mph"
(database) "127.8" == (ui) "205.6 kph"
The TK106 transmits 2 types of packets, a standard 94 byte packet, and a shorter 81 byte packet.
The current incarnation of the code disregards the 81 byte packet, as it is only sent when invalid gps data is determined,
or optional panic button on the device is pressed.
The standard 94 byte packet is as follows:
It consists of 13 non delineated fixed length fields
(0 13666666666 BP050000 13666666666 110925 A 1234.5678N 01234.5678W 000.0 020334 90.000 00000000 L000024DE
(0 2 bits - Field 1 is best I can tell an identifier for the protocol
13666666666 11 bits - Field 2 is the device's programmable ID. Used in placed of the IMEI number
BP050000 8 bits - Field 3 is the only unknown in the protocol as it only changes in the shorter packets (only other data seen is "BO012" )
13666666666 11 bits - Field 4 is a repeat of the devices id. Reason unknown.
110925 6 bits - Field 5 is the date taken from the cellular network in YMD format
A 1 bit - Field 6 is a marker for valid GPS data. I'm assuming A for 'accurate'.
Only other possible option is "V" (assuming 'variable') (packets marked variable are currently discarded)
1234.5678N 10 bits - Field 7 is the Latitude coordinates
01234.5678W 10 bits - Field 8 is the Longitude coordinates
000.0 5 bits - Field 9 is the current speed in KPH
020334 6 bits - Field 10 is the current time in GMT (presumably accurate if the correct time zone information is programmed into the device)
90.000 6 bits - Field 11 is the current cardinal heading in degrees
00000000 8 bits - Field 12 is the device status
- Bit 1 is the devices power status: 0 if on external power; 1 if on internal battery
- Bit 2 is the current ACC / Ignition status (if wired correctly): 0 for ignition off; 1 for ignition on
- Bits 3-8 are unknown as I was unable to trigger any of them to flip via any command given to the device (cut power, cut oil, etc.)
L000024DE 9 bits - Field 13 is the devices calculated odometer since power on in hexadecimal, excluding leading bit.
Hex to decimal: 000024DE == 9438
Divide by 100 : 9438 == 94.38
Odometer reads: 94.38 KM
The device claims to support a 'clear milage' command, but response with 'invalid command' on transmission.
Example of the shorter packet (fields expanded):
(0 13666666666 BO012 110925 A 1234.5678N 01234.5678W 000.0 025948 118.72 00000000 L000024DE
This packet type is currently discarded.