markers in TS tuning windows

[msoultan]

Hey Phil,
One common problem I have when using either MT or TS is I have no reference of where things are unless I write it down in an external file. For example - at 67% load, that's when things start changing on my timing table - it would be nice to put a marker there. Or the area on the table at which is the cruise area - or decel, or idle.. know what I mean? If I put a special rpm or load in for a column or row, it would be nice to be able to place a comment/marker next to it with a little note as to the reason. Or to be able to change a group of boxes to a different color to denote that it's about where idle usually hangs out. That way you could mark areas like "cruise", "light load", "idle", "decel", "needs work here", etc. I think that this kinda feature would be especially helpful when tuning sessions have to be broken up into multiple sessions. Then when you pick up during the next session, it's easy to see where you left off at if you were good about making notes...

[dave]

i like this idea.. preferably have it on an easy to hit hotkey, like the spacebar or something.
my car had a spot at light load where there was a real on/off attitude, if i left the throttle there you'd start getting jiggled back and forth in the seat. To nail it down I had to keep it there for several seconds so that I could look it up in a log later and figure it out.

[LT401Vette]

Hmm, Interesting. I like this idea.
What if you could right click on a cell and select "Insert Comment" like you can in Excel. Then the comment would show in a tool tip when you move the mouse over the cell.

[msoultan]

exactly. Because then you'd know *why* you set that RPM bin there, or you know not to touch it because it's important for some reason. Right now, I never know why I did something because I set it so long ago. Having side-notes in a text file are helpful, but are a pain to cross-reference when you just wanna get in there and tune.

I think it would be helpful to be able to color a region as well, because then you can label it with different colors and notes (i.e. cruise, decel, idle, etc). It would be especially helpful when you have someone else helping out and you're telling them only to edit the are in the cruise zone.. or if you're doing some tuning and realize that your cruise area is actually bigger than the area you colored, you can see it much easier because it's obvious instead of trying to follow the lines back to the index markers.

I'm just trying to think of things that have been a problem for me when I'm tuning alone and/or trying to show my girlfriend how to tune while we're on a road-trip. I'm not sure if other people run into the same kinda problems, though.

anyways, yeah.. I'll keep the ideas flowin' your direction

[LT401Vette]

This shouldn't be to hard if the comments/notes are at the project level, however it seems better if they were at the msq level. That should still be doable, it just needs a little more thought

[msoultan]

Ok.. I was thinking about this some more and I think I came up with an even better idea. I think it would be awesome if every input screen, tuning window, etc. had its own notepad. Then you could write notes like "5/3/09 - changed afr at cruise to 15.1:1 because running leaner was causing bucking", or "raised up wb02 coolant activation from 150 to 160 because it was getting engaged too early (4/9/09)", etc. I would be taking notes like crazy!

The neat thing is that it changes the MSQ from being an engine tune to a tune with some history and information to go along with it. If you had a little window that would slide down or to the right or something like that, I think that would be even handier than the tool tips.

[LT401Vette]

I've been thinking about it more too, but more from a data perspective. I figure once I put in the storage, I should be able to attach notes to pretty much any setting, so a cell or a setting. The project verse msq has some interesting aspects. It seems you would want it at the msq level, so you could open any msq and see the comments you had attached to that tune, any thing you may have been trying there. Or if you sent it to someone, the comments would be in the tune for them to see.

But then you would have no comments if you just open the project and connect to a controller. I don't know if that is a big deal, but it seems like it would be nice to have the comments automatically there where you left off. I believe some people generally always open an msq before they start doing anything anyway, but other do not.

The request has been made before to automatically open an msq on project open, that might do it. But I think it might be nice to have a project level msq, one that always mirrors what ever you did while connected to the controller, then let's you continue to work in an off-line mode. If you reconnect and the off-line doesn't match, prompt you as to whether you want to write the off-line changes to the controller.

[msoultan]

