Wishlist

If you'd like to see something in SavvyCAN then edit this page and add it!

Single/Multi State: 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.

Support plugin system: 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 along side 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.

Installer/Updater: 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.

DBC Cyclic Messages: 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.

Allow ISO-TP frames for DBC and Graphing: 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.

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.

Better decoding of indexed 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.

Python scripting: 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.