Future Tuning Software User Feature Wish List (UI stuff)

[Fred]

Yep, thanks :-) http://wiki.winehq.org/GdiPlus

[davebmw]

Hmm thats the second time I have seen the maps arranged opposite to the MT. the Emerald ECU on my fathers Volvo is RPM up the Y axis and Load along the X axis.

After using the two types for base tuning i think i can relate to the MT format better. Would this be something that could be altered in settings to change the load v RPM format??

Just thinking that would make it easier for people to trim the program to what they are used to and encourage more people onboard.

Would still like both VE and Adv 3D maps on one page with a basic configuarable dashboard on the bottom. that would make tuning a piece of piss.

[deviousKA]

I like an mdi interface, where any selection of settings can be open and viewable at a time. It also makes viewing with small screens (mini laptops) easier as you only need to open what you need.

I think gauges should be seperate from the maps, and re sizable. With an mdi interface you could have 1 or both of the maps open while having full selection of gauges open in near full screen mode in the background, or smaller and positioned next to the map, or whatever you want.

I have to connect to an ecu to enable viewing of all parameters in my nissan software, next time I have it running, ill take a snapshot.

its a bit like this software, http://nistune.com/

[BenFenner]

Hmm thats the second time I have seen the maps arranged opposite to the MT.

Would this be something that could be altered in settings to change the load v RPM format??

I second this. While I prefer the RPM axis on the bottom and Load on the left, I think it's a great idea to be able to swap these, or allow labels on the right and top as well so those who prefer that style can be happy.

[BenFenner]

While thinking about an earlier suggestion about table re-sizing I came up with an idea.

Basically Fred was asking what size tables should be provided for VE/lambda target/ignition timing, etc.
The decision was that they would be variable (From 2 x 2 to 23 x 2 to 2 x 21 to 23 x 21 or something close. Fred would know.). The idea was that the GUI would provide the ability to change the size. I'd previously thought of just dragging and dropping the corners of the table to "reveal" more area of the map. I've got a better idea now and it stems from a new feature request.

New feature request:
Re-sizing a table should give the option to automatically calculate new cell values based on old cell values. The other option would be that new cells are added "empty" or cells you're removing are just chopped off instead of re-integrated.


I'm imagining some sort of "table resizing wizard" even though I hate "wizards" with a passion. Something else should be figured out obviously to avoid the wizard approach. The idea goes like this though:

Say I have a turbo Nissan SR20 engine. It runs at 1.4 bar of boost, redlines at 7,500 rpm and torque peak is around 5,250 rpm. I've got a real good VE table set up already with what I thought would be sufficient resolution. Here it is:



I start going to the racetrack and realize I've got way too much wheel spin. I need to turn the boost down. Might as well adjust the map too while I'm at it. I want to run no more than 0.6 bar now and I'd like to "chop off" the top couple of rows. Now my table looks like this:




Instead of going to the race track and wanting to run lower boost, I instead install a stroker kit with more aggressive cams without installing stiffer valve springs. I can't rev to 7,500 rpm anymore so let's chop that part off the table:




Now instead of the stroker, I've got cold start issues that I'd like to take care of by adding a new column way early on during the start-up process. I don't know what values I'd like, so I choose to fill with blank values (maybe zero?):




This time I've decided to install some valve springs, a nice cam, a shorty header and intake. It's time for more revs:




Revs are off the table this time and variable valve timing and lift is on the table (thanks to the SR20VE head ). I'm switching the cams at 4750 rpm and want more resolution around that area than I had before:




So I ditch the variable valve idea and now I tighten up my vacuum leaks and realize while going down hill in 5th at light throttle I run very low down on the map. I need more area there:




Next up we've got a common situation. Want more boost! (But not that much more )




So I find out my Japanese engine isn't all it's cracked up to be and I've got a pretty restrictive throttle body. It's so bad my N/A line needs to move down some. Time to add a new line:




