DLT Viewer: reading and filtering automotive diagnostic logs from a desktop
Diagnostic Log and Trace viewing program
At a glance
- What is it?
- DLT Viewer is the COVESA desktop tool for the Diagnostic Log and Trace protocol, a Qt application that reads DLT files, converts them to text or CSV, applies saved filters and can control a running DLT daemon's log levels. It suits an automotive or embedded developer working with log data, and the macOS build is explicitly unofficial.
- Who is it for?
- DLT Viewer is worth installing if you work with DLT logs from an embedded or automotive target, because it handles the file formats that the daemon produces, including the project and filter files that carry your saved configuration, and because the command line mode with the silent and terminate flags makes the conversion step scriptable instead of something you click through a window.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What the tool is for, and the two directions it works in
The Diagnostic Log and Trace Viewer is an application that can send and receive control messages to the DLT daemon, for example to set individual log levels of applications and contexts, or to get the list of applications and contexts registered in the DLT daemon.
That is the interactive half, and it is the part that makes the tool more than a log reader. DLT is a protocol where the daemon on the target holds the logging configuration, so a developer can ask the target to raise or lower the verbosity of a particular application or context at runtime, and can ask it what is registered at all. A viewer that only reads files cannot do that.
The other half is the file side, and it is where most of the work happens. The tool reads DLT log files, and it also imports DLT and IPC data captured from a network, in pcap files, and from measurement files in the MF4 format. It saves its own state as a project file, and it saves filters as filter files, and the command line takes all of those as positional arguments.
The formats are given in the usage text, and knowing them is useful when you script against the tool. A logfile must end with .dlt, a project file with .dlp, a filter file with .dlf, a pcap file with .pcap and an MF4 file with .mf4.
The tool is based on Qt for Windows and Linux, and can run on the Mac though that is not officially supported. The project is COVESA, the same organisation behind the Diagnostic Log and Trace protocol itself, and the topic list names autosar, dlt and genivi, which are the three places the protocol comes from in the automotive world.
The command line, and the silent mode that makes it scriptable
The command line is documented in full, and it is more capable than a viewer that only opens a window would suggest.
The invocation is dlt-viewer with options and up to five positional arguments, and on Windows the executable is dlt-viewer.exe. The options block reads:
-c <textfile> Convert logfile file to <textfile>
-u Conversion will be done in UTF8
instead of ASCII
--csv Conversion will be done in CSV format
-d Conversion will NOT be done, save in
dlt file format again instead
--dd Conversion will NOT be done, save as
decoded messages in dlt format
-b <plugin|command|param1|..|param<n>> Execute a plugin command with <n>
parameters before loading log file.
-e <plugin|command|param1|..|param<n>> Execute a plugin command with <n>
parameters after loading log file.
-s, --silent Enable silent mode without any GUI.
Ideal for commandline usage.
--stream Treat the input logfiles as DLT
stream instead of DLT files.
-t, --terminate Terminate DLT Viewer after command
line execution.The three options that matter for automation are -s, -t and -c. The silent mode enables silent mode without any GUI, ideal for commandline usage. The terminate flag terminates DLT Viewer after command line execution, which is what stops the program from sitting in a window after a conversion. And -c does the conversion itself, with the -u and --csv flags choosing the output encoding and format.
The difference between -d and --dd is a small one that matters in a pipeline. With -d, the conversion is not done and the file is saved in dlt file format again instead, and with --dd it is saved as decoded messages in dlt format. So the tool can rewrite a log file without losing the binary structure, or decode the messages and keep them in the DLT container, and the --delimiter option chooses the character used for CSV export, defaulting to a comma.
The documented examples show the combinations:
dlt-viewer.exe -t -c output.txt input.dlt
dlt-viewer.exe -t -s -u -c output.txt input.dlt
dlt-viewer.exe -t -s -csv -c output.csv input.dlt
dlt-viewer.exe -t -c output.txt input.pcapThe plugin hooks are the other half of the pipeline. The -b option executes a plugin command with parameters before loading the log file and the -e option executes one after loading it, both using the same pipe-separated syntax, and the examples show a non verbose mode plugin taking a fibex path, and a file transfer plugin taking an export directory.
DLT Commander, and when a window is the wrong tool
The repository ships a second executable, dlt-commander, and the difference between the two is the point.
DLT Commander has the same options as the viewer for the things that matter, converting a log file to text or CSV, applying a filter file, decoding into dlt format, running plugins, and importing pcap and MF4 input, and it is a command line program rather than a graphical one. Its usage is dlt-commander with options and the same positional arguments.
Two options are unique to it. The -multifilter option makes the multifilter generate a separate export file with the name of the filter, which is the feature you want when you have a project with a set of saved filters and you want one filtered output per filter rather than one merged output. And the -c flag has a different meaning in the commander, where it will define the folder name, not the filename, so the exported files land in a directory named after the filter.
That combination is what makes the commander the tool for a scripted log analysis job: apply a saved filter, export the result, repeat for each filter, into a predictable directory structure. The documented examples show the pattern, including a filtered export that combines a filter file with a trace file, and a decoded export that runs the non verbose mode plugin before converting.
So the division of labour is sensible. The viewer is for a human looking at a log, with the filter and project files, the live daemon connection and the plugin interface. The commander is for a pipeline, with no window and with the multifilter behaviour that a batch job wants. Having both in one repository, with the same option syntax, means the knowledge transfers.
The build, the platforms and the licence files
The repository is a CMake project with preset configuration, and it carries the scripts for each platform's build.
There is a CMakeLists.txt at the root and a CMakePresets.json beside it, plus a.clang-format for the C++ style, and the source tree is split into the directories you would expect: src/ for the viewer itself, commander/ for the command line program, parser/ for the log file parsing, plugin/ for the plugin system, qdlt/ for the DLT protocol library code, sdk/ for the development kit, filters/ for the shipped filters, doc/ for the documentation, and scripts/, cache/ and noble/ for packaging.
The Windows build is scripted rather than described, with batch files for building the SDK against Qt 6 with Microsoft Visual Studio, one for the ARM variant, one for the interactive variant, and build_config.bat. The Linux packaging is also scripted, with build_viewer_debs.sh and a second script specific to the Ubuntu noble release, which is what produces the Debian packages.
The tested combinations are listed explicitly, which is unusual and useful. The project was developed with Qt 5 and Qt 6, and tested with Windows 11 with Qt 5.15.2 and Microsoft Visual Studio Build Tools 2019, with Windows 11 with Qt 6.7.3 and the same build tools, with Ubuntu Linux 24.04 with Qt 5.15.13, and with macOS Monterey with Qt 6.8.3. The binary is dynamically linked open source software.
The licence situation is the one part that needs reading rather than summarising. The README lists the components and their licences, Qt at LGPLv3, GCC at GPL, optionally Mingw under a mixture of GPL, BSD variant and public domain, and the Open Icon Library under multiple licences, and says that full information is in the LICENSE.txt file. The repository tree also contains an MPL.txt, and the licence recorded in the repository metadata is one that GitHub cannot classify, which is consistent with a file that combines several notices rather than a single standard licence. The development kit and the viewer are separately licensed artefacts, and the SDK is distributed with its own terms.
The releases are 2.31.0 from 2026-09-28, 2.30.0 from 2026-03-24 and 2.29.0-alpha6 from 2025-08-09, and the last push to the repository was on 2026-10-22. The three separate release notes files, ReleaseNotes.txt, ReleaseNotes_Parser.txt and ReleaseNotes_Viewer.txt, tell you that the daemon, the parser and the viewer are versioned and documented independently.
Where DLT Viewer is the wrong tool
The first limit is the platform statement about the Mac. The tool is based on Qt for Windows and Linux, and can run on the Mac though that is not officially supported, and while macOS Monterey with Qt 6.8.3 appears in the tested list, the framing is unambiguous. A team whose developers are all on Macs is picking up an unsupported configuration, and the build scripts in the repository are for Windows and Linux.
The second is that the interactive half only works against a live DLT daemon. Setting log levels of applications and contexts, and listing what is registered, requires a target running the daemon. If you have log files and nothing else, the control messages are unavailable and the tool is a file viewer and converter, which it does very well but which is a smaller thing than the project describes.
The third is that this is a desktop application with a plugin architecture and a C++ and Qt build, and the deployment story for an embedded team is a build of your own. The repository ships batch and shell scripts, and the macOS, Windows and Linux builds each need their own toolchain, which for a team that wants the tool on a build server means maintaining the build rather than downloading a package.
The fourth is the file format dependency. A.dlt log, a.dlp project and a.dlf filter are specific formats, and a team whose log analysis pipeline already works on a different format has to convert. The tool does read pcap and MF4 as input, which widens what it can open, but its own project and filter files remain its own.
And the fifth is the licensing, which is not a defect but a consideration. A viewer that links against Qt under the LGPLv3 has obligations for whoever distributes it, GCC is GPL, the build scripts reference Mingw, and the repository carries both a LICENSE.txt and an MPL.txt with the metadata recording a licence that GitHub cannot classify. For a tool used internally that rarely matters. For a group that intends to ship the viewer or the SDK with a product, it matters a great deal, and the answer is in the files rather than in a single line.
Editorial conclusion
DLT Viewer is worth installing if you work with DLT logs from an embedded or automotive target, because it handles the file formats that the daemon produces, including the project and filter files that carry your saved configuration, and because the command line mode with the silent and terminate flags makes the conversion step scriptable instead of something you click through a window. It is the wrong tool if your logs are not DLT, and it is the wrong tool if you need a live log viewer for a system that does not run the DLT daemon. Before you adopt it, check three things: that your platform is one of the tested combinations, since the project lists Windows 11 with Qt 5.15.2 and Qt 6.7.3 and Microsoft Visual Studio Build Tools 2019, Ubuntu Linux 24.04 with Qt 5.15.13, and macOS Monterey with Qt 6.8.3, while the macOS run is described as not officially supported; that you check the licensing, because the repository carries both LICENSE.txt and an MPL.txt and the licence field is one that GitHub cannot classify; and that you plan for the toolchain, since the build is CMake with preset files and the repository ships batch scripts for building the Windows SDK against Qt 6 and shell scripts for building the Debian packages.
Frequently asked questions
How do I convert a DLT log file to text or CSV from the command line?
Use the silent and terminate options with the conversion option, for example dlt-viewer.exe -t -c output.txt input.dlt for a text conversion, dlt-viewer.exe -t -s -u -c output.txt input.dlt for UTF-8 output, and dlt-viewer.exe -t -s -csv -c output.csv input.dlt for CSV. The -s option enables silent mode without any GUI and the -t option terminates the viewer after the command line execution.
What is the difference between DLT Viewer and DLT Commander?
Both read and convert DLT files and support the same plugin syntax, but the commander is a command line program with two extra options. The -multifilter option generates a separate export file with the name of the filter, and in the commander the -c flag defines the folder name rather than the filename, which is what a batch export of many filters needs.
What file formats can DLT Viewer read and write?
Log files must end with .dlt, project files with .dlp, filter files with .dlf, and it can import DLT and IPC data from .pcap files and from .mf4 measurement files. On the output side it converts to text or CSV, with -u for UTF-8 instead of ASCII and --delimiter to choose the CSV delimiter, and it can write the result back in dlt format with -d or as decoded messages in dlt format with --dd.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/covesa-dlt-viewer)Was this useful?