Future Tuning Software User Feature Wish List (UI stuff)

Free Open Source Software project discussion forum. Post your Free Open Source software projects here!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Future Tuning Software User Feature Wish List (UI stuff)

Post by Fred »

A guy I refer to as vvvvvvvvvvvega suggested than when we get aux pins functionality enabled and working that the pins should be able to be labled. This is clearly a UI thing, ie, store in the settings on the PC what you want to call each pin so they are memorable. Makes good sense to me.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
tpsretard
QFP80 - Contributor
Posts: 99
Joined: Thu Mar 19, 2009 3:05 am

Re: Future Tuning Software User Feature Wish List (UI stuff)

Post by tpsretard »

i am sure this is not the right place but as i cant find the topic i will post here..

When you have an unused ignition or injection output, will we be able to use them for other things.
Like fan control etc..

Link is very good at doing this and so is motec.
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Future Tuning Software User Feature Wish List (UI stuff)

Post by jharvey »

Last I recall, the quick answer is yes, you can. However, it should be designed such that you don't have to do it that way.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Future Tuning Software User Feature Wish List (UI stuff)

Post by Fred »

The answer is yes, and I'm wondering what you mean by that Jared? Do you simply mean that because there are 90 odd usable pins you shouldn't run out for any reasonable engine? And that those functions will have their own, or just more suitable, pins already?
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Future Tuning Software User Feature Wish List (UI stuff)

Post by jharvey »

Correct, FreeEMS has many aux circuits. It's unlikely one will need to use an injector channel.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Future Tuning Software User Feature Wish List (UI stuff)

Post by Fred »

http://www.gotech.co.za/productprox.html

Some interface ideas there. That ECU is fairly poor in many ways, though.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Future Tuning Software User Feature Wish List (UI stuff)

Post by Fred »

viewtopic.php?f=10&t=218&p=5821&hilit=1 ... .jpg#p5821

Re this post of Ben's on page 3, I'd like to make it clear that it's NOT optional what to do in the blank holes. The required behaviour gives the exact same, or closest reasonably possible tune to before. Assume no rev limits etc. Assume that the engine is doing a burnout just outside the table bounds or anywhere changes are being made.
  • Normal mode, tweak an axis value/break point = don't touch the data, let the tuner do it. [default, non-feature feature]
  • Reshuffle axis values/break points within the bounds of the old table = look up the old table value, use as is. This COULD be better, but would be complicated to be better, and is correct in places and close elsewhere. [general shuffle feature]
  • Move end cell outside old table = extrapolate outward so as to maintain the same tune point [general shuffle feature]
  • Move end cell inside old table = look up the old table value, use as is. [general shuffle feature]
  • Add new axis cell outside old table = extend by using same values as old edge cells [general shuffle feature]
  • Add new axis cell inside old table between others = interpolate from each side which is the same as looking up the old table value and using as is. [general shuffle feature]
  • Combine two axis cells inside old table = interpolate old to create new - [explicit operation/feature]
  • Reshuffle axis values/break points outside the old table = extrapolate the first row that lands outside, match the rest to that. [general shuffle feature]
Note: "general shuffle feature" stuff should all use the same code; it's just expressed in various ways to aid understanding. Other options for filling new rows in the middle could be provided as explicit operations/features too.

This is still not perfect, but it's as close as you can get without hard coding knowledge about the table type into the handler. The emphasis here is on keeping things WITHIN the old tune as close as possible. Outside is, by definition, undefined. Thus what you do outside of the table must be from the perspective of maintaining the old tune, not trying to guess the new tune. The old tune, outside the table, was the same as the edge. Hence new row outside = use edge values. Using old values when moving an edge row would mean different tune to before in the middle. Using all zeros as suggested by Ben in IRC/AIM just now would result in interpolations between row before and new/moved row, and a lean condition/melted engine. To be fair, Ben wasn't thinking about tuning the top end of the table while I do a burnout in that zone. I am, though :-) Whatever the tuner does with the data should be "burnout in that zone" safe.

Image

The thing that could be better is to take "same as edge" and "extrapolated" and for VE/Lambda use the highest and for Ignition Timing use the lowest. This requires knowing what your data is, and that's taking things WAY too far. The down side with the above is that if the curve rolls over and turns down (on VE) then your outside value will be leaner than it was before. All inner values will match, though. Likewise if your timing is going up at the edge, outside will result in more advance than before, however inside will match before. The new data, though it should be close/usable by default, should be treated as untuned and untrusted.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply