Timestamp is undefined if it contains any START_BYTE
emirkartal0 opened this issue · comments
When reading tlog file, for some packets, timestamp was null. However I was able to parse this tlog file with other tools corretly. Upon further investigation I noticed that in _transform offset was <8 so it is set to null. This happens because on previous iteration, start of packet is detected incorrectly in the middle of the timestamp.
In short: When we have fd or fe in timestamp, it is discarded and as a result we have mavlink packets with timestamp = null altough there is a time stamp in tlog file
It'd be great to have a minimal tlog file that I could use to replicate the issue...
@emirkartal0 One possible solution would be to change lib/mavlink.ts:522 from
if (offset >= 8) {
to
if (offset == 8) {
That way, only timestamps that are directly after the header would be read. But I'll need an example to make sure this fixes it.
I can't send this tlog file (company policy) but i will try to generate a similar tlog file.
Meanwhile fallowing is part of faulty tlog. Hopefully you can simulate from this.
Buffer.from("b3 20 05 f1 fd 7a 1a c9 48 fd 10 20 20 eb 01 01 1e 20 20 20 20 20 20 95 7e 10 3d 0a 92 90 bb 88 f1 09 be d2 49 20 05 f1 fd 7a 1a f8 28 fd
19 20 20 ec 01 01 21 20 20 20 20 20 20 5c 96 f3 17 d2 29 dd 13 36 d8 0f 20 ee ff ff ff 20 20 20 20 03 6e f0 20 05 f1 fd 7a 1b f2 28 fd 1e 20 20 ed 01 01 18
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 58 20 9a 20 20 20 d3 40 05 0b 66 39 ".replaceAll(' ',''),"hex")
I will try to generate tlog file but I am not sure i will be able to. Beacuse the problem happens at spesific times.
This tlog is from a uav with system id 01 and comp id 01. So for example:
20 05 f1 fd 7a 1b f2 28 fd 1e 20 20 ed 01 01 18 ... is start of a mavlink message with timestamp containing fd. So this will not be able to parse.
I'll check it Today.
@emirkartal0 Here's what's going on:
- the protocol you used is Mavlink v2 (hence the 0xFD packet magic byte at offset 0x04)
- since the offset is 4 bytes it is not enough to read a full timestamp, which is 8 bytes
It just looks like broken/incomplete data - all according to what QGroundControl does:
https://dev.qgroundcontrol.com/master/en/file_formats/mavlink.html#c-sketch-for-logging-mavlink :
memcpy(buf, (void*)&time, sizeof(uint64_t));
where sizeof(uint64_t) is 8 bytes, not 4.
I can see now how the 0xFD in the timestamp would be problematic... Let's see if I can do something about it.
b3 20 05 f1 fd 7a 1a c9 48 fd 10 ...
That's a tough one: it starts with one byte of total garbage (b3), then there are 8 bytes. The strategy I have chosen is to find the first packet start that is at least 8 bytes into the stream, when reading TLog files. In version 1.5.0 there's a new splitter class that does that, the MavLinkTLogPacketSplitter.
@emirkartal0 Please check it and see if that fixes it for you. If so, close this issue :)
node-mavlink@1.5.0
Yes, version 1.5.0 is parsing correctly.