Traccar (3.7) odd position/time issue

Looks like it had always such length. I do not know how to decode this extra part. It is continuously increasing (time, odometer or something else) and finally started give 0x24 that confused frame decoder.
Just a coincidence.

I agree that there is some problem with frame length, and possibly with decoding of binary messages. Unfortunately I have only Chinese documentation, so I can't really understand how to decode it properly. Does anyone have English documentation for this protocol?

I have found some limited English documents:

https://www.traccar.org/protocols/

I was right, extra part contains Mileage Unit: Kilometer
Anton, I can write a fix or you will?

I don't know how to fix it yet. Send me a pull request if you have a solution.

I have asked lkgps to send me the full protocol docs, we will see if they answer.

You are right there is no 100% way to determine which packet used. Length is not reliable.

Here is the complete HEX log of I trip I just made:

2016-09-13 11:30:45 DEBUG: [4EB878C5: 5013 < 213.137.13.4] HEX: 2a48512c343230393931373438342c4e42522c3039333034332c3230362c31302c302c312c31363330302c363238302c35382c3133303931362c46464646464246462c3523
2016-09-13 11:30:45 DEBUG: [4EB878C5: 5013 < 213.137.13.4] HEX: 2a48512c343230393931373438342c5631392c3039333034332c562c353035322e393734392c4e2c30303432362e343332322c452c3030302e30302c3030302c3133303931362c2c303033323437353837343134312c38393434353338353330303030353433373030462c464646464642464623
2016-09-13 11:30:47 DEBUG: [4EB878C5: 5013 < 213.137.13.4] HEX: 2a48512c343230393931373438342c4e42522c3039333034352c3230362c31302c302c312c31363330302c363238302c36322c3133303931362c46464646464246462c3523
2016-09-13 11:30:59 DEBUG: [4EB878C5: 5013 < 213.137.13.4] HEX: 2442099174840930551309165052974005004264320c000000fffffbffff001f00000008c100ce0a000000008c
2016-09-13 11:31:10 DEBUG: [4EB878C5: 5013 < 213.137.13.4] HEX: 2a48512c343230393931373438342c4e42522c3039333130382c3230362c31302c302c372c31363330302c363238302c35322c31363330302c32343839332c34312c31363330302c383435332c33362c31373130302c33343131312c33322c31373130302c33323833312c33312c31363330302c383435342c32372c31363330302c32313330392c32352c3133303931362c46464646464246462c3523
2016-09-13 11:31:21 DEBUG: [4EB878C5: 5013 < 213.137.13.4] HEX: 2442099174840931171309165052974005004264320c000000fffffbffff001f00000008c100ce0a000000008d
...
2016-09-13 11:55:54 DEBUG: [9AA7F0DC: 5013 < 213.137.13.4] HEX: 2442099174840955531309165040934005004232890e000000fffffbffff001808000008db00ce01000000000e
2016-09-13 11:55:56 DEBUG: [9AA7F0DC: 5013 < 213.137.13.4] HEX: 2a48512c343230393931373438342c56312c3039353535332c412c353034302e393334392c4e2c30303432332e323839302c452c3030302e31302c3030302c3133303931362c46464646464246462c3230362c30312c302c302c3523
2016-09-13 11:56:04 DEBUG: [9AA7F0DC: 5013 < 213.137.13.4] HEX: 2442099174840956031309165040934005004232890e000000fffffbffff001808000008db00ce01000000000f
2016-09-13 11:56:15 DEBUG: [9AA7F0DC: 5013 < 213.137.13.4] HEX: 2442099174840956131309165040934005004232890e000000fffffbffff001809000008db00ce010000000010
2016-09-13 11:56:24 DEBUG: [9AA7F0DC: 5013 < 213.137.13.4] HEX: 2442099174840956231309165040934005004232890e000000fffffbffff001809000008db00ce010000000011
2016-09-13 11:56:34 DEBUG: [9AA7F0DC: 5013 < 213.137.13.4] HEX: 2442099174840956331309165040934005004232890e000000fffffbffff001807000008db00ce010000000012
2016-09-13 11:56:44 DEBUG: [9AA7F0DC: 5013 < 213.137.13.4] HEX: 2442099174840956431309165040934005004232890e000000fffffbffff001807000008db00ce010000000013
2016-09-13 11:56:54 DEBUG: [9AA7F0DC: 5013 < 213.137.13.4] HEX: 2442099174840956531309165040934005004232890e000000fffffbffff001709000008db00ce010000000014

I think we have enough logs for now. The problem is pretty clear. There are at least 2 versions of H02 protocol, and each version has different message length. Now the problem is that there is no indication of protocol version or message length in the messages, so it's impossible to decode messages correctly without some extra information.

Maybe by adding a new protocol h02_v2?

Only suggestion is 0x10 byte
In base protocol it is marked as 0x00 Reserved
In extended as battery level 06=100% 05=80% 04=60% 03=40% 02=20% 01=10%

But I'm not sure that it can't be 0x00 in extended protocol.

Now I remember I changed something recently on the trackers. I enabled LBS tracking, which, if I understand well is indicated by NBR in the 3rd field. Could it be that?

renaud, yes it can. Extra part contains LBS.

I have implemented a workaround for now. Basically you need to specify message length in the config file like this:

<entry key='h02.messageLength'>45</entry>

New build:

https://www.dropbox.com/s/cgmlansv32j3ii0/tracker-server.jar?dl=0

I am under the impression there will be more problems with this protocol. The new h02 device like the lk209C-3G have by default LBS and WiFi positioning so this might again add another layer of information. The old ones could already have WiFi positioning but it was far from the most commonly sold.