The ability to save a display configuration is very useful for quickly opening up previous analyses/views.
However, it would be great if it would be possible to not only store 1 plot window - but that the display configuration stores the full 'grid' of plot windows with the correct sizing, focus area, plot coloring, zoom level (for GNSS plots) etc. This would enable almost a 'dashboard' style view in asammdf with minimal effort.
When I save this as a display config, close the plots and open the display config, I do indeed get multiple windows now - but the focus seems off. It would be OK with the focus not being saved, but it would be nice if then at least the 'default' focus is selected when the display is loaded, so that the entire plots are displayed:
This would put everything in all pages within a single schema. In the case we have an array of required elements, then, perhaps validation errors could show only at the end once all pages are completed.
Not sure if this is the right way to do it; would appreciate some feedback!
We created a version of the react-jsonschema-form-pagination project that includes just the tabs functionality and which works with the latest rjsf versions. You can find it here: https://github.com/CSS-Electronics/rjsf-tabs
It would be ideal to modify this so as to better integrate with rjsf through e.g. the plugins functionality, or perhaps an integration into the core project. But we are not sure what that would require in terms of code modification. However, we're hoping our updated project may help others and may serve as the basis for a more formal integration.
Bus Logging: #IDs matched vs. total is incorrect for J1939
The Bus Logging print output displays the total number of CAN IDs in the log file, as well as how many of these were 'decodable' using a set of DBC files. However, when converting data using a J1939 DBC file, the numbers are misleading.
Example: An MF4 may contain 300 unique CAN IDs, but only 100 unique PGNs.
In this case, a DBC file may match 10 unique PGNs, corresponding to 30 unique CAN IDs
The console output will display this as if the DBC decodes 30 of 100 IDs (30%)
In the above example, we are comparing "CAN IDs" vs. "PGNs", resulting in an incorrect comparison.
A better approach would be to either:
Always display these numbers as CAN IDs (in the above case it would then show 30 of 300 IDs)
Always display these numbers as PGNs if J1939 (in the above case it would then show 10 of 100 IDs)
I think the error has arisen since the removal of 'bundling' IDs by PGN for J1939, which has resulted in all PGNs being separated by their SA. This is OK for the final output, but it currently results in an incorrect print output.