Parsing Issue H02 protocol
The issue is likely with the previous message. You found the correct thread. The message length is only relevant for the binary messages. Are they different as well? Please provide samples, if that's the case.
Thanks for the reply. I can give you some sample messages. They're all from the same device, I cleared the uniqueId.
Length 68
2020-10-14 07:43:19 INFO: [3c0a5b1e: h02 < 0.0.0.0] HEX: 24XXXXXXXXXX074315141020522476014c012332856c000000ffff7bff100205c80e14ba3ed52dca0e14ba3ed52df0b0142447221f8625190c53fd1df2b0142447221a76
2020-10-14 07:43:29 INFO: [3c0a5b1e: h02 < 0.0.0.0] HEX: 24XXXXXXXXXX074325141020522476014c012332856c000000ffff7bff100205c80e14ba3ed537ca0e14ba3ed5368625190c53fd2cf2b01424472223f0b0142447222277
Length 61
2020-10-14 10:47:28 INFO: [e8b03e9c: h02 < 0.0.0.0] HEX: 24XXXXXXXXXX1047251410205224747847012332865c000000ffff7bff100204c80e14ba3ed539ca0e14ba3ed5398625190c53fd2dd0ff986c87a01ca9
Length 54
2020-10-14 06:18:30 INFO: [5128f5b4: h02 < 0.0.0.0] HEX: 2400000000000618211410205224760150012332856c000000ffff7bff0e0203c80e14ba3ed52cca0e14ba3ed52c8625190c53fd1d5d
Length 48
2020-10-14 07:47:25 INFO: [e260fa11: h02 < 0.0.0.0] HEX: 24XXXXXXXXXX0747231410205224760148012332856c000000ffff7bff0e01020106013702c8940d0106013702c892057e
2020-10-14 07:47:35 INFO: [e260fa11: h02 < 0.0.0.0] HEX: 24XXXXXXXXXX0747321410205224760148012332856c000000ffff7bff0e01020106013702c8940d0106013702c892067f
Length 37
2020-10-14 07:47:55 INFO: [97a713ec: h02 < 0.0.0.0] HEX: 24XXXXXXXXXX0747531410205224760148012332856e000217ffff7bff0e000d00f0005f81
2020-10-14 07:48:05 INFO: [97a713ec: h02 < 0.0.0.0] HEX: 24XXXXXXXXXX0748031410205224760148012332856e000110ffff7bff0e000e00f0003b82
2020-10-14 07:48:15 INFO: [97a713ec: h02 < 0.0.0.0] HEX: 24XXXXXXXXXX0748131410205224739548012332996e000091ffff7bff0e000d00f0001d83
Unfortunatelly, I haven't any documentation for the binary protocol. The only document I got from the vendor, only describes messages with length of 45 Byte, which is obviously not correct.
https://drive.google.com/file/d/1BRTzHDGJtNtYCtBGKI3910Xm6NvV3G3F/view?usp=sharing
I compared it to the h02 documents on traccar and it seems to be the same until "longtitude." In traccar you're reading a byte with flags, but in my case there should be 3 bytes with "speed, direction". After that there is the vehicle status (ffff7bff) with 4 bytes. That means the messages are consistent until byte 29.
Then there're blocks with different length:
message length - block length
37 - 7
48 - 19
54 - 24
61 - 31
68 - 38
The last byte looks like the record number, which is increased at every sent message.
I can't tell which information are in these blocks. In our case, they're probably not important. Can you tell me where I can implement something to discard the bytes after the device status? Would it be the FrameDecoder? Or maybe you have a better solution to this.
Hope this helps.
The problem is that we need to detect frames. How do you know where one message starts and ends?
I have a solution for frame detection. I got the correct protocol document from our vendor. I implemented the FrameDecoder on our side and it worked very well. I don't know if it's generally applicable for the H02 protocol, but I created a pull request for it. I included the protocol document there. Maybe it helps.
Hi,
I encountered a problem with H02 protocol if I send a command to my device. I sent positionPeriodic command, which worked fine, but the answer from the device is broken in the H02ProtocolDecoder.java. I think it has something to do with the periodic received positions and the received answer to the command.
I logged the following:
The command was sent 07:52:44, 1 second later I received the answer from the device which I can decode to:
At this point the message is correct and "D1, 60" is the expected result of the device.
But inside the H02ProtocolDecoder.decode(...) the message is corrupted. I logged the content of the buffer and it seems, that the first part is still content from the message at 07:52:39 and in the second part I can see the beginning of my result message. Obviously, it's not decoded properly and I miss the answer from my device.
Is there anything I can do to fix this problem? It's very important, that I receive the answer from the commands I send.
I already tried this solution, but couldn't fix the issue:
https://www.traccar.org/forums/topic/traccar-3-7-odd-position-issue/page/2/#post-8339
I set the message length to 68, because most of the messages are that long. But I also got messages with length 54, 48 and 37, maybe this messes up somthing.
Kind regards,
Christian