collin80 / savvycan

QT based cross platform canbus tool

SavvyCAN

Qt based cross platform canbus tool (C) 2015-2024 Collin Kidder

A Qt5 based cross platform tool which can be used to load, save, and capture canbus frames. This tool is designed to help with visualization, reverse engineering, debugging, and capturing of canbus frames.

Please use the "Discussions" tab here on GitHub to ask questions and interact with the community.

Requires a resolution of at least 1024x768. Fully multi-monitor capable. Works on 4K monitors as well.

You are highly recommended to use the CANDue board from EVTV.

The CANDue board must be running the GVRET firmware which can also be found within the collin80 repos.

It is now possible to use any Qt SerialBus driver (socketcan, Vector, PeakCAN, TinyCAN).

It should, however, be noted that use of a capture device is not required to make use of this program. It can load and save in several formats:

1. BusMaster log file
2. Microchip log file
3. CRTD format (OVMS log file format from Mark Webb-Johnson)
4. GVRET native format
5. Generic CSV file (ID, D0 D1 D2 D3 D4 D5 D6 D7)
6. Vector Trace files
7. IXXAT Minilog files
8. CAN-DO Logs
9. Vehicle Spy log files
10. CANDump / Kayak (Read only)
11. PCAN Viewer (Read Only)

Dependencies

Now this code does not depend on anything other than what is in the source tree or available from the Qt installer.

Uses QCustomPlot available at:

http://www.qcustomplot.com/

However, this source code is integrated into the source for SavvyCAN and one isn't required to download it separately.

This project requires 5.14.0 or higher because of a dependency on QtSerialBus and other new additions to Qt.

NOTE: As the code in this master branch sits, it does compile with QT6. Support for QT6 is approximately "beta" quality. Most all functions should work, please send issues if found.

It appears that the current binary build for MacOS requires at least MacOS 10.15

Instructions for compiling:

Download the newest stable version of Qt directly from qt.io (You need 5.14.x or newer)

cd ~

git clone https://github.com/collin80/SavvyCAN.git

cd SavvyCAN

~/Qt/5.14/gcc_64/bin/qmake

make

Now run SavvyCAN

./SavvyCAN

On linux systems you can run ./install.sh to create a desktop shortcut.

Compiling in debug mode for additional information

qmake CONFIG+=debug

make

What to do if your compile failed?

The very first thing to do is try:

qmake

make clean

make

Did that fix it? Great! If not, ensure that you selected SerialBUS support when you installed Qt.

What to do if qmake fails with error Project ERROR: Unknown module(s) in QT: qml serialbus help on Ubuntu? :

sudo apt install libqt5serialbus5-dev libqt5serialport5-dev qtdeclarative5-dev qttools5-dev

Used Items Requiring Attribution

nodes by Adrien Coquet from the Noun Project

message by Vectorstall from the Noun Project

signal by shashank singh from the Noun Project

signal by juli from the Noun Project

signal by yudi from the Noun Project

Death by Adrien Coquet from the Noun Project

savvycan's Issues

Create a way to filter captures

There are two alternatives:

1. To allow a filter to be used while saving so that only some frames are saved
2. To allow a filter to be used on the captured data so that only some frames are captured

Both have their perks. Option 1 allows one to save the frames into various files one after the other with a minimal fuss. Option 2 could be done on the fly so that incoming frames aren't saved if we don't care. But, that discards the data irretrievably.

The best approach might be a hybrid approach. Have a filtering setup that allows for filtering of the displayed frames on the main view. But, all frames are still captured. The filtering can be changed on the fly. Then, saving can be done either on the filtered frames or for the whole capture. This way basically is pretty much possible. Also, it should be possible to load and save the filter set up so that they can be quickly set too.

Random crashes while capturing

It seems like there are still some random crashes while capturing. They never seem to happen in debugging builds (naturally) or when a debugger is attached to a release build. But, sometimes the program will crash while capturing with a release build.

It would be good to get reports if anyone knows what could cause this. It seems to very rarely happen now but any crash is one crash too much.

Default file extension (during save)

Save any file default with the proper extension. Does not happen (at least not under Ubuntu). Had to search the source code to find ie the flt extension.

Building error

Hi, I'm getting this error while building despite the successful installation of qscintilla:
ui_scriptingwindow.h:23:32: fatal error: Qsci/qsciscintilla.h: No such file or directory

Make instructions

