Fuzzy Scope

[collin80]

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.

[yoh-there]

As a simple alternative to this and (and even more to state finding), what has helped me a lot is to display in a tabular form, a cell per seen CAN id, simply all 8 cell values is hex, real time. Our visual system is really good in finding correlations so things like pressing buttons jump out rather fast.

A further enhancement to this idea would be to slowly "dim away" bytes, or even packets that do not change over time.

My "implementation" was very crude, terminal style, so the code itself is not very usable I guess. In the picture the upper half already has "some" interpretation added. The still unknown packets run in the bottom half.

[collin80]

The linux CAN utilities actually have pretty much the exact functionality you're talking about. I can see how that'd be handy.

I suppose there could be some way to do this in a GUI app.

Perhaps have a screen with one line per ID and with frames that have changing data naturally grouped toward the top? The problem with EV drive systems is that there are over a 100 messages generally and not all of them can fit on the screen at once. So, the view would have to bring changing messages up the top. But, it messes up visual inspection if the rows change ID too rapidly so it would have to be done very carefully.

How about the view defaults to being sorted by number of changes since the start of the capture then by ID but you can pin any row you want? That way rapidly changing rows naturally rise the top and IDs with totally unchanging data sink to the bottom where presumably no one is looking.

So, the idea is to have a screen with a table of data, one row per ID. The IDs with rapidly changing data rise to the top, rows with unchanging data sink to the bottom. Otherwise it is sorted by ID. The user can pin a given ID in place by clicking a checkbox in the row. They can also filter which IDs they are even viewing (to remove any IDs they know they're not interested in) As in your screenshot, it should be possible to name a frame ID for easier human friendliness. SavvyCAN can use the name from loaded DBC files.

The GUI will utilize a model/view system with a model based tableview. The underlying model gets updated as traffic comes in and is sorted as above. This is all sort of like a more configurable version of overwrite mode that's found on the main window.

[collin80]

The sniffer window has existed for a long time and satisfies the simple alternative suggested by yoh-there. Additionally, there is a "Range State" window that is somewhat similar to my first idea above. So, this issue will be closed as suitable functionality does exist.