Now this is where we can really have some fun. After a lot of thinking I've decided my boost area doesn't need as much resolution as I previously thought. I'll chop out a couple rows at the top of the map and replace them with a new kPa valued row that's sort of in the middle of all of them. I don't want blank values however, I'd like the table to have the values it would have had during my old tune. The newly calculated row is highlighted:




Now this next example is very, very important and addresses a couple of subtle things. Why not just delete your old rows, add in the new single row (with "empty" values) and then use the tools already in place to calculate the values for the new row? The problem with that comes when you want to replace a "peak" or "valley". This data would be smoothed over with the above mentioned technique instead of doing what we'd like it to do. What we'd like it to do is put the values in the table that the EMS would have calculated during it's normal operation. So, now I see that I have two rpm columns that have identical values. There may be a reason to keep this. This is actually common and usually good and proper. But I've found I can do without this situation and collapse those two columns into one.



If they'd been given "empty" values and then I manually "calculated" the middle values, I'd come up with something different than what was there to begin with.


Anyway, pardon my Excel usage, and let me know if I've gone off the deep end.

[Fred]

Table resizing is available in the firmware right now (and has been for a while) however it is safe to ignore it in the short term to speed development.

I like the insert, delete, extend, stretch ideas :-)

The scale idea is the obvious one, but what you've suggested is pretty cool.

BTW, there is no bottom end limit. You can go down to 2x2 for all I care LOL

The data structure contains the information on how far you can go with it. I may change the format of that though to ensure it can't be accidentally changed by a tuning tool I will probably move that out to the packet data for transfer instead as attributes if you like.

Fred.

[BenFenner]

Heres how I set up map grid and 3d view on a nissan editor I wrote.

I'm glad you posted this image so I could make a critique. I like this a lot for many usability reasons. Table and Map both predominantly displayed. Option to stream current info to "floating ball" on 3D map is great (I assume table can do the same). Changes to table updates instantly to 3D map.

What I'd recommend is that the 3D map have much, much more resolution on the Z axis. My gripe with MegaTune is that their maps don't scale to your max VE value (they use 255 max always) and they didn't give enough scale to the Z axis. These together make for useless maps. You should be looking at a mountain range (similar to maps I posted of AEM's software before) not a prairie. That's the way I feel anyway.

[deviousKA]

Valid critique. The only real limitation with the way I am drawing the maps with gdi+ is that the top and bottom of the base must always be horizontal (no true rotate function).

The map can easily be dropped down and/or shifted in either direction, and the "z" axis can be exaggerated to show more detail as you mentioned. Locking the current maximum table value as the maximum Z (to provide maximum table viewing at any time) can also be done, just a little bit of code.

When I was looking into drawing 3d maps/tables I wasnt able to find any examples similar to what I wanted (wireframe landscape). Gdi+ has been thrown around a couple times on here so I just wanted to show an example.

The difficult part was the colors, ive got it now so I can blend any two colors for the high/low ranges (not just colors being close in the spectrum). The code would be a little more lightweight if it was drawn in only a single color though. I had to use transparency to accomplish this.

The table gridview is done using a .net datagridview component, during ecu trace mode both it and the 3d display the current (closest) cell being used.

[Fred]

Is it written in C# ? If so, you should keep it portable using the 2.0 libs and try running it on mono :-)

Even if it's not open source it can still be useful if you write a comms plugin for it ;-)

Fred.

[deviousKA]

It was originally written in vb.net (express visual studio), but lately I have been using #develop (sharpdevelop) open source IDE, it has a built in C# conversion that works pretty well. Thinking about continuing project in c# (nice being able to analyze your own converted code to understand the langauge).

I have been trying to stick with 2.0 if at all possible, there is no reason for me to use the newer framework seeing as the serial ports are worked out in 2.0 and its upward compatible.

Regarding the source, I would be willing to share code/help write some gdi+ for an open source freeems editor, thats what its all about right

Gabe.