jcsbanks

I've spent the last month or so (it is quite complex with thousands of lines of code) disassembling the routines that link the measurement of MAF pulses all the way through to the injector pulse, along with the important compensations (glossing over errors, closed loop and coolant stuff). Here is an outline.

Crank angle sensor (CAS) interrupt (vector 1C8) calls a routine that has been called MAFLONG. This measures the number of pulses per CAS and multiplies by 9C. A fractional part is calculated to improve accuracy and based on the time between pulses. Various checks and rates of change are calculated. There is a filter that works like a moving average (like the knock sensor stuff described before). Two important variables are calculated:

MAFSOURCEMAIN - multiplied by MAF size to calculate the LOAD, from which there are baro, temp and baro+temp compensated versions calculated which are used to lookup the maps.
MAFSOURCEMAINxMAFMULTIPWARMUP - which is later used to calculate IPW.

(MAFMULTIPWARMUP is based on coolant temperature, moderated by load so it has little effect at high load).

Both of these are limited based on calculated values- so far I've posted how to remove the limiter for MAFSOURCEMAIN which allows loads over 380 to be looked up. However, we also need to sort the limiter for MAFSOURCEMAINxMAFMULTIPWARMUP to complete the delimiting. I'll look into the maximum values before overflow soon.

There are also replacement values for MAFSOURCEMAIN for errors that are calculated based on:
MAP, MAT, IAT (at least on my IX JDM - MDPHERE is the routine, this is what we can use for speed density)
Baro, RPM, TPS

Still in this busy CAS interrupt, we eventually make a calculation that forms a precursor to IPW:
MUTC7 * O2Feedback * MAFSOURCEMAINxMAFMULTIPWARMUP +- accel enrichments + Injector deadtime

MUTC7 is not loggable as it is beyond the MUTBF end of the MUT table, but it is calculated from the main engine control loop (not in CAS interrupt), but in FU_MAF_OTHER:
Lean spool and fuel maps lookup to give AFRMAP
AIRFLOW=MAFSOURCEMAIN/TIMEBETWEENCASPULSES, used to lookup MAFSCALING, MAFSMOOTHING, TEMPBAROAIRFLOWLOOKUP to give MAFsmthsclgfactorxINJSCALING
MUTC7=MAFsmthsclgfactorxINJSCALING * AIRTEMPDENS * BARO * WARMUPCOUNTER * COOLANTTRIM * MAFMULTIPWARMUP * LOADBASEDMAFMULT * AFRMAP (and a few other compensations that seem unimportant)

The calculated value is delivered to the injectors by complex interrupt handlers that deal with all the scheduling.

In summary IPW is calculated from:
AFRMAP*AIRTEMP*BARO*MAFSCALING*MAFSMTHG*TEMPBAROAI RFLOWLKUP*INJSCALING*MAFSOURCEMAINxMAFMULTIPWARMUP

(* WARMUP*COOLANT*MAFMULTIPWARMUPxLOADBASEDMULT*O2FEE DBACK)
+ accel1 - accel 2 (still to be fully worked out)
+INJDEADTIMELOOKUP*INJLAGRES

Questions?

Magnumpsi

iTrader: (2)

You are an animal lol.

Mitch

tephra

iTrader: (6)

wowzers nice work... I KNOW how much of a PITA that stuff is... looks like you worked out the ATU stuff huh?

So IPW is based of AIRTEMP, is that scaled/tabled from somewhere?

l2r99gst

iTrader: (2)

Nice info, John.

MR Turco

iTrader: (16)

:headexplodes: Great work, i just wish i knew what it meant. I need to read again, for the 4th time.

jcsbanks

It is the same variable that is used to calculate temperature corrected load that you've dealt with before.

Yes, ATU stuff is reasonably cracked now, most of it reduces to what I've posted. I've been trying to track all the potential issues we might see with speed density or crazy MAF conversions.

What I didn't mention is that there is loads of code devoted to other calculation and IPW settings involved in what I think will be for batch fire injection for asynchronous acceleration enrichment and cranking. I'd tried to reduce my understanding and explanation to the normal open loop case as that is what we are interested in for performance applications.

C6C6CH3vo

iTrader: (9)

So does this mean with non OBDII (0..5v) air temp and baro sensor logging, real time MAF hz and rpm logging, with only AFRMAP from MUT, that it might be possible to accurately calculate load with one very long math equation that includes the MAF's scaling, smoothing, and size on LW's? Byte load logs are erratic and untimely for me using LW's which is why I ask.

Your the man by the way JSC

sub7

Am excited to see futher development in this area

merlin.oz

Super impressive John.

Was there any kind of injector phasing table/map associated with this that you could see?
Or any clue as to when the injectors were fired?

Oh, and might we see a good description of accel enrichment soon?
The E85 guys could probably use that to good effect.

evoredy

iTrader: (7)

badass man. i knew there was replacement MAFSOURCES as thats what bez's code replaces. it exists in the usdm renditions. some modifying is needed, but not to the calcs to port over the code.

i still have yet to post the 015 and 006 stuff, i'll get to it. what you said [for SD] is exactly what bez's patch does on the USDM-like roms. some modifying was needed to his original 006 code as it never "hooked" for some reason. i went through all of this a while ago, but my intent was to only port the code over and not travel the MAF to IPW yellow brick of hell road heh. i did name all that stuff in my 015 and 006 disams according to bez's finds.

all in all good stuff and i wish there were more hours in the day.

mrfred

iTrader: (50)

Nice work John. Since you've been through it now, my first though besides SD conversion is whether there are any new tables or constants that are worth having in the tuning arsenal for a stock MAF-based Evo.

jcsbanks

Not really any of interest mrfred, they have already been well discussed by you and others, perhaps we can tighten up on acceleration enrichment and coolant/timer based compensations. The main calculations work pretty much as you would expect with the compensations being divided (often by 0x80) to normalise them and then all multiplied together, producing lots of intermediate variables that are copied and recycled etc. It took some finding to realise that load was never a multiplier in the IPW calc, but it was just a lookup for the tables, and that the MAFSOURCEMAINxMAFMULTIPWARMUP was copied and then after lots of bit flag testing, used in the "normal" case. What is surprising is the amount of code processed in interrupts.

merlin.oz, no injector timing tables found, I think it is hard coded to use a fixed start or end point relative to CAS and a 500kHz timer. I tracked through to the point where the IPW variable we log using MUT is formed, going further would cause brain meltdown, it is not friendly code. There is promise to work on the accel enrichment given that we have lots of candidate tables and the code that processes them to tidy up (much the same with the coolant/timer stuff).

C6, in the error free, warmed up car that isn't having an acceleration transient it might well be possible.

03whitegsr

iTrader: (8)

In my XML files, I have a table labeled "MAF Sensor Filtering" that has two values that corespond to low and high load conditions. (217 and 192 respectively)

Are these values used and what affect do they have?

For 94170015 the address of these variables starts at 1508.

jcsbanks

The values control an exponential filter. At 192 the filter is a sort of running average of the last four MAF readings.

cossie1

Just 2


1) DO YOU SPEAK ENGLISH ?

2) How much closer does this bring you / us to getting an SD patch out there ?