What would be extremely helpful is to have build instructions. I have git cloned the project before on my plain-vanilla Ubuntu 14.04 LTS. Entering qmake gave

qmake: could not exec '/usr/lib/x86_64-linux-gnu/qt4/bin/qmake': No such file or directory

OK, seems to be an issue in Ubuntu, and as the project is stated as a Qt5 project anyway AND given that Qt5 seems to be available in /usr/lib/x86_64-linux-gnu/qt5 I ran

sudo apt-get install qt5-default

After that, qmake gave me

Project ERROR: Unknown module(s) in QT: qml serialport

I remember having "fixed" that one under Qt4 but it was a PIA, I certainly f-ed up part of my system back then. And yes (humble pie) even forgot how I "fixed" it.

As said, a short instruction or even a pointer to fix that qml serialport issue would be massively appreciated.

File loading is brittle

It is very easy to crash the program by loading a malformed file. If a file isn't in the proper format it is very likely to crash most any of the file loaders. There is no exception handling right now so this crashes everything. No bueno!

Phantom frames when sending

In bleeding edge (V143) there is new support for showing Tx frames in the frame view. When sending frames it can be seen that phantom frames seem to come in as Rx frames. But, nobody is sending anything. The receiving side shows the proper number of transmitted frames so frame transmission is working but somehow the sending side is also getting phantom frames reported.

Compile warning

Totally irrelevant I guess, but on my system, I do get compiler warnings. Just in case it would bother you and not showing up on your end. FYI:

graphingwindow.cpp:82:6: warning: unused parameter ‘event’ [-Wunused-parameter]
void GraphingWindow::closeEvent(QCloseEvent event)
^
graphingwindow.cpp: In member function ‘void GraphingWindow::legendDoubleClick(QCPLegend, QCPAbstractLegendItem*)’:
graphingwindow.cpp:175:15: warning: unused variable ‘idx’ [-Wunused-variable]
int idx = -1;
^

frameinfowindow.cpp:37:6: warning: unused parameter ‘event’ [-Wunused-parameter]
void FrameInfoWindow::closeEvent(QCloseEvent *event)
^
frameinfowindow.cpp: In member function ‘void FrameInfoWindow::updateDetailsWindow(QString)’:
frameinfowindow.cpp:108:9: warning: unused variable ‘idx’ [-Wunused-variable]
int idx, numFrames, targettedID;
^
frameinfowindow.cpp:108:14: warning: unused variable ‘numFrames’ [-Wunused-variable]
int idx, numFrames, targettedID;
^
frameinfowindow.cpp:115:55: warning: unused variable ‘numBase’ [-Wunused-variable]
QTreeWidgetItem *baseNode, *dataBase, *histBase, *numBase, *tempItem;
^
newgraphdialog.cpp:115:6: warning: unused parameter ‘idx’ [-Wunused-parameter]
void NewGraphDialog::loadSignals(int idx)
^
newgraphdialog.cpp:131:6: warning: unused parameter ‘idx’ [-Wunused-parameter]
void NewGraphDialog::fillFormFromSignal(int idx)
^

newgraphdialog.cpp:115:6: warning: unused parameter ‘idx’ [-Wunused-parameter]
void NewGraphDialog::loadSignals(int idx)
^
newgraphdialog.cpp:131:6: warning: unused parameter ‘idx’ [-Wunused-parameter]
void NewGraphDialog::fillFormFromSignal(int idx)
^

serialworker.cpp: In member function ‘void SerialWorker::procRXChar(unsigned char)’:
serialworker.cpp:210:12: warning: enumeration value ‘TIME_SYNC’ not handled in switch [-Wswitch]
switch (rx_state)
^
serialworker.cpp:210:12: warning: enumeration value ‘SET_DIG_OUTPUTS’ not handled in switch [-Wswitch]
serialworker.cpp:210:12: warning: enumeration value ‘SETUP_CANBUS’ not handled in switch [-Wswitch]
serialworker.cpp:210:12: warning: enumeration value ‘SET_SINGLEWIRE_MODE’ not handled in switch [-Wswitch]

candatagrid.cpp:42:6: warning: unused parameter ‘event’ [-Wunused-parameter]
void CANDataGrid::paintEvent(QPaintEvent *event)
^
candatagrid.cpp:141:6: warning: unused parameter ‘width’ [-Wunused-parameter]
void CANDataGrid::saveImage(QString filename, int width, int height)
^
candatagrid.cpp:141:6: warning: unused parameter ‘height’ [-Wunused-parameter]

