TKStar devices protocol

A Ra year ago

Hi, is there a suitable protocol for TKStar devices available? It seems very similar to h02 and updates properly when moving, but then seems to drop to a short form of message when idle which results in jumping to the ocean.

Protocol description is here: https://www.tk-star.com/?m=common&a=down&id=14 if there is a better one to use than h02.

Thankyou!

Anton Tananaeva year ago

There won't be a better one. If it works (even partially) with one port, it means that's the correct port.

A Ra year ago

Thankyou for the fast response Anton, I found mention of this same/similar issue in a previous thread re detection and handling of the short frames sent by this series of devices being interpreted as position data here: https://www.traccar.org/forums/topic/parsing-issue-h02-protocol/

Do you know if a resolution was ever found and integrated that I can make use of somehow?

Anton Tananaeva year ago

There is a solution. You have to configure frame length in the config file. More info here:

https://www.traccar.org/forums/topic/traccar-3-7-odd-position-issue/

A Ra year ago

Thankyou Anton! I have applied the <entry key='h02.messageLength'>45</entry> line to my config and so far looks good for one of the impacted devices, I will try others and report back. Your assistance is greatly appreciated!

A Ra year ago

Unfortunately this does not seem to have resolved the issue for the TK905 4G after all, I see the following in my logs with several correct reports of location followed by it jumping to the ocean when the last entry is received as the device goes into standby mode:

2021-11-10 03:15:08  INFO: [18d6be5a: h02 < 195.226.133.55] HEX: 2459051018930314371011213757325002145037076a000344ff7ffbffff00085b0000000001f90300000000640003
2021-11-10 03:15:08  INFO: [18d6be5a] id: 5905101893, time: 2021-11-10 03:14:37, lat: -37.95542, lon: 145.06179, course: 344.0
2021-11-10 03:15:39  INFO: [18d6be5a: h02 < 195.226.133.55] HEX: 2459051018930315371011213757329002145037083a000340ff7ffbffff00085b0000000001f90300000000640004
2021-11-10 03:15:39  INFO: [18d6be5a] id: 5905101893, time: 2021-11-10 03:15:37, lat: -37.95548, lon: 145.06181, course: 340.0
2021-11-10 03:16:36  INFO: [18d6be5a: h02 < 195.226.133.55] HEX: 2a48512c353930353130313839332c5631392c3033313633362c412c333735372e333239352c532c313435332e373039392c452c3030302e30302c3134312c3130313132312c2c2c3
8393434353032393031323131363039373333662c464637464642464623
2021-11-10 03:16:36  INFO: [18d6be5a] id: 5905101893, time: 2021-11-10 03:16:36, lat: -37.95549, lon: 14.89517, course: 141.0

Is there anything else I can try for this or other filters I could perhaps apply to ignore the line that causes the jump? Thankyou

Anton Tananaeva year ago

Where did you get the length from? Hopefully you got the actual length from your logs.

Also, I'm not sure that's actually the problem. Latitude seems to be correct and the issue is only with longitude. Is that correct?

A Ra year ago

I just copied the length from the previous thread I must admit, is it the length of the hex in the log or the decoded string length I need to find?

Yes the latitude seems correct but not the longitude.

A Ra year ago

When the devices are awake and on the move they report location accurately, I think it is as they go to standby they send a shorter string which causes the longitude to be misinterpreted.

Anton Tananaeva year ago

Do you have protocol documentation? I would recommend you to check those short HEX messages against documentation manually and see if it's a device issue or not.

Mikael6 months ago

We are experiencing this as well with several TK905 4G devices.