According to my dissassembly 0% fuel trim is 128
Value is checked to be in range of (64, 192).
I guess these values mean +-10%

Therefore the value should be scaled
(x-128)/6.4 to give correct values.

Am I missing something?

 

+-10% was used by DSM loggers and early EvoScan versions: http://www.stealth316.com/2-fueltrims.htm but for later Mitsubishi check this http://www.aktivematrix.com/forum/viewtopic.php?t=126
Malibujack: "For Mitsulogger, the range is scaled to mirror OBD-II where 0% means no adjustment -25% is the maximum amount of fuel that can be removed, and +25 is the maximum added.."

 

I would understand if 64 and 192 would mirror some rational numbers (like +-10%,+-25%, +-50%), but what you are saying is that those values represent +-12.5% which I cannot understand how designer can come to such values.

Nevertheless it would make 12.5/64*x-25 = 0.1953125x-25
so some discrepancy is still there.

 

bump^

 

if 128 is the midpoint then 256 is the whole range. That makes 64 and 192 -25% and +25%.

 

You are wrong according to MalibuJack statement. its 0% +-25%, this means -25% is 0 and +25% is 256 therefore 64 is -12.5% and 192 is 12.5%, and I could not get how designer can take such values, but it seems that MalibuJack have chosen to be in conformance with OBDII protocol values, and this makes it understandable.

So the simple formula would be 25/128*x-25

I guess I have to add keyword EvoScan and Mitsulogger that evo4mad and MalibuJack look in.

 

Well I don't get it either...we'll have to assume that formula is correct then, but then my obdii loger gives me totally different trims(that I disregard) than Malibujacks formula.

 

The values should be almost same the intercept is the same and slope is sligthly different, supposing you have mitsulogger or evoscan formula.

 

Thats the funny thing about being stuck scaling values of 0-256 looking at the raw value of 128 being a perfect trim, the scaling is not "perfectly divisible" by the interval..

I chose to use the OBD-II scaling because that is what most people would be somewhat familiar with. PLUS, if you can get your trims within +/- 15% means your really close to having factory drivability in closed loop with OBD-II scaling. And since I only tune with Mitsulogger, I know its possible to get that close in most circumstances and conditions with as large as 1000cc injectors (even larger if I fiddled with the base injector latency along with scale and battery latency) 1600cc or larger if your using E85 or you have modified/replaced the resistor pack to compensate for impedence differences so you can get very low IDC's to allow a proper idle and fuel trim

 

15% ??? Why does everyone alway preach 5%?

 

Lately I have found that the same values are used in MUT and OBD communication so you can use the OBD scaling, and then it all makes sense. Boundary check is +-50%, the range +- 100%

100/128*(x-128)
or
0.78125*(x-128)

So now the values of OBDII logger and Mitsuloger/EvoScan should give same results.

I have to crosscheck Timing advance if the scaling is correct...
Then I will probably start a new thread

 

Because if you use the Evoscan/DSM scaling, that would be roughly the same thing..

However its nearly impossible to be "perfect", even on a stock car the trims may be as much as 15%, over 25% and the closed loop system can no longer adjust properly and just hunts. Take into account engine load, a/c, alternator, weather, fuel quality, and you'll always have some different value. The closer you can get to 0 the better, but it will vary throughout the year.

 

MalibuJack are you going to go open source with your Mitsulogger once the new UniLogger is out? I am getting some exceptions while logging, maybe I could fix them then.

 

No, unilogger will be replacing it completely. Unilogger has a programmer's API and plugin framework, and its modular so it will be easier to fix issues and allow users to contribute features.

FWIW the reason mitsulogger isn't open source is due to the options available to allow continued contribution. Its likely that portions (if not all of) Unilogger will itself be open-source and use subversion as a source control system for contributors.

Mitsulogger is written in VB.NET with some small portions being VB6. Unilogger is entirely C# and C++

 

The value send via OBD_PID_0E = 2*MUT_06 + 88
OBD_PID_0E is scaled x/2-64

Timing_Advance in range +-64 is then
Timing_Advance = (OBD_PID_0E)/2-64
with substitution
Timing_Advance = (2*MUT_06 + 88)/2-64
then
Timing_Advance = MUT_06 + 44 - 64
so
Timing_Advance = MUT_06 - 20
is correct