flowviewwindow.cpp:107:6: warning: unused parameter ‘event’ [-Wunused-parameter]
void FlowViewWindow::closeEvent(QCloseEvent event)
^
flowviewwindow.cpp: In member function ‘void FlowViewWindow::refreshIDList()’:
flowviewwindow.cpp:326:30: warning: unused variable ‘item’ [-Wunused-variable]
QListWidgetItem item = new QListWidgetItem(Utility::formatNumber(id), ui->listFrameID);
^
flowviewwindow.cpp: At global scope:
flowviewwindow.cpp:431:6: warning: unused parameter ‘check’ [-Wunused-parameter]
void FlowViewWindow::changeLooping(bool check)
^

framesenderwindow.cpp:42:6: warning: unused parameter ‘col’ [-Wunused-parameter]
void FrameSenderWindow::onCellChanged(int row, int col)
^
framesenderwindow.cpp: In member function ‘void FrameSenderWindow::doModifiers(int)’:
framesenderwindow.cpp:112:20: warning: enumeration value ‘NOT’ not handled in switch [-Wswitch]
switch (op.operation)
^
framesenderwindow.cpp: In member function ‘CANFrame* FrameSenderWindow::lookupFrame(int, int)’:
framesenderwindow.cpp:172:14: warning: address of local variable ‘frame’ returned [-Wreturn-local-addr]
CANFrame frame;
^

dbchandler.cpp: In member function ‘QString DBCHandler::processSignal(const CANFrame&, const DBC_SIGNAL&)’:
dbchandler.cpp:522:67: warning: variable ‘bitWithinByteEnd’ set but not used [-Wunused-but-set-variable]
int startBit, endBit, startByte, endByte, bitWithinByteStart, bitWithinByteEnd;
^
dbchandler.cpp: In member function ‘void DBCHandler::loadDBCFile(QString)’:
dbchandler.cpp:117:54: warning: ‘currentMessage’ may be used uninitialized in this function [-Wmaybe-uninitialized]
currentMessage->msgSignals.append(sig);
^

dbcmaineditor.cpp:70:6: warning: unused parameter ‘event’ [-Wunused-parameter]
void DBCMainEditor::closeEvent(QCloseEvent *event)
^

dbcsignaleditor.cpp:164:6: warning: unused parameter ‘event’ [-Wunused-parameter]
void DBCSignalEditor::closeEvent(QCloseEvent *event)
^

framefileio.cpp: In static member function ‘static bool FrameFileIO::loadCRTDFile(QString, QVector*)’:
framefileio.cpp:111:21: warning: unused variable ‘decimalPlaces’ [-Wunused-variable]
int decimalPlaces = tokens[0].length() - tokens[0].indexOf('.') - 1;
^

filecomparatorwindow.cpp:31:6: warning: unused parameter ‘event’ [-Wunused-parameter]
void FileComparatorWindow::closeEvent(QCloseEvent *event)
^
filecomparatorwindow.cpp: In member function ‘void FileComparatorWindow::calculateDetails()’:
filecomparatorwindow.cpp:272:81: warning: ‘valuesReference’ may be used uninitialized in this function [-Wmaybe-uninitialized]
if (!uniqueInterested) valuesReference->addChild(detail);
^
filecomparatorwindow.cpp:240:81: warning: ‘bitmapBaseReference’ may be used uninitialized in this function [-Wmaybe-uninitialized]
if (!uniqueInterested) bitmapBaseReference->addChild(detail);
^
filecomparatorwindow.cpp:290:56: warning: ‘referenceOnlyBase’ may be used uninitialized in this function [-Wmaybe-uninitialized]
referenceOnlyBase->addChild(valuesBase);
^

mainsettingsdialog.cpp:56:6: warning: unused parameter ‘event’ [-Wunused-parameter]
void MainSettingsDialog::closeEvent(QCloseEvent *event)
^

Receiving frames while filtering causes phantom records

If you have filtering enabled and are also still receiving traffic then you will likely see phantom records appear in the frame list. They won't have any data at all but they'll be numbered anyway. This isn't a big deal as they're harmless and go away when you change the filters. They don't affect anything but it's kind of annoying. So, it should be fixed.

Dynamic update of preferences when changed