I've been thinking about it more too, but more from a data perspective. I figure once I put in the storage, I should be able to attach notes to pretty much any setting, so a cell or a setting. The project verse msq has some interesting aspects. It seems you would want it at the msq level, so you could open any msq and see the comments you had attached to that tune, any thing you may have been trying there. Or if you sent it to someone, the comments would be in the tune for them to see.

Yeah, I think the MSQ would probably be the best place for them to go, pretty much for the reason you said. If I want to send you all of my work, it's just in one file, tune and comments as one.

But then you would have no comments if you just open the project and connect to a controller. I don't know if that is a big deal, but it seems like it would be nice to have the comments automatically there where you left off. I believe some people generally always open an msq before they start doing anything anyway, but other do not.

I always open a tune. An interesting thought would be to store the comments in the project as well as in the MSQ. The only problem is that things could get out of sync and overwritten. It would be weird if I sent an MSQ to you, you made comments and send it back to me. In the mean time, I had opened up TS and made some comments of my own - yeah, synchronization could be a pain.

The request has been made before to automatically open an msq on project open, that might do it. But I think it might be nice to have a project level msq, one that always mirrors what ever you did while connected to the controller, then let's you continue to work in an off-line mode. If you reconnect and the off-line doesn't match, prompt you as to whether you want to write the off-line changes to the controller.

I like the idea of always having a tune open. I view the project settings as being TS-specific settings, but not the MS controller settings. So for me, I would think seeing a blank screen (no gauges, nada) until I open a tune would make sense, but that's just me. I like to have one master copy of the tune and always work from that, online or offline. Since I only work from one computer, my master copy is on the computer, not the controller.

I do a lot of offline editing so I like to have a tune loaded and uploaded every time I connect to the controller so that I know all of my offline updates got sent over to the controller right at the beginning of the session. If, by accident, I don't open a tune and then start tuning the MS based on the tune that was pulled from the MS, it can then vary greatly from my offline edits and then it's a pain to synchronize all of the changes. Loading a tune and uploading it to the controller every time it's connected to the MS is an easy way to avoid those synchronization problems.

Maybe I'm thinking about things the wrong way, but it seems to work and keep things consistent...

[cygnus x-1]

Some random thoughts...

Maintaining a "tune" file reminds me of maintaining source code. Any time you change something it's good to put a comment there as to explain why the change was made. I wonder if .msq files could be maintained in a similar way to code version tracking? This might also be useful as various changes are made to the car/engine in order to track the effect of those changes. So really instead of maintaining lots of individual files, why not just maintain the project as a tree of diffs? Just like source code you could have stable versions and experimental versions. This way you could always go back to a stable version if you goof something up.

In regards to color coding the tables, having color coded regions might be useful. But to take it further (this is probably more related to MLV), how about being able to scan a datalog and get statistics on individual cells, like how often the value in that cell was used? Use that to color code the table and you can get a idea of which areas are used most (and least) while driving. MLV already does this for VE tuning so why not make use of that data?

Another thing that I would find useful for tuning tables is to be able to lock individual cells from being edited. I find that as a tune progresses I'm really only interested in certain areas that need work and I want to leave everything else alone. You can sort of do this with the filters in the VE analyzer but they seem cumbersome to use that way. After I have the VE mostly dialed in I tend to just scan through the logs and look for places where the AFR doesn't match AFRtrgt. Those are the areas I want to alter. Another cool way to accomplish this might be to allow selection of parts of the MLV graph to analyze, but do it graphically instead of through the filter. For example, I see a section in the graph where the VE is off, so I select that section and hit the analyze button. It's the same thing as filtering by time but you don't have to type in the numbers. And maybe also allow selection of multiple areas at once, so this spot here, another one there, that other part 2 minutes later, etc..

Oh, I just had another thought. If you have predefined area in a table, e.g. decel, cruise, light accel, etc. how about having some sort of dashboard indicator of what region you're in? You could use it like that eco assist dash in the new Honda Insights that tells you when you're driving efficiently. Or you could use it to show you when you are in an area of the table that needs to be tuned or doesn't. That would make it a little easier to tune those funny places in the tables that aren't in the normal range of engine operation.

