Just a question about parsing detail

[Haugpro]

thanks for this fine piece of software first. I looked a bit into the parser file and noticed, that you read some parts of a message payload assuming little endian always, especially the 'Type Info' field of an argument. Should that not follow the MSBF bit in HTYP for standard header?

[mbehr1]

thx! Here (in this repo) only the old/deprecated typescript based parser is used. The newer parser is in the https://github.com/mbehr1/adlt repo. There the type_info field is parsed with the endianness of the header:

let type_info = if self.is_big_endian {
                    u32::from_be_bytes(
                        self.msg.payload[self.index..self.index + 4]
                            .try_into()
                            .unwrap(),
                    )
                } else {
                    u32::from_le_bytes(
                        self.msg.payload[self.index..self.index + 4]
                            .try_into()
                            .unwrap(),
                    )
                };

so yes. in the typescript parser here I do use always little-endian.

const typeInfo: number = this._payloadData.readUInt32LE(argOffset)

If you have an example file with big endian I could change the parser here (even though as stated above) the dlt-logs extensions uses now always the adlt based parser/binary.

[Haugpro]

super quick answer, thanks. No, I do not have problems with any DLT file and don't know about one using big endian payload data. I was just curious about the DLT format. I have a lot of years experience in the automotive infotainment area (especially DAB, TV, and all kind of dataservices). In times when there is not much to do I try to understand some tools in depth and maybe find some ways to automate things. So your code did help to understand that rather sophisticated spec (to say it politely). Thanks again

[mbehr1]

welcome! So I can close the issue?

[Haugpro]

oh yes, of course. Thank you