Right now it is possible to change the preferences but mostly the application will ignore any changes until it is restarted. That's not too handy. It should detect preference changes and automatically apply them. For instance, if use hex mode is turned off the main display should change from hex to decimal automatically.

More control options

It'd be useful to be able to use the keyboard in more places. For instance, the graphing window very heavily relies on a mouse with scroll wheel. It'd be handy to be able to push "+" and "-" to increase / decrease zoom level. This feature should pay attention to which axis (if any) is selected and zoom accordingly. Also, add a hotkey to center and rezoom on the graphs. This same functionality should be added to the pop up menu (an entry to reset to a "good" view).

Lastly, investigate being able to use touch screen control of the graph window. Many devices have touch screens these days and it'd be neat to be able to interact with the graphs through touch control.

Support SocketCAN on Linux / Kvaser driver on Windows

Linux has SocketCAN which is a unified interface to many canbus tools. Windows doesn't have such a thing but it might be nice to support KVaser on Windows. Both would cause there to be some platform specific stuff in SavvyCAN but it's for a good cause.

Single step in playback doesn't send frames

Single stepping in the playback window will properly single step back and forth in terms of which frame # it is on but will not send out frames while doing so.

Setting to use filtered messages instead of all messages

Currently most sub-screens use the main frames list which is unfiltered. It would be nice if there were an option to make those screens use the filtered list so that it's easier to do analysis without having to constantly save all sorts of different versions of the filtered list and then load them one by one.

Default file type (Enhancement)

May I suggest to use GVRET as default file type, as it is "native"?

Implement Overwrite mode

Still need to implement overwrite mode. This is a mode where there is only one frame stored for each unique ID. Thus, this one frame entry gets overwritten each time a new frame of that type comes in. This is useful to see the current values for a given ID in realtime. There is a checkbox for this mode and it is exposed all of the way into the view model but it doesn't actually do anything yet.

Filter quick sets (Enhancement)

Add a "set all filters off" button.

Flowview live mode does not work

It appears that "live mode" in the flow view window was never finished. No data actually shows up but the graph increments forward as if it were. Something is messed up.

Additional operators in Custom Frame Window

The custom frame window allows operators like +, -. *, / as well as &, ^, and |. That makes add, sub, mult, div, and, xor, or. But, support for modulus, not (bitwise) should be added. Maybe think of other operators too.

Add persistent settings for connection dialog

The connection dialog should track which port you're currently connected with and also save that setting for the next run (if the port still exists). At the moment if you are connected to a serial port it won't necessarily show up as the port when you go back into the connection dialog. Also, you cannot start the program and click connect. You have to go to the setup screen for connections first. But, it should be possible to store the last used connection and use it again.

Multi-file sequence sending in playback window

It should be possible to set up a list of files that get played back one after the other in sequence so that custom combinations can be made. Each file should be able to be played a set # of times before going to the next and the whole sequence should be loopable. In place of a file it should be possible to also playback the captured frames onto the bus (with files optionally before and/or afterward).

32 bit version of SavvyCAN for Windows miscompiled

It seems that the supposedly 32 bit version of SavvyCAN has been miscompiled as a 64 bit executable instead. That's kind of evil. Fix that.

Dynamic updating sub-screens

It would be useful if the various subscreens could dynamically update when new data comes in. For instance, the graphing view could continue to accumulate graphed data and add it to the graph. The detailed data view could dynamically update, etc. There is rudimentary support for this already but it is not hooked up anywhere.

Allow for custom baud rates

There are some instances where devices use a very non-standard speed. Why do they do this? Who knows. But, it is possible to find 80k, 83.333, 100k, and other oddball speeds. It should be possible to allow for custom baud setting in savvycan.

Capturing traffic doesn't work properly on some machines

There is a report that, at least on an OSX machine, the capturing doesn't work properly. The device will connect but no frames will show up on screen even though there are frames coming in. Pushing the normalize button causes the previously captured frames to be shown but the list of # of frames shows zero still and the filter list does not update. This happened to me initially on Windows when testing for this problem but thereafter would not happen no matter how many times I tried. It has never occurred to me in Linux. I tried to replicate in OSX but I'm having trouble getting my OSX copy to work properly. So, the mystery deepens.

Sending while receiving crashes

When sending frames from the playback window you cannot have reception also enabled or it crashes

Save/Load graph definitions

Currently there is no way to save the graphs you've got set up nor a way to load them. It can be very time consuming and tedious to set up the graphs. Life would be a lot simpler if sets of graph definitions could be saved/loaded when needed.

