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.
Future Tuning Software User Feature Wish List (UI stuff)
Re: Future Tuning Software User Feature Wish List (UI stuff)
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!
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!
Re: Future Tuning Software User Feature Wish List (UI stuff)
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.
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.
Re: Future Tuning Software User Feature Wish List (UI stuff)
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.
Re: Future Tuning Software User Feature Wish List (UI stuff)
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!
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!
Re: Future Tuning Software User Feature Wish List (UI stuff)
Correct, FreeEMS has many aux circuits. It's unlikely one will need to use an injector channel.
Re: Future Tuning Software User Feature Wish List (UI stuff)
http://www.gotech.co.za/productprox.html
Some interface ideas there. That ECU is fairly poor in many ways, though.
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!
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!
Re: Future Tuning Software User Feature Wish List (UI stuff)
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.
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.
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.
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]
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.
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!
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!