[How to] decoding "Reading" dlt messages received from dlt daemon

[mwaheed-ae]

Hello,
I have a use case , that It is as follows:

I have two separate machines,

1. I need to encode dlt messages at the first machine "ex: guest qemu"
2. I need to decode those received messages back on the second machine.

Steps, I did:

1. In the first machine, I have used dlt lib in my application binary, I have used dlt_log to decode dlt messages with different log levels.

2. On the same machine, I connected my application to dlt daemon.

3. on the same machine, I implemented another binary and connected it through tcp socket to dlt daemon, to receive dlt frames from dlt daemon and save them in log file, and this log file shall be sent to the second machine upon request.
   NOTE: This log file is implemented as ring buffer, so to save the up-to date data.

4. On the second machine, I have an application that can communicate with the first machine and request to get this log file.

The problem faced: I tried to used dlt lib API to decode the messages in file "dlt_file_quick_parsing", or "dlt_file_read", but it fails cause there is no storage header, I used also "dlt_file_read_raw", but the output time stamp is not correct, sounds like there is a problem with timestamp,

My question is: Is there any way to implement such use case, which is:

1. To generate dlt messages on one machine and save it in log file for later.
2. on the other machine, it can be decoded properly with correct timestamp.
   ex: can I have the dlt messages directly from dlt lib without the daemon and save them properly and decode them back with correct time stamp.

[minminlittleshrimp]

Hello @mwaheed-ae ,
thank you for your interest in DLT topic.
Regarding your question, the log generated by your applications using libdlt will be a binary file with format .dlt. You need to read this file using some provided APIs, and for reference you could try dlt-convert.
For the timestamp we actually face some issues of 32 bit counter, this will be solved for a next Major release with autosar timestamp header autosar standard R21-11.
Thanks for your understanding.
Hello @michael-methner @lvklevankhanh @Le-Tin FYI
DLT team