To continue on the subject of feedback while driving, color changes are good because they are easy to discern quickly with out having to read numbers. But what about audio feedback? When you're driving you can't always be looking at the laptop screen to see what's happening. It might be cool to set audible indicators for things like O2 readings outside of set limits, or knock detections, or temperatures/pressures out of limits. This could also be useful for people that are color blind.

C|

[msoultan]

Maintaining a "tune" file reminds me of maintaining source code. Any time you change something it's good to put a comment there as to explain why the change was made. I wonder if .msq files could be maintained in a similar way to code version tracking? This might also be useful as various changes are made to the car/engine in order to track the effect of those changes. So really instead of maintaining lots of individual files, why not just maintain the project as a tree of diffs? Just like source code you could have stable versions and experimental versions. This way you could always go back to a stable version if you goof something up.

That might come in handy for history purposes, but then it would also have to keep track of what version of the firmware was used. Then if features changed in different firmwares, you'd have to cross-reference things and it could probably get kinda ugly, especially because a lot of stuff gets added and removed. The other issue is that when you'd send the file to someone else, you'd have to send them the merged file; I guess that wouldn't be that difficult to compile because the tuning software would have to do it anyways...

In regards to color coding the tables, having color coded regions might be useful. But to take it further (this is probably more related to MLV), how about being able to scan a datalog and get statistics on individual cells, like how often the value in that cell was used? Use that to color code the table and you can get a idea of which areas are used most (and least) while driving. MLV already does this for VE tuning so why not make use of that data?

That was one thing I always thought would be helpful - but in a couple different ways. One way was how much that cell was used (so you had an idea where you need to tune things), and the other way was to change the color the more a cell has been modified, so you can tell where autotune (or your tuner buddy) has been working (or messing things up!). This would help provide a good history of changes that were made.

Another thing that I would find useful for tuning tables is to be able to lock individual cells from being edited...

I think that would be handy, but that might be tricky because you'd need to lock the column/row index values as well. This one isn't as crucial for me, but it would be handy.

Oh, I just had another thought. If you have predefined area in a table, e.g. decel, cruise, light accel, etc. how about having some sort of dashboard indicator of what region you're in? You could use it like that eco assist dash in the new Honda Insights that tells you when you're driving efficiently. Or you could use it to show you when you are in an area of the table that needs to be tuned or doesn't. That would make it a little easier to tune those funny places in the tables that aren't in the normal range of engine operation.

This would be very handy - just another way to label different areas on the various tables so you know what area you working on at a quick glance. Plus, you'd also KNOW when you're in those funny places instead of trying to do weird load/rpm combinations while staring at the computer monitor and trying to avoid driving off the road ;)

To continue on the subject of feedback while driving, color changes are good because they are easy to discern quickly with out having to read numbers. But what about audio feedback? When you're driving you can't always be looking at the laptop screen to see what's happening. It might be cool to set audible indicators for things like O2 readings outside of set limits, or knock detections, or temperatures/pressures out of limits. This could also be useful for people that are color blind.

hahahaha! I was just trying to think of some kinda audio thing today and I couldn't think of how you'd use it, but I wanted to figure out something! Tuning alone is a pain and anything that can be done to look less at the screen is a very good thing!

[LT401Vette]

All good ideas. For seeing how much it hit areas of the table, I have a half built Scatter plot in MLV, so that will be coming there.

Cell Locking is something that has been requested before and doesn't seem terribly complicated, that could almost stay at the project level instead of msq though.

Audio Alerts, I have plan in place. It is just a matter of getting to it. But it shouldn't be terribly big.

MLV has a big backlog of changes, but TS has been blocking the pipes. Well, that and there was a hump to get over. TS uses many of the MLV components, but remember I started writing TS in Oct of 2006 so several of them got branched. I have tried to stop making any changes to MLV until I get them reintegrated, which I have done now. So the MLV 3.0 code base is up and working. So it is really just waiting for me to find some break point on TS to switch back there for a bit.