Hello all, one of my first posts here but I think I have done a lot of reading before hand so just looking for some clarification.

I can't find (easily, in layman terms) the relation between KFMIOP, KFMIRL and LDRXN.

I know they all affect each other and I think I've figured it out but would like to confirm. Below are my thoughts...

LDRXN - this is the absolute maximum, regardless what the other tables are set at, the boost (load) will not exceed this.

KFMIRL - this is possible requested load.

KFMIOP - this is the actual requested load from the driver as such. It appears to be a percentage.

So it goes like this example...

KFMIOP requests 92% (based on driver requested load/pedal pressure/something) of KFMIRL (210 / 100 * 92) = 193.2 which can be capped by LDRXN in the end.

So if LDRXN is set to a crazy number like 240, then still the max will be 193.2 = ~1.2bar (193.2 + 30 * 10), not taking into account any overboost/hardware issues on the car.

If we want more than 1.2bar then KFMIOP and/or KFMIRL need to be adjusted accordingly, another example...

KFMIOP requests 100% (based on driver requested load/pedal pressure/something) of KFMIRL = 210 which can be capped by LDRXN in the end. The max possible here would then be 210 rather than 193 (if LDRXN allows for this).

Am I on the right track? 

Kfmiop is the inverse of kfmirl. It is used for torque monitoring.

Kfped = requested torque %
Kfmirl takes the value from kfped and turns it into a requested torque value.
Kfmiop is used to monitor that value and should always be the inverse of kfmirl. Ie; @50%  kfmirl = 100 ---> @100 Kfmiop = 50%.

Me personally I use kfldhbn to limit my load. I set ldrxn to the highest load value I've tuned the car at. This way if I were to go down in altitude I wouldn't push the engine into higher untuned loads.

Ugh... Wat

That's way off. The purpose of kfmiop is not at all related to torque monitoring. If there's serious errors within kfmiop, there will be torque monitoring conditions met but kfmiop's job isn't too detect it. The purpose of kfmiop is to take a torque % and make it relative to load.

As far as using kfldhbn for a load cap, it doesn't cap load. It caps absolute pressure and doesn't care what altitude you're at. If you want to adjust how the ecu reacts to altitude changes look at BGPLGU module. There's also considerations for elevation specifically in LDRLMX. The ecu wasn't designed to use kfmirl as a load cap, that isn't it's purpose but if one were to use it that way, then I suppose moving ldrxn out of the way would work.

KFMIOP takes the max permissable load and translates it to max permissible torque. If this max torque allows desired torque to be too high, then torque intervention will be triggered. It is also used to calculate indicated torque from current load, which again, if too high will trigger torque intervention and corrected to optimum torque for other forms of intervention.

You are also all wrong about KFLDHBN. This map defines the max permissible pressure ratio, but is then multiplied by ambient pressure giving an absolute pressure. So yes, altitude is definitely a factor here. This absolute pressure is then translated to load and used to limit the max permissible load.

LDRXN is max DESIRED load, but desired load can exceed this because there are corrections that can raise the desired load limit. Also, actual load can exceed desired load.

KFMIRL is desired load, it is limited by the max desired load from %LDRLMX

KFMIOP translates load, actual and max desired, to a torque value for use in the torque model


This is correct for the most part, when you see inverse in the FR, it is an inverse relationship i.e. torque to load, load to torque or air mass to throttle angle, throttle angle to air mass.

Why does everyone act like it's one or the other?

Everything works together

Depends on what load limitations are more important to you. For stock, since there is a ton of headroom in the boost, the IAT corrections make sense.. higher temps, more boost to keep the driver experience consistent... but running near the compressor limits is more common in tuned files, so HBN makes more sense as the "usual" limiter. That said, get hot enough, you still want LDRXN to intervene via KFTARX.. but in this case, REDUCE requested boost on high IAT, and maybe even increase requested boost on low IAT.

That is to say, stock, generally LDRXN limits boost more often than HBN... but IMO that approach does not make sense if you want to run at or near the compressor map limits.

In a performance based tune, you may want the opposite. It obviously isn't about choosing one or the other (absolutely), and never using the other.


IIRC VVT correction (like IAT correction) is in fupsrl, which cancels itself out in the HBN->load->boost path.

I could be wrong.

IIRC fupsrl is used to convert HBN to desired load limit... then back again.. so any corrections in fupsrl (VE, including VVT corrections) get canceled out. Lets put it this way: why should VE be relevant to compressor limits?

If vvt correstions aren't in fupsrl, then you are right, of course.

I don't know of any other ways to limit req load (or boost) dependent on ambient pressure... please elaborate?

Also, this isn't outlook. Ditch the top replies ;P