we have an issue with some of our trackers.
From time to time we extreme high number of Number of Data 1 & 2 like
00000000000000038ea7a70000a15b despite there being no data present.
Following the decoding from Teltonika AVL Protocols - Wiki Knowledge Base | Teltonika GPS
this would mean the Number of Data (Records) is 167 (a7).
what could be the reason for that?
in addition to that: isnt the Data Field Length wrong here as well? is states it is 3 which but shouldnt it be 2?
Note: this also happens randomly on other devices only where the Data Field Length is 03?
Hello @Aescaru,
Thank you for reaching out! Number of Data 1 & 2 is only composed of 1 Byte Data, so it should not be that long as per your example. The data from these parameters corresponds to the number of records in the packet.
Number of Data 1 – a number which defines how many records is in the packet.
Number of Data 2 – a number which defines how many records is in the packet. This number must be the same as “Number of Data 1”.
In this case, I believe this could be due to how you parse the data. Can you help to specify which Data Protocol (Codec 8 or Codec 8E) you used on the device and share here the Raw Data to further assist you on parsing the data?
Best regards,
Patrick
We ware using Codec8 Extended - so the two byte length seems to be ok. I will come back to you with the raw data logged.
Could this be related to any configuration?
@Patrick_Sangalang see above.
Hello @Aescaru,
I believe this is not related to Configuration of the device, so it would be helpful if you can share the raw data to assist you further on parsing the data of the FMC650.
Kind regards,
Patrick S.
@Patrick_Sangalang
we receive the bytes on our socket and parse it with binascii.hexlify(client_data), where client data is client_data = self.socket.recv(1024).
The 1024 is another issue we had in our script and solved it (related to another error we had where the bytes were more than 1024).
However, this is not what is happening on the issue above.
client_data = self.socket.recv(1024)
logging.info(self.id+"[*] Received Data: " + str(binascii.hexlify(client_data)))
logs Received Data: b’00000000000000038ee7e70000916b’.
the indicated data is still missing or am i overlooking sth here?
Another thing we noticed: every once in a while, but very randomly one device sends the data correctly like
00000000000000038ee7000000e70000916b
but then sends again on subsequent requests without the nulls
This topic was automatically closed after 8 days. New replies are no longer allowed.