FEATURE: Make DBC decoding more seamless in GUI

[MatinF]

Feature summary

We suggest changing the DBC decoding functionality of the asammdf GUI to make it more seamless by e.g. avoiding the creation of a new separate file. We believe the below changes could elevate the UX and DBC functionality of asammdf to the next level.

---

Context/pain point

Today, the asammdf GUI enables decoding of raw 'bus logging' MDF files via the Bus Logging tab. The user loads a DBC file in this tab and clicks "Extract Bus signals" to create a new MDF file with the corresponding decoded data.

While this works as intended, it has some downsides:

1. For every new log file loaded, the user needs to go through all the DBC decoding steps
2. To decode a log file, the user has to 'create' a new MF4 (with the DBC decoded data)
3. There is no support for "remembering" loaded DBC files across sessions
4. The above steps become increasingly cumbersome if users want to analyze many individual log files

---

Possible solution

We suggest making the following changes:

First, integrate the DBC decoding of log files to avoid creating new separate DBC decoded files. Second, elevate the DBC decoding to go across log files.

Step 1: Enable DBC decoding without new log file creation

• The 'Bus Logging' tab is updated to exclude the "Extract Bus Logging" button
• Further, the "export" options are removed from the tab
• Each of the other tabs (Channels/Export/Info) get a new DBC decode checkbox field (positioned as in below image)
• By default, the new DBC decode field is disabled and greyed out (if a raw bus logging MDF is loaded)
• When the user loads his DBC file(s), the field can be enabled
• Toggling the field in one tab also toggles it in the others (across Channels/Export/Info)
• When the field is enabled, the tab interpretation changes from 'raw' to 'DBC decoded' mode
• In the Channels tab, this means that the user can now directly see the ID/signal channel structure and create plots
• In the Export tab, enabling the DBC decoding means the user can now export e.g. a DBC decoded MDF, CSV, ... file
• In the Info tab, enabling DBC decoding means the meta info is shown for the decoded version of the MDF
• Under the hood, the above might be achieved by creating a hidden 'temporary' DBC decoded MDF file on disk
• When a 'raw bus logging' file is closed in the GUI by the user, the corresponding DBC decoded temp copy is deleted
• If a user loads an already DBC decoded MDF, the DBC decode field is enabled and greyed out

The above would allow end users to create plots quickly and avoid juggling "two files" for every 1 log file they wish to analyze. It would also simplify the general work flow as tabs like the Export tab can seamlessly be used across the two "forms" of the same log file.

Step 2: Move DBC decoding to a cross-file layer

• Remove the Bus Logging tab from the file-specific menu
• Add a new menu option: File/Load DBC file(s)
• Clicking this option opens a 'DBC manager' floating menu
• The DBC manager has similar fields as the current Bus Logging tab (excl. the export options)
• In addition, each loaded DBC will have an extra drop down that by default says "Any MDF file"
• This dropdown controls if the DBC will be applied to any opened MDF file - or a specific one (from a list of the open files)
• Toggling the DBC decode field will now "sync" this across open files (in addition to across the Channels/Export/Info tabs)
• The 'DBC manager' and DBC decode settings selected by the user would ideally persist between GUI sessions

The result of the above would have some similarities to the 'DBC decoding' in another tool, SavvyCAN: https://canlogger1000.csselectronics.com/img/DBC-decode-CAN-bus-data-SavvyCAN.mp4

For the probably 500+ users working with the asammdf GUI daily on CANedge raw bus logging files, the above changes would be a radical improvement. Based on my own usage, I believe it would reduce the no. of clicks required for day-to-day operations by 80-90%. At the same time, it would simplify the user interface by removing the 'Bus Logging' tab per file. And for most users, adding a DBC file for decoding would become a 1-time operation - not a 1-time-per-file operation.

I realize the above are dramatic changes, hence why I would propose the 2-step structure via feature branches. And at the end of the day, it is of course 100% your decision Daniel. But I hope you'll consider this as our team is confident this could be a 'game changer' in terms of UX for the asammdf GUI.

Martin

[danielhrisca]

Hello Martin,

this would be a big change for sure. I can't say if or when it would be tackled.

[MatinF]

Fully understand :-) thought I'd create a suggestion/outline for potential iteration over time and to serve as inspiration. I wouldn't expect this to be something that could be implemented short term