djd24

Does anyone know the mathmatical formula that the ecu uses to calculate the load %? I know it uses many factors such as speed, boost, etc, but I am interested in the exact method the ecu uses to arrive at a certain load %.

Dapper Dan

iTrader: (28)

not sure exactly but this might help you.....it helped me



I finally made a few logs today and wanted to try to take a stab at the load formula. I know from my DSMLink experience that it is mainly based off of mass airflow/revolution, along with a few other variables that can change it slightly.

So, looking at my Evoscan logs with the logreader, I came up with this equation which seems to work pretty decently for my car. Maybe a few of you can test it out and see what you come up with:

Load = Maf Hz/ Engine RPM * some variable(s)

For my car I used the "some variable(s)" as a constant of 852, based on a few quick calculations.

So, for example in one of my logs, I was at 1308Hz at 4656 RPM (right at the end of a spoolup after going WOT in 2nd), and my EvoScan log showed timing as 2*.

So, 1308/4656*852=239 So, looking at the 240 load column in my stock map at 4500RPM, the timing value is 2. So that checks out.

Using one more data point: A different run at the top of third I had 1585Hz at 6781 RPM, and the log showed 17* timing.

1585/6781*852=199 So, in the 200 load column in my stock map at 6500, it is 15* timing and at 7000 it is 18* timing. So, 17* checks out there, too.


Obviously, this isn't an exact forumula since I used a constant where I know there are variables, but I think this may help a few people out to get an idea of what there load number is. I know someone already posted how to find what load column you are in, but if this load forumla checks out and you find a constant that seems to work on your setup, you can use the forumla to calculate what load column you are in when you are knocking and how much timing is being pulled as a result.


Eric

A418t81

iTrader: (5)

That system works well until you peg the 1609 hz limit on the ECU output which on my car basically happens when the turbo completely spools (usually around 5k, add a touch longer in 1st and 2nd).

chrisw

iTrader: (2)

https://www.evolutionm.net/forums/sh...d.php?t=220966

There are many many thread discussing this topic. I would suggest searching. The most "accurate" load calculation is discussed in the thread posted here.

djd24

I recently had my ecu flashed by a local tuner with the EcuFlash program. I wanted to see what was going on with my fuel curve, so I copied the data points off the program, pasted them into Excel, and modeled a 3D graph based off the data. Here is what I got:





On the road, my fuel seems to be fine. I'm running fairly consisten afrs of 11.0-11.7. But my question is, why do the afrs in the above graph change so much with respect to load? Shouldn't the afrs be conistent across the load parameters once under full boost? Wouldn't a graph such as the one below with smoother, more consitent afrs be more desireable?





Thanks for any input. Sorry if these questions are dumb...tryin to learn.

chrisw

iTrader: (2)

summarizing what I have learned off this forum, I think it goes like this...

The actual AFR target is a calculated value that is generated by looking at the octane number, knock count, and a few other variables that I can't remember off the top of my head.
If the octane number stays the same or increases in value, then you are using the high octane map exclusively. If the combination of knock counts and octane is right, then the ECU switches to use a value determined by the average between the high and low maps. If the octane number is super low, then you are using the low octane map.

The peaks and valleys in the 3d Map (really cool BTW) just show where you need to run richer or leaner depending on the engine (and the mods you have done) in order to meet the desired AFR.

make sense?

djd24

So are you saying that a graph that is closer to the 2nd graph would be more desireable (for a high octane map)? That just seems too easy...that means the afrs should basically be just a flat line all across the board (with the exception of the lower-load cruising afrs).

nothere

iTrader: (23)

. agree with chrisw

nothere

iTrader: (23)

nevermind

chrisw

iTrader: (2)

no, that is not what I am saying. The 1st map just reflects the peaks and valleys that allow the engine to maintain what the ECU has determined to be the correct AFR for the given load.

I would not run the second graph at all.

djd24

I see. Thanks.

But why, for example, would the ecu determine that an afr of 9.0 is correct at any load level (as in the first graph)?

nothere

iTrader: (23)

if I understand it correctly

the graph is not the target afr, it is the desired correction to achieve the right afr.

djd24

So you are saying that the values listed in the high octane fuel map that are sent to the ecu through the EcuFlash program are not target afrs, but instead desired corrections?

Actually, that would make much more sense if that was the case.

AutoXer

iTrader: (1)

The AFR numbers in the fuel tables are really just "something to go by". In open loop fueling, the ECU doesn't really care what AFR it is really running. It just looks up a value in the table, does a little bit of math with the value pulled from the table(0-255), the injector scaling, injector latency and probably some others... then sprays the correct amount of fuel into the intake manifold. The ECU has no way to check to see if the AFR is hitting the "target". We have to monitor the AFR value with a wideband to see if we need to make the numbers in the fuel tables lower or higher. The linearity of the MAS and the Volumetric Efficiency of the engine varies with RPM and Load. That's why the maps can, and usually will, be a little bumpy.

Cliff Notes: The numbers in the maps are scaled. The actual numbers stored in the ECU range from 0-255. The scaling is (x/128)*14.7. Some users set the scaling to show just the raw 0-255 number because the AFR number(0-29.4) shown in the tables really don't mean anything.

...that make any sense?

djd24

Yes, that makes perfect sense. Thank you.