Fuzzy Scope

The idea behind fuzzy scope would be to search for data that doesn't conform to discrete states. An example would be an RPM read out. It could be all over the map from 0 to 10k RPM and everywhere in between. The fuzzy scope would operate on live captured data and ask the user to do things to try to narrow down the data location. For instance, the user might be asked to do nothing, then try to increase the value, then hold steady, then decrease. Then, data that conformed to this pattern would be shown to see if any of it might have been what we were looking for. The user should be able to tell this mode what they want to do (like the up, steady, down example above). Here are some mode ideas:

1. Up, steady, down. Used to find RPM or throttle type data or maybe amperage while driving. Requires the user to be present and actuating things on queue.
2. Trends upward over a long time - used to find charging data? Could be left to its own devices while the operation is under way.
3. Trends downward over a long time - used to find SOC while driving? Could be left to its own devices while the user is driving around.

Graphing window issues

1. Seems that sometimes when you're working in the graph and traffic is coming it it'll crash. Tsk! Tsk!
2. You cannot load a graph definition file that contains DBC signal graphs. The signal graphs just plain don't show up properly upon load.
3. When you select to use a DBC signal in the add graph window it'll have a default signal that is the first signal from the first message. But, this default won't actually work. You have to go select something else then go back to the first one if you want to actually graph it.
4. It isn't possible to edit a graphed signal. Once a signal is selected to be graphed the signal parameters should be copied to a standard graph. This could fix the loading issue too perhaps. People are going to want to be able to base a graph on a signal but then edit it to fit the rest of the data if necessary.
5. If a DBC file is loaded after the graphing window is first shown then that DBC file will not ever be possible to use with the graphing window. 👎

Can't get SWCan to work

Watching SWCANMode0 and SWCANMode1 they both seem to be low no matter what I do with Savvycan V136. On the other hand running GVRET V325 in terminal mode they are both always high wether SINGLEWIRE=0 or 1?

My board has no EEPROM

Some save formats are not implemented

Some of the saving formats are not actually done and just silently fail (Busmaster, microchip, generic). These should be implemented some day.

Complete implementation of time in seconds mode

There is now a mode that will turn time stamps into time in seconds instead of microseconds. Yes, this just adds a decimal point but it's handy for mere mortals who are used to seconds. It is currently only working in the main window frame view but should be persisted everywhere in the application.

Single / Multistate Analysis

There should be a mode that scans for events that fit into a single or multistate switch. For instance, there might be a signal for whether the brake is down. This is either a yes or no answer and so is considered single state. It either is or isn't. A multistate value would be something like a shifter. It can be in PRND for instance and so there are 4 values (or more). This is multistate. This mode would operate on live captured data and ask the user to toggle the state to try to isolate where it is in the data stream.

DBC Editing not yet done

The DBC editing code was started and is partly operational but not fully. So, finish implementation. Also, test loading and saving with various files to ensure code works properly in all cases.

Frames transmitted have wrong timestamp

Any frames transmitted by SavvyCAN will have essentially random timestamps placed on them. Instead SavvyCAN should sync itself to the clock on the attached capture device and use that to properly time stamp any frames it sends.

Comm validation failures randomly

While testing it was found that sometimes the comm channel fails to validate. This caused crashes in the past when sometimes the channel would crash and begin to reset and then other code would run expecting the channel to be up but it was not. The crash has been corrected (in WIP2 as of right now) and things seem to be pretty stable (in linux at least) but there is no reason to see random comm validation failures. The cause of the failures should be investigated.

Comparison mode

Mode to compare two canbus captures to find things like ids in only one of them, bit field diffs, etc.

Weirdness in custom frame sender

It seems as if the custom frame sender works oddly if you have a lot of modifiers running at the same time. It looks as if all modifiers after the first are poisoned a bit by the first one and so they seem to not produce completely accurate results. For instance, incrementing in the second or third modifier might pick up some numeric data from the subsequent modifiers and this makes things a little weird.

Implement changed frames view

The linux can tools package has a command that can be used to show the flow of frames where frames with frequently changing data bubble to the top and changed bytes are highlighted. This is kind of like the flowview window that already exists in SavvyCAN but would be implemented in more of a table format that is kind of like overwrite mode on the main form but with reordering to bubble frames that change to the top and coloring to highlight bytes that have changed. That's kind of like the bitfield view in flowview. Really, this would be kind of an alternative to flowview with a bit of a different layout GUI based but reminiscent of the way the linux command line tools work. This isn't so important on linux (obviously) but nothing of the sort exists for Windows or OSX (that I know of).

