#1 Add support for the TK106


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.

Added functions:
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 )


Current cons:

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.
Conversion Process:
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.


  • Nobody/Anonymous

    I would like to show some thanks to you just for rescuing me from this type of scenario. Just after checking through the internet and coming across ways which were not productive, I was thinking my life was well over. Living without the presence of approaches to the difficulties you've solved by way of your good short article is a serious case, as well as the ones which could have in a negative way damaged my entire career if I hadn't noticed your web site. Your personal competence and kindness in dealing with all the details was important. I'm not sure what I would've done if I hadn't come across such a step like this. I can at this point look ahead to my future. Thanks so much for the high quality and effective guide. I will not hesitate to refer your web blog to anybody who should receive guidelines on this topic.
    home for Replica Hermes http://discountabouthermesbagsonhermesbags.yolasite.com/

  • Nobody/Anonymous

    Thank you for the good writeup. It in fact was a amusement account it. Look advanced to more added agreeable from you! However, how could we communicate?
    wow gold http://www.wowgolds.ca

  • Nobody/Anonymous

    This would be the proper weblog for anybody who wishes to discover this subject. You realize a great deal of its almost tough to argue along with you (not too When i would wantHaHa). You really put a brand new spin utilizing a subject thats been written about for decades. Great stuff, just wonderful!
    replica lv https://skydrive.live.com/redir?resid=62ECC669FE3F951!118&authkey=!AH0Aw-60qHL_hFo

  • Nobody/Anonymous

    oi0peb <a href="http://tosavfwavmul.com/">tosavfwavmul</a>, [url=http://qfcodtwgmfun.com/]qfcodtwgmfun[/url], [link=http://lcruxddbjzrh.com/]lcruxddbjzrh[/link], http://rlbhokmspute.com/

  • Nobody/Anonymous

    Baidu world's largest Chinese search engine dedicated to Internet users more convenient access to information, find the demand.Baidu over billions of Chinese web database, you can instantly find relevant search results Bai du http://www.baidu.com


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks