-
Notifications
You must be signed in to change notification settings - Fork 289
Wishlist
If you'd like to see something in SavvyCAN then edit this page and add it!
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.
There are many things that SavvyCAN could do that would be useful to some people but completely worthless to others. A prime example is the MotorControlConfig and Firmware Updater screens. These are special and really don't have any place in a general SavvyCAN distribution. They crept in when I was trying out some new things and really need to go. But, they'd be fine as plugin modules. QT does support plugins. Now, the next question is how to distribute plugins and what functionality should be broken out into plugins? Scripting systems might be another good candidate. I want to add python as a scripting system alongside the current JavaScript support. A preliminary step might be to cut the project into libraries. Once it is compartmentalized it'll be easier to turn some libraries into plugins.
QT has support for creating an installer that can then also update the program when new versions come out. It also supports modular installation so plugins could be supported by each being a module in the repository.
Add attribute to DBC messages for whether a message is cyclic and if so the interval. This could just be "useful information" or it could be used somewhere for, say, an ECU simulator. If the range and interval are defined then it'd be possible to make a somewhat generic simulator that could generate signals that conform to the criteria, along with things like how much it should vary and how quickly.
The program should allow people to lay out signals within ISO-TP formatted messages. Currently it isn't possible to really define a graph or DBC signal in terms of an ISO-TP message. Should be implemented for all features.
Today its possible to use ISO-TP decoder to view multiframe data. But it should also be possible to save the combined data as a logfile.
Also, other higher level protocols like J1939 and CANOpen should eventually be supported as a source for signals and graphs. So, a generic approach is best. It's already possible to mark a DBC file as having J1939 signals. This slightly changes the way signal matching works but doesn't add support (yet) for longer multi-frame messages.
Somewhat related to CANOpen/J1939 multi-frame messages is the concept of indexed messages. Some messages have an index in them that is used as a multiplexor. The program can already use the multiplexor and then you can create separate signals that rely on that value. But, quite often this sort of thing can go on for nearly 100 signals that are all basically the same over and over. It would be handy if the program could either auto-generate all the signals for you given the multiplexor and a list of signals found in one message or if it could automatically otherwise use this information to create "phantom" signals that properly number themselves to decode all the values. Along this same discussion, the graphing window can be a little weird about multiplexed messages. It counts data points based on the number of frames that match the ID but not all frames with the matching ID will match the multiplexed value. Some work will have to be done to smooth this out.
A lot of people would rather the scripting interface in SavvyCAN be python, not JavaScript. JS was just easy because the scripting interface was included already with QT and well integrated. Python can be used for scripting but the support isn't quite as pre-packaged and nice. Still, Python is the way to go. A lot of work has already been done to create useful python code that runs on the command line. It would be easier to port it to python hosted in SavvyCAN than it is to port over to JavaScript.
Maybe add a text box on the Flowview window that allows for jumping to a specific frame. However, this is complicated by the fact that Flow View uses a different numbering scheme than the main window. In Flow View frame numbers are segregated by ID so jumping to 2000 should do what? Probably jump to the 2000th frame with the current ID. It must be made clear that this is the case.
Similar to workspaces in IDEs, it'd be nice to be able to save a subset of SavvyCAN.ini as a project. This may include:
- currently loaded DBCs
- settings for connected devices
- currently configured frame filters
Support changing the frame ID for records in the frame sender window. Currently the modification field can be used to change the data bytes but not the ID. But, there are valid reasons to want to change the ID too. For instance, perhaps you want to try the same data but scan through IDs to see which one responds to that data. This also leads to another thought that perhaps the Fuzzing window should allow direct entry of the value for each data byte instead of requiring people to try to figure it out by clicking the 8x8 grid cells.