You may end up with negative results as a result of other conditions and maps

As an example, a turbo will see much higher IATs than NA, you can counter the negative impact on load, which further impacts timing map load point selections etc by altering the IAT load map

There are a whole series of maps and their cell inputs that determine the final output value

 

no, is it publicly available?

 

Let me ask one last question of MM...

If i were to set the fuel table up so that there were columns for say 250% load ,would the ECU ever be able to reference those numbers for its fuelling calculation?

Assuming all comp. multiplier tables were set to 1 (eg , IAT and baro)

A simple yes or no answer will do ......

 

without using the wrong terms....
What you want to accomplish is.

97.5 percent CalcLOAD should equal about 50 percent ACTUAL load.

And 195 Calc load, should be the MAX ACTUAL load. because you've setup your tune in away that you can't go over 195, you can't go measuring off your ruler, because you've stretched your ruler just long enough to cover the range you're going to run.

your 100 percent load, may be at 2 or 3 psi, depending on a particular setup.

IF you then say, change out turbos, and your engine puts out higher FLOW/power, You would want to/have to retune, and restretch your ruler so that your new setup is in the range of your tune...

Thats how i see it at least.

 

http://obdcon.sourceforge.net/2010/0...ed-load-value/

 

hmmmmm ....

http://www.cobbtuning.com/info/?ID=5323

 

+1 hmmmmm


So I checked my version of ATR and I'm at 1.8.0.0-11359

Can't wait to get the link to the new ATR package.

 

hmm

 

if you are refering to that link team put up. that's not for the rx8.

1.8.0.0-11359 is the latest ATR version for us.

 

There's a whole lotta hmmmm.......ing going on in this thread . heh

 

Slightly different problem (because of the way the L3-VDT programming was handled by Mazda), but it still speaks to the problem that has arisen because of the "blurring" of AbsLOAD and CalcLOAD by Cobb.

Remember - the L3-VDT (MZR Turbo) has torque targets as part of the programming. This is a variation on how the Subies are programmed.
The MSP does NOT have this because the PCM is an NA application.

 

mmm-hmmm ....

 

This is a critical parameter for higher HP applications due to the fact that the ECU is not able to properly calculate fuel requirements when demand exceeds the load cap. If the load cap is set too low, a lean condition occurs, getting worse as the delta of actual load goes further beyond the load cap.

MMMMMMMM

 

The MSP PCM has no "fuel cap" because it isn't a torque-target system.
That makes it, for our purposes, a better PCM for FI than the L3-VDT (MZR Turbo) PCM for this very reason. It has no inherent, mathematical cap to the AbsLOAD calculation (up to the end of the MAF limit).

The PCM will "run off the edge of the map" since it has no constraints.
This is why I am trying to get you guys to wrap your head around the "CalcLOAD limiter" problem rather than just giving some single-sentence answer that, ultimately, wouldn't be an answer as soon as something else changed in the calibration.

 

So what you do with the calx load max table is move the virtual page around on the big global picure depending on how the other variables are configured?

 

Essentially, though you aren't moving the page, you are just changing the size of the paper.

 

So what happens if the page is too small or big?

 

If it is too small,you simply don't get to see the rest of the information and the resulting "error" is reported as a hole in the tuning, even though the information still exists.

If it is too big, the information is written in bigger letters to fill the page.

The page always must be completely filled to get reports that conform to the actual data.

 

So instead of a tuning issue this shows up in how the logs look? And if wrong limits your information in the missing areas......

 

Well, not exactly.
There is a tuning issue, but it has to do with how CAlcLOAD is applied to the maps that use it as an axis.

The main point is that it doesn't behave as a "limiter" as some were suggesting.

 

So does it imput incorrect data?....just trying to wrap my head around this too

 

So can someone tell me if this is the correct formula for Calculated load:

Calculated Load = [current airflow] / [(peak airflow at WOT@STP as a function of rpm) * (BARO/29.92) * SQRT(298/(AAT+273))]

STP = Standard Temperature and Pressure = 25 °C, 29.92 in Hg BARO
SQRT = square root
WOT = wide open throttle
AAT = Ambient Air Temperature and is in °C

If this IS correct then then there are 2 variables other than those listed above. The first is "current airflow" and I assume is the reading from the MAF, but the second "peak airflow at WOT@STP as a function of rpm", where does this come from? Surely its a table somewhere?

Cheers

Andrew

 

Had a cold front come through and I rocketed right through the roof on my NA load table. The tune went lean in some areas, others not. Not sure why, so I'm building a different tune to test out some ideas on alternate configuration methods.

 

IAT and BARO compensation.

 

perhaps, but I need to work it through for my own educational experience. I played with those before when it was uber-high temps and the system seemed to override my settings