TKStar devices protocol
There won't be a better one. If it works (even partially) with one port, it means that's the correct port.
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?
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/
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!
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.0Is there anything else I can try for this or other filters I could perhaps apply to ignore the line that causes the jump? Thankyou
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?
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.
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.
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.
We are experiencing this as well with several TK905 4G devices.
Hi everybody, I know that this post was updated a year ago, but Im having the same problem with tk905 4G:
24590510615119080422032323282103050464009152000040ff7ffbffff00310c0000000000000000000000640005#the lat is correct, but long is not. Anyone has a solution for that?
thank you so much
Is it outdated or simply invalid longitude? If invalid, it would probably indicate a device malfunction.
the longitude is valid, but its jumping to the ocean, like the other guy that opened this post.
but the latitude come correct.
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!