Documentation

Documentation should be added to the project. Currently there are a few pages but they aren't linked to the program yet. Fill out more documentation and also link to it from the relevant areas in the program itself.

Synchronize flow view and graphing windows

These two windows are graphed with potentially different X axes. The flowview window can graph by timestamp (like the graph window does) or by frame number. But, even when it graphs by timestamp it does so without biasing the timestamp to start at 0 like the graph window does. The graph window has an automatic bias to start at X=0 because it's easiest to set up graphs this way. But, because of this discrepancy, it is extremely difficult to look at data in both windows and be looking at the same point in time.

There are a few options here.

The flowview window could bias to start at 0 on the X axis as well. It currently doesn't do that because it is trying to match timestamps to the main frame list.

The graph window could quit biasing to 0. This might be the best option because then it will match the timestamps in flowview and on the main frame list. That synchronizes everything. It is currently possible to cause the main list to bias to start at 0 time so that button can be used to make all of the windows start from 0 time on the X axis.

Also, it might be possible to cause a click on the graph in either flowview or graphing window to update the other so that the view is centered on the same X position / timestamp.

Test new playback system

Test playback system with live traffic both coming and going to ensure it works and doesn't crash while also receiving.

Custom frame sending window

It has been started but not completed yet. The idea is to allow for a bit of a scripting like ability to create custom traffic on the canbus. This traffic can be triggered by things like time going by (every 10ms), number of frames to send (do it up to 100 times), reception of a frame (send a custom frame every time frame 0x101 comes in). Additionally, the data sent can be scripted a bit (increment a byte, grab data from incoming frames, modify it, and place it into an outgoing frame), etc. This could be pretty powerful but complicated. It was completed in the C# program but was pretty brittle and very picky of syntax. Use regex in this version to make the syntax much less picky.

Random comm freezing

It seems that sometimes, with some hardware, the communication between GVRET and SavvyCAN will cease. A disconnect and reconnect cycle will fix this problem, at least temporarily. Some hardware (that runs GVRET) is worse than others. So, it seems to be an issue at least partly related to hardware but cycling the communications fixes it so presumably a software fix is possible.

Try validating the comm every so often and cycling communications if things go south.

Multi packet messages

While I have no suggestion how to implement this, I have seen on my EV multi packet responses for some modules. For example, when querying the Lithium Battery Controller for cell subassembly temperatures, the response is 24 blocks of 3 bytes (2 raw, 1 calibrated), and two more bytes with averages. Total message size is 74 bytes. This is spanned over 4 bytes in the first response message, which also contains the number of bytes still to follow (70) and then 10 more packets. These 10 response packets are numbered in their first byte and can either be requested all at once (one query [0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00], 10 responses) or one by one (a new query for each consecutive response, [0x30 0x01 0x00 0x00 0x00 0x00 0x00 0x00]).

I have no idea if this is a "generic" approach for CAN devices. If it is, and it is worth to implement, I guess a state machine is needed per CAN id.

Auto fill in serial ports

Currently the list of serial ports is set in stone when the program starts. That's kind of silly. The list should be regenerated every time it is dropped down.

V150 - crash when clearing frames with certain windows open

It is possible to crash the program by clicking the clear frames button while sub windows are open. The sub windows that will do this are the ones that read incoming frames. These windows can receive a message to read incoming frames after the clear button has already erased them and this makes the program crash. Fix all windows that have this bug.

File Comparison doesn't properly compare bytes

The file comparison screen is supposed to track values on a per ID, per byte basis.

For instance, if file1, ID 0xE, byte 1 has a value of 0x20 at some point but file 2 never does then it should be reported. This doesn't properly happen.

Mode to use decimal instead of hex not finished

There is a mode to turn off hex display and revert to displaying all numbers in decimal. Currently this mode only affects the main frame display. It should propagate to other screens such as flow view and the info views. However, this isn't a big priority because hexadecimal is the far more common choice.

Timing enhancements

It'd be nice to be able to reset the timestamp so that it's easier to figure out when things happened. Likewise, investigate how to correlate real world readings and happenings to canbus capture. For instance, maybe the car was shifted near the 5 second mark or the mph was around 55 at the 30 second mark.