Disassembly: MAF tables and Air Flow Calculation

[Greg E]

Try to let go of the notion that the stock MAF is some intelligent air counter and try to think of it more in the terms of any 5V sensor. There's a voltage and a scaling (the ECU associates the input pulses to some amount of air). Granted it's not a linear varying voltage signal like a wideband O2 sensor or a MAP sensor, but it's still a 5V pulse signal sent to the ECU. The faster the pulses, the more air.

The MAF sensor can only read air volume. Dennis has a great explanation for how the mitsu MAFs work.


The Mitsu Karmann air flow sensor is a volume sensor - so you are right in saying "it'll show the exact same pulses for 70deg air as it does for 110 deg air" because (assuming all other conditions are equal) the volume of flow is the same. What changes with the temperature change is the density, and with it, the mass.

So the Mitsu "MAF" must be temperature and baro pressure compensated in order to produce a mass value, which is what we want. And by no small coincidence, the sensor has a baro pressure and air temp sensor in the body of the "MAF".

Hot wire sensors - like the GM sensor - use an entirely different measuring system (the amount of cooling on a heated wire) and these sensors measure air mass directly with no need to temperature or pressure compensate (at least on paper - I would not be surprised to find out that GM ECUs use some "fudge factors" to cover for where theory diverges from practice)

Knowing the volume doesn't get you anywhere, since the number of air molecules in a given volume changes with temperature and pressure. If you know air volume, temperature and pressure though, you can get air mass. Air Mass can be used to determine the correct amount of fuel

This is one of the reasons for the closed loop feature of the ECU. Even with all the tables used to calculate air mass, your final number is only as good as the base number. Even a completely stock, perfect condition car will have varying fuel trims depending on the weather outside. You'll never ever have a perfect 0% trim under all weather conditions.


The trims are less about weather as they are about engine wear and general chaos (in the mathematical sense). Remember that the reasoning behind closed loop fuel control is emissions. The manufacturers were forced to go closed-loop-control by increasingly tighter emissions standards over increasingly longer periods of time. As engines wear, build up carbon, spark plugs get weaker, injectors clog etc the calibration changes (slightly) and your emissions change accordingly. Closed loop allows the ECU to compensate for these drifts away from the mechanical state of the engine as it was delivered from the factory.

Closed loop will also accomodate errors in your weather-related tables as well (and for tuners, your fuel tables) which is why I cheat like a bastard and run closed loop with a low lean-out authority and a high enrichen authority all the time (with a pair of wideband sensors), tweaking fuel tables to try and minimize the amount of O2 correction. The OEM, with a narrow band O2, can't cheat like this except on cells where it is supposed to be 14.7:1 so the weather based corrections are probably very good (thus the reason why I want to duplicate them)

So how does the ECU calculate airflow? It starts with the MAF Size and the MAF Pulses. The larger the MAF size number, the more air the MAF can count (in the code, you must set this value according to the MAF you're actually running)

AirCount = MAF Pulses Per RPM
MAF Hz = MAF Pulses Per Second = AirCount/RPM

Load is the term used for years as a number value to show how much air volume there is. More Load = More HP. So the object of the game is to get as much airflow in the motor as possible. ;)

Load quite simply is just Air_Count * MAF_Size / 65536. This is uncompensated Load (meaning Air Temp and Baro haven't been applied yet).

Being able to read this number accurately is advantageous over the traditional boost gauge/butt dyno as you're able to see if your airflow numbers go up with each mod performed. When you get to the point where you keep raising the boost, but airflow isn't increasing, then you hit the limit of the efficiency of your turbos on your particular setup.


Caution! There's a MAF Pulse Limitation in the code. This isn't a physical limitation of the MAF itself, just an issue where the ECU will stop adding fuel past a certain PPS (Pulse per second) due to a 1 byte limitation in memory. Beyond this limitation, the ECU will stop adding fuel so be forewarned.

This limitation is 13.06 PPS or 319.7 grams of air/second (table is shown in the V2 xml). With a stock MAF, this is only about 450hp depending on which HP calculator you're using. This is coincidentally is about where the stock 3/S MAF also seems to run out of resolution. Thought that was interesting. Obviously the car is capable of making more power as people have been doing so for years by fooling the ECU into seeing less air with a piggyback.

I'm not sure what this limitation is with an EVO MAF yet. The EVO MAF won't pulse as often for the same airflow as the stock 3/S MAF and I need more data to make an educated guess. Wouldn't be surprised if the limitation is double the stock 3/S MAF. If the demand requires I come up with a way around this limitation, I can, but for now, I'm not going to worry about it till we start seeing more big builds with the Flash ECU.

AirFlowMAX = MAFLimit * AirTempComp * WaterTempComp

*Note: These 2 comp tables are only used for calculating MAX airflow NOT engine load. Also note they are just set to 1 so they are disabled anyway.

http://i.imgur.com/avWVc.jpg



So that's airflow. Next the ECU calculates a MAF Correction value for the injectors during the IPW calculation. It does this using the MAF Scaling, Adder and VE tables. The MAF Smoothing table is just a way to measure the engines Volumetric Efficiency (VE).

http://i.imgur.com/1UdfZ.jpg



Changes to MAF Smoothing (VE) Table will produce large results relative to the value in the Scaling Table. So if you need to adjust the amount of fuel based on airflow, adjust the values in the VE table. It's kinda like an SAFC in a way only you're going off the actual MAF values instead of RPM. The higher the number in the VE table, the more fuel the ECU will use. Lower values = Less fuel.

It's important to note that changes to your intake, innercoolers exhaust, head work, turbos... All this changes your particular engines VE and the MAF may not detect this change in airflow. This table is tuned for a 100% stock car. Something as simple as hard pre-turbo intake pipes can effect the readings from the MAF as more can sneak thru it without being detected.

When tuning cars, I don't mess with the fuel injector size and latency values beyond setting up the values for whatever injectors is being used. Most people also tend to want to play with the fuel table too much during initial tuning, but if you get your VE table setup just right, the AFR value you see in the fuel table is what you'll get on the wideband.

The fuel trims are handy for tuning this table. If your trims are increasing, add more to the VE table in that range to bring them back to 0. If your trims are negative, lower the numbers.


http://i.imgur.com/DsNLk.jpg

Something interesting in the code is an idle correction factor during it's airflow calc process. Since at idle vacuum is so great, it causes an anomaly with the idle AFR in that the ECU will think there's a lot more air there than what's actually flowing thru the MAF. This correction is based off the idle switch and it works to differentiate the low fuel trim between idle and just low speed driving.

When you install cams and vac is a lot less than stock, consider bringing up this idle correction factor a bit as it may cause too lean of an idle mixture (not that a lean idle is really is a bad thing).

[Greg E]

When you install an EVO MAF, these are the settings you need to make your tables. Leave everything else alone.

http://i.imgur.com/laCsg.jpg

[Zybrainn]

Just to clarify if we are using an EVO MAF, the maf scaling table (V1 table name) should change to the values you listed from the airflow/hz raw scale table (guessing V2 table name) to the right?

[Greg E]

MAF scaling is the chrome V1 and V2 name.

The raw scaling name is what the EVO guys called it in their ROMs. Those 3 tables on the right are straight out of my old EVO 8 stock ROM.

...and if you have an EVO ROM (even a tephra one) you can just copy/paste all the values instead of manually typing in each one.

[Chris@Rvengeperformance]

I guess that is why my car has to add fuel at idle, I'm still using the 3/s scaling. Hopefully I can try this out over the weekend. It is good I had a chance to dial in the injector scaling and the airflow table while I'm still on the stock fuel pump. The FPR overrun I'll get later would lead me to the wrong numbers.

I take it there is hope for a voltage to grams scaling someday? That beast 3.75" draw through maf I had would sure be nice.

[Greg E]

Grams/ second scaling (instead of load) is already in the ROM. I was curious if anyone used it. It's a sinple matter of editing the table and selecting the g/sec scaling.

If you'd like to experiment with the GM MAF I'll send you the special ROM I've been working on which utilizes a linear 5V signal for the MAF input instead of the HZ signal like the Mitsubishi MAFs.

Believe you and Adam are my only beta testers still in the game during the winter.

[Chris@Rvengeperformance]

Grams/ second scaling (instead of load) is already in the ROM. I was curious if anyone used it. It's a sinple matter of editing the table and selecting the g/sec scaling.

If you'd like to experiment with the GM MAF I'll send you the special ROM I've been working on which utilizes a linear 5V signal for the MAF input instead of the HZ signal like the Mitsubishi MAFs.

Believe you and Adam are my only beta testers still in the game during the winter.

Sure I can test the GM maf. Let me get the few kinks worked out we talked about and we can go from there. I don't need a solid tune until the NG next year, so I have time to iron it out.

I'll keep my eye out for a z06 maf. I guess you have some preliminary scalings setup for some mafs? GM publishes some decent info don't they?

I guess there are other methods of obtaining a 5v signal, aren't there ;) ? I assume it is not quite as simple though, so we can start simple.

FYI, the part # I ran before was 25168491, if there is no objections I'll get one of those again. Not interested in blow through.

[DG]

As is my usual practice, the summer ends and I start driving my car again. And once again, I start noticing the more ragged edges of my current AEM EMS tune, and start wishing I had the OEM ECU calibration translated into an AEM EMS calibration so I could leverage all the tuning work Mitsu did when they first developed the friggin' thing.

So I'm happy to see the OEM ECU disassembly stuff moving forward. Who knows, maybe this time I'll actually get it done.

Ok then, sooooo.....


The MAF sensor can only read absolute airflow, not relative (or also called Atmospheric) meaning it'll show the exact same pulses for 70deg air as it does for 110 deg air. Same with barometric pressure. This is one of the major advantages to using a ford or GM hotwire MAF. They measure air volume so your base signal is already compensated for atmosphere.

Not exactly.

The Mitsu Karmann air flow sensor is a volume sensor - so you are right in saying "it'll show the exact same pulses for 70deg air as it does for 110 deg air" because (assuming all other conditions are equal) the volume of flow is the same. What changes with the temperature change is the density, and with it, the mass.

So the Mitsu "MAF" must be temperature and baro pressure compensated in order to produce a mass value, which is what we want. And by no small coincidence, the sensor has a baro pressure and air temp sensor in the body of the "MAF".

Hot wire sensors - like the GM sensor - use an entirely different measuring system (the amount of cooling on a heated wire) and these sensors measure air mass directly with no need to temperature or pressure compensate (at least on paper - I would not be surprised to find out that GM ECUs use some "fudge factors" to cover for where theory diverges from practice)


Even a completely stock, perfect condition car will have varying fuel trims depending on the weather outside.

The trims are less about weather as they are about engine wear and general chaos (in the mathematical sense). Remember that the reasoning behind closed loop fuel control is emissions. The manufacturers were forced to go closed-loop-control by increasingly tighter emissions standards over increasingly longer periods of time. As engines wear, build up carbon, spark plugs get weaker, injectors clog etc the calibration changes (slightly) and your emissions change accordingly. Closed loop allows the ECU to compensate for these drifts away from the mechanical state of the engine as it was delivered from the factory.

Closed loop will also accomodate errors in your weather-related tables as well (and for tuners, your fuel tables) which is why I cheat like a bastard and run closed loop with a low lean-out authority and a high enrichen authority all the time (with a pair of wideband sensors), tweaking fuel tables to try and minimize the amount of O2 correction. The OEM, with a narrow band O2, can't cheat like this except on cells where it is supposed to be 14.7:1 so the weather based corrections are probably very good (thus the reason why I want to duplicate them)


Something as simple as hard pre-turbo intake pipes can effect the readings from the MAF as more can sneak thru it without being detected.

I've never seen anything that suggests that the "MAF" is anything other than perfectly accurate for its calibrated range. It should not be possible, assuming you aren't exceeding the flow limit, to "sneak air through the MAF" without it going uncounted.

What is more likely is that this really is a VE correction. The "MAF" is a volume sensor, and it sits at the head of a very long and convoluted airflow path. Due to flow efficiancies along that path, somewhat less air will arrive at the engine than was counted at the sensor - and even that isn't quite right. As long as air is not being lost (via a vacuum leak) the same mass of air is making it in, but the volume and density are being tweaked a little by flow losses.

Change the flow efficiency of this flow path into the engine and you change the amount of divergence between what is measured at the entry to the pipe and what comes out at the end of the pipe - that's the change in VE. And VE is indeed sensitive to things like hard pipes.

What I have noticed sort of emperically though is that the Mitsu "MAF" is very much less sensitive to VE changes than is a pure speed/density system (which implies volume flow rather than measuring it). The fuel maps still have a curve to them, but not much of one - and the very narrow range of that "MAF Smoothing" table bears that out. To the point where I wonder if it isn't so much about VE as it is about nonlinearity in the response curve of the sensor.

I'd give a testicle to see a 3S MAF and an EVO MAF hooked up to a flow bench (where flow volume is carefully controlled) and see the results of a stepped flow test, where sensor output Hz is plotted against known flow.

Greg, I also wish you and I could spend some time together in a room with a whiteboard... it would be SO much easier to do this in person.

DG

[Greg E]

I've never seen anything that suggests that the "MAF" is anything other than perfectly accurate for its calibrated range. It should not be possible, assuming you aren't exceeding the flow limit, to "sneak air through the MAF" without it going uncounted.

What is more likely is that this really is a VE correction. The "MAF" is a volume sensor, and it sits at the head of a very long and convoluted airflow path. Due to flow efficiancies along that path, somewhat less air will arrive at the engine than was counted at the sensor - and even that isn't quite right. As long as air is not being lost (via a vacuum leak) the same mass of air is making it in, but the volume and density are being tweaked a little by flow losses.

Change the flow efficiency of this flow path into the engine and you change the amount of divergence between what is measured at the entry to the pipe and what comes out at the end of the pipe - that's the change in VE. And VE is indeed sensitive to things like hard pipes.

What I have noticed sort of emperically though is that the Mitsu "MAF" is very much less sensitive to VE changes than is a pure speed/density system (which implies volume flow rather than measuring it). The fuel maps still have a curve to them, but not much of one - and the very narrow range of that "MAF Smoothing" table bears that out. To the point where I wonder if it isn't so much about VE as it is about nonlinearity in the response curve of the sensor.

I'd give a testicle to see a 3S MAF and an EVO MAF hooked up to a flow bench (where flow volume is carefully controlled) and see the results of a stepped flow test, where sensor output Hz is plotted against known flow.

Greg, I also wish you and I could spend some time together in a room with a whiteboard... it would be SO much easier to do this in person.

DG

Hey Dennis! Was hoping you'd come out of hiding and find my posts! You're one of the guys whom I am gearing this whole project towards. :)

You're right. I should edit my posts to be more clear about the difference between mass and volume. If you don't mind, I'd like to steal a few of your words from this post and move it up top.

If I didn't witness the direct changes in the fuel trims from swapping on different intake pipes, I would agree with your statement but time and time again the MAF needs to be rescaled for different intakes, exhausts, turbos... That's where the "air sneaking thru the MAF" statement comes from.

Remember the stock MAF has chambers divided up and only the vortex generator sits in the middle chamber. This means there is a lot of uncounted air going thru the other chambers at any given time.

While I've never had the equipment to measure the stock and EVO MAF side by side, its known that the stock MAF will pulse more times a second than the EVO for the same amount of air. This is the purpose of the single cell MAF size value. This number tells the code how much air flows thru the MAF for each individual pulse. This is why you need to set the size value to be so much bigger than stock for the EVO MAF.

Further evidence to support this comes from comparing my stock 98 readings to a few modded cars. Jesters 99 is a good example. He's running a montero MAF (very similar to the EVO MAF, the settings are close enough between the two). Adam is running 19Ts at 19ish PSI.

Comparing his logs to mine, the stock car shows about 220 load at 16psi vs 205 LOAD on Adams car. There is absolutely no way his car is flowing less air than mine. Looking at his raw HZ readings, they are also lower than my car. Why? Because the montero MAF doesn't pulse as much for the same amount of air.

I see this time and time again so I swapped the EVO MAF onto my stock car. Just as i suspected, lower HZ and load numbers. 160 load vs 220 with the same exact tune on the same exact day on the same exact stretch of road.

Something that will really blow your mind is I don't believe the MAF itself is a restriction like we are all accustomed to believing. In the code, there is a 1 byte limitation to the MAF signal at about 319 pulses per RPM. Without going into too much detail with the math (though I can if you'd like), this comes about 450hp. Now, that number about where people have been running out of power with the stock MAF. What happens is past 319 pulses per RPM the ECU just stops adding fuel as it doesn't see any more pulses past that limit. Air keeps coming in but the numbers are beyond max so the AFR just leans out.

I'd be willing to bet you if I increased this limit, we could get more power out of a stock MAF. Obviously this depends on sensor latency/accuracy past that point. Then of course there is the conundrum of breathing thru a straw but that's left to be seen.

Dennis, I would love to chat more ideas like this with you. I do this all the time with a few guys while I'm bored at work. Do you have my email?

[DG]

If you don't mind, I'd like to steal a few of your words from this post and move it up top.

Go ahead.


but time and time again the MAF needs to be rescaled for different intakes, exhausts, turbos

That makes sense though if what the "scale factor" is, is a VE factor. Changing the efficiency of the flow path behind the sensor is going to alter the relationship between air measured at the front of the pipe and air "measured" (by the calibration) at the end of the pipe. I'd bet, for example, that if you moved the MAF to right before the throttle body, you could change intake piping all you wanted without needing to rescale the MAF - because changes upstream of the sensor get measured by the sensor.

Similarly, I expect that changing air filter designs doesn't require MAF rescaling either.

My experience though with the AEM in MAF mode is that the MAF is very insensitive to VE changes, whereas the Talon (which was an AEM in speed/density mode) was very sensitive to VE - one of the reasons I retained the MAF for my Stealth.


Remember the stock MAF has chambers divided up and only the vortex generator sits in the middle chamber. This means there is a lot of uncounted air going thru the other chambers at any given time.

True, but the ratio of counted to uncounted is proportional and fixed. It would be quite the trick convince air to flow through the unmetered portion without a proportional amount flowing through the metered section.

The old "hacked MAF" from back in the early days of 1G DSM tuning was about changing the ratio of metered vs unmetered air, not so much about increasing the raw flow value.


its known that the stock MAF will pulse more times a second than the EVO for the same amount of air.

This is entirely possible, but is a separate issue - that's a difference in the calibration of two separate sensors, not a question of the sensor not counting air passing through it.

If you are using a frequency or count-based air sensor, there is going to be a maximum frequency over which your count window will be too short to catch all the pulses. It makes sense, then, to design the MAF so that the maximum amount of air you intend to be able to count generates this frequency, or a little lower to give you some wiggle room. Given that the EVO sensor is intended to count more air than the 3S one, I'd expect the max frequency to occur at a similar percentage of max flow and the rest of the airflow to be scaled accordingly, rather than keep the 3S airflow ratio and just add headroom. This would result in a lower frequency air count at the same air flow.

It might be interesting to connect a 3S MAF to an EVO MAF in series, use one to run the car, and log the other. This would get you airflow curves for both sensors at the same airflow value. Then switch them and see if the same relationship holds.


Something that will really blow your mind is I don't believe the MAF itself is a restriction like we are all accustomed to believing. In the code, there is a 1 byte limitation to the MAF signal at about 319 pulses per RPM. Without going into too much detail with the math (though I can if you'd like), this comes about 450hp. Now, that number about where people have been running out of power with the stock MAF. What happens is past 319 pulses per RPM the ECU just stops adding fuel as it doesn't see any more pulses past that limit. Air keeps coming in but the numbers are beyond max so the AFR just leans out.

I absolutely believe it - there is a similar feature in the AEM. It is the difference between the "software calibration" of the MAF (what the ECU thinks the maximum value of the MAF is) and the "physical calibration" of the MAF (the relationship between the volume of flow through the sensor and the output frequency)

This brings us back to the desire for a flow bench test to see exactly how much air volume can be passed through the thing and what the output signal looks like.

I would absolutely like to see the math, in detail, for how the OEM ECU calculates its load values, starting with the individual pulses measured at the MAF and ending with the load axis on the tables. I know exactly how this works on the AEM and I have it documented on farnorthracing.com If I knew how the OEM ECU did it, I could make a conversion function that would convert OEM calibrations to AEM calibrations and back again. One could have an AEM whose initial calibration was exactly the same as the OEM ECU (within the limits of the AEM control scheme to duplicate the OEM and vice versa)

I don't think I have your email address.

DG

[Greg E]

That makes sense though if what the "scale factor" is, is a VE factor. Changing the efficiency of the flow path behind the sensor is going to alter the relationship between air measured at the front of the pipe and air "measured" (by the calibration) at the end of the pipe. I'd bet, for example, that if you moved the MAF to right before the throttle body, you could change intake piping all you wanted without needing to rescale the MAF - because changes upstream of the sensor get measured by the sensor.

Similarly, I expect that changing air filter designs doesn't require MAF rescaling either.

You're right. Funny we are having this talk. Check this out. Tonight I just disassembled the intake section of one of the 99 SL ROMs (working on a chrome NA version right now).

http://i.imgur.com/YE1ua.jpg

The scalings are the same BUT obviously there's a huge difference between the NA and turbo intake pipes. :lol:

So what's different between an NA and TT motors? You got it, Volumetric Efficiency.

http://i.imgur.com/8l7cJ.jpg

So then the reason the trims are changing with aftermarket pipes or what not is because the engine's VE is changing. Not so much that more/less air is sneaking thru the MAF undetected.


My experience though with the AEM in MAF mode is that the MAF is very insensitive to VE changes, whereas the Talon (which was an AEM in speed/density mode) was very sensitive to VE - one of the reasons I retained the MAF for my Stealth.

Yes. I have an idea for getting around this. Rather not discuss it here though. I'll get you my email.


I absolutely believe it - there is a similar feature in the AEM. It is the difference between the "software calibration" of the MAF (what the ECU thinks the maximum value of the MAF is) and the "physical calibration" of the MAF (the relationship between the volume of flow through the sensor and the output frequency)

Learned something else tonight with the NA disassembly. Earlier this afternoon, Jeff pointed me to the club3G forums where the guys have been playing with ECUFlash a bit. They ran into issues making the code work with high airflow/load. I think I found out why.

http://i.imgur.com/fYVQz.jpg

Same MAF scalings but the NA and TT MAFs are different part numbers. It would seem the frequency calibration theory holds some water.


I would absolutely like to see the math, in detail, for how the OEM ECU calculates its load values, starting with the individual pulses measured at the MAF and ending with the load axis on the tables.

Most of this is posted in the top of this thread (InjectorMAF_Comp), but I've left some things out from the whole equation. Since I need to redo the first post (probably do this tomorrow) I'll get it out laid out for you start to finish.

[DG]

Man, you could really help me out by copy/pasting the values from all these tables into an Excel spreadsheet where they can be manipulated and - most importantly - graphed.

Slopes and shapes tell a lot more than lists of numbers.

DG

[DG]

Here's an example of how spreadsheet analysis can perhaps illuminate some of this stuff:

1. Make a table of airflow steps, from maybe 50 CFM to say 500 CFM in steps of 50 CFM

2. Pass that table through the MAF scaling table and graph the results

3. Pass the results of step 2 through the MAF Smoothing / VE table (using the same math as the ECU code uses) and graph the results.

Questions:

1. Given that the input is linear, how linear is the output from Step 2?

2. Is the output from Step 3 more or less linear than the output from Step 2?

3. What is the largest deviation from perfect linearity in Step 3, as a percentage?

This will provide clues as to what is going on, and to the scale of the correction.

DG

[Greg E]

Days like today where I wish I could bring my laptop into work and hide somewhere with it... My job is so boring sometimes.

[Blackmount]

wasn't sure to make it a separate thread or not but here. Hope this is what you guys are looking for....

http://www.3sgto.org/f104/maf-flow-rates-info-10522.html#post206565

[DG]

Nope. All that stuff is inference and guesswork. Nobody has actually hooked a MAF to a flow bench and actually measured the response curve. It's all urban legend stuff.

DG

[Jeff V.]

Dennis, I'm all for getting calibration data on these sensors. And I'd love to see it adapted to an AEM.

But how, exactly, can that be done? The first thing the stock ECU does is count the number of pulses from the MAF sensor during a given intake stroke. To make matters worse, a 2nd intake stroke starts ~2/3 of the way through the previous one. (On a DSM, you only have one intake stroke from crank falling edge to falling edge.)

So you need to be able to capture these pulses as the lowest hardware level, in two separate streams, before you can do math on any of it. You also need to compensate for the fact that, for ~1/3 of the cycle, you have two cylinders pulling air through the MAF.

I don't know the AEM that well, but I don't think they give you low level access to the pulse accumulators for the MAF sensor, or the rising/falling edge triggers and timers associated with the crank sensor.

So even with bench data for the sensors and the raw math from the factory ECU, you're still stuck kludging that on top of the strategy that AEM designed for managing these Karman equipped cars. In the end, you have only an approximation of the Mitsu strategy. It sounds like you already have a damned good interpretation of that.

[99 vr4]

You're right. Funny we are having this talk. Check this out. Tonight I just disassembled the intake section of one of the 99 SL ROMs (working on a chrome NA version right now).

http://i.imgur.com/YE1ua.jpg

The scalings are the same BUT obviously there's a huge difference between the NA and turbo intake pipes. :lol:

So what's different between an NA and TT motors? You got it, Volumetric Efficiency.

http://i.imgur.com/8l7cJ.jpg

So then the reason the trims are changing with aftermarket pipes or what not is because the engine's VE is changing. Not so much that more/less air is sneaking thru the MAF undetected.



Yes. I have an idea for getting around this. Rather not discuss it here though. I'll get you my email.



Learned something else tonight with the NA disassembly. Earlier this afternoon, Jeff pointed me to the club3G forums where the guys have been playing with ECUFlash a bit. They ran into issues making the code work with high airflow/load. I think I found out why.

http://i.imgur.com/fYVQz.jpg

Same MAF scalings but the NA and TT MAFs are different part numbers. It would seem the frequency calibration theory holds some water.



Most of this is posted in the top of this thread (InjectorMAF_Comp), but I've left some things out from the whole equation. Since I need to redo the first post (probably do this tomorrow) I'll get it out laid out for you start to finish.

For those of us that are experiencing cut at quick spool up and max boost, can we raise this?

And hey I need the 2.0 xml file... And bin...

[Greg E]

There is no way you're flowing so much air that you've reached this limit already.

...and no it can't be raised. FF is the limit and the table is maxed stock. I have to get creative to get around this limit.

[DG]

Dennis, I'm all for getting calibration data on these sensors. And I'd love to see it adapted to an AEM.

But how, exactly, can that be done? The first thing the stock ECU does is count the number of pulses from the MAF sensor during a given intake stroke. To make matters worse, a 2nd intake stroke starts ~2/3 of the way through the previous one. (On a DSM, you only have one intake stroke from crank falling edge to falling edge.)

So you need to be able to capture these pulses as the lowest hardware level, in two separate streams, before you can do math on any of it. You also need to compensate for the fact that, for ~1/3 of the cycle, you have two cylinders pulling air through the MAF.

I don't know the AEM that well, but I don't think they give you low level access to the pulse accumulators for the MAF sensor, or the rising/falling edge triggers and timers associated with the crank sensor.

Yes, you get access to this low-level stuff, in a matter of speaking:

The MAF vortex pulses (and fractional pulses) are counted in a window of engine CAMSHAFT revolutions, set in option VMAF_Flow_sum_Revs. (typically set at 4)

The count can be seen by logging parameter MAF_Flow_sum_raw

This is then corrected for barometric pressure and air temperature as shown in parameter MAF_Flow_sum_cor

Parameter MAF_as_Load = MAF_Flow_sum_cor / VMAF_Flow_Max as long as MAF_Flow_sum_cor in is the range defined by VMAF_to_TPS_Above to VMAF_to_TPS_Below

MAF_as_Load is thus a 0-100 value indicating the percentage corrected load range of the flow meter.

Engine Load is the same value converted to an engineering unit - which, as noted above, is scaled to the range of the MAP sensor if one is installed.

Parameter T4PER will indicate the period = 1/frequency of vortex meter, expressed in microseconds.

So then, given all that, if the base count for the OEM ECU is the MAF pulse count during one intake stroke, then the AEM base count is the number of counts from the MAF during as many of those intake strokes as happens in VMAF_Flow_sum_Revs (usually 4).

Let me put it this way:

The OEM ECU counts MAF pulses during a window. Then it does math on those pulses to eventually end up with a LOAD value.

The AEM ECU counts MAF pulses during a window. Then it does math on those pulses to end up with a LOAD value.

The size of the AEM window is known (and configurable). The math the AEM uses to get from pulses per window to LOAD is known (and somewhat configurable)

What is NOT known (to me) is the ratio between the OEM count window and the AEM count window, and the math the OEM ECU does to get from pulses per window to LOAD.

Once I do have that, I can go:

OEM LOAD -> do math to get pulses per window -> convert OEM window to AEM window -> do math to get AEM LOAD

And now I can translate every single OEM LOAD-based table to an AEM LOAD based table.

Somebody documenting the OEM LOAD calculation procedure would get me there.

Let me worry about the AEM side - what I need is the OEM side.


So even with bench data for the sensors and the raw math from the factory ECU, you're still stuck kludging that on top of the strategy that AEM designed for managing these Karman equipped cars.

Yes. That is exactly the idea.

The calibrations won't wind up perfect 1:1 equivelencies. While overall very similar, there will be differences based on how the various tables and whatnot are laid out. But that's OK - "perfect is the enemy of good enough" - and "good enough" will be so much better than what we have now it's not even funny.


In the end, you have only an approximation of the Mitsu strategy.

Yes. Correct. That is what I want - the best possible approximation of the Mitsu strategy in an AEM context.


It sounds like you already have a damned good interpretation of that.

Oh, dude, nowhere near. Like not even in the same ballpark. Like not even in the same CITY as the ballpark.

Fuel isn't bad, thanks to wideband O2 feedback and logging the correction values / correcting the main fuel map using the feedback correction (aka "poor man's auto tune"). But the air temp corrections, baro corrections, coolant temp corrections - those are all guesses. And the timing map is complete shit.

All of Mitsu's experience and R&D is locked up in that OEM ECU calibration. Not that it can't be bettered, but it is THE starting point. The AEM provided initial calibration is a SWAG with little to no actual science behind it.

Lemme put it this way - once I saw the breakdown of the OEM startup maps - which don't use LOAD, but rather raw values - and even though the tables do not map 1:1 and there are functions on both ECUs that don't correspond to each other, it was enough information that in 10 minutes I had cold start working better than about 5 years of tinkering on my own.

"Oh, that's how they do it!" and now it is pretty much key on and start immediately down to at least -5C

DG

[Greg E]

Dennis, I haven't forgotten about you. Just been pulled in all kinds of directions all week. Hard enough explaining all this to folks but I'm stuck trying to teach a guy in France who doesnt speak english as a first lamguage how to use this....

[DG]

No worries. I am nothing if not patient.

DG

[Greg E]

I have to explain the difference between Mitsubishi version of air flow vs OBD2 definition of air mass. The ECU calculates both.

The tables you see listed above are what the ECU uses during the IPW calculation. This single sub has over 300 lines of code and there's still a chunk of it I don't understand. When I started typing this equation out in an email to you, I only got about 1/8th of the way thru it before I realized that's TMI.

What you are looking for is the ECUs interpretation of air mass or the OBD2 side of the equation which is much simpler to explain. I don't foresee any distractions tonight so let me get back into this when I'm home with my disassembly in front of me instead of going all out from memory.

The tricky part is, the ECU uses different levels of this calculation throuout the various table axises. Some use compensated load, some use uncomp load, some use the whole 2 byte word value, some get clipped and resolution expanded to fit into a 2 byte value... It's tricky. I'm guessing the one you care about is the load value used in the fuel and timing table axis correct?

[DG]

Yeah. The calculation that gets me the load axis on any load based table - ignition and fuel for sure.

DG

[Greg E]

Okay, finally at my computer.

The OBD2_Load (air mass) calculation starts with this.


Load quite simply is just Air_Count * MAF_Size / 65536. This is uncompensated Load (meaning Air Temp and Baro haven't been applied yet).

Remember Air_Count is the MAF Pulses Per RPM.

Then there are the air density factors.

First it takes the barometric pressure compensation which is a single multiplier value. If barometric pressure is 100.45kpa, the multiplier is 1. As barometric pressure increases above that, the multiplier increases as well. Less pressure, the compensation value becomes a fraction. I don't know why they didn't code it as a table look up. Would have been simpler to code... Maybe this would be a great future Chrome Mod to give the user the ability to edit the baro comp.

Next, we have the Air Temp correction. This value is a table look up shown here.

http://i.imgur.com/gqAXN.jpg

Again, this is another multiplier value. From this table, if the AITs are 73 degF, the correction factor is 1.

So the final equation looks like this:

Load_OBD2 = (MAF Pulses Per Second/RPM) * MAF_Size * BaroComp * AITComp / 65536

That's basically it. The Load axis you see in the fuel and timing tables both use this air mass value.

[DG]

That's it?

That seems awfully simple...

That's engine RPM right, not camshaft RPM?

Ok then... differences... AEM has a longer measurement window (4 cam revs, so 8 crank revs) but it could be shortened to 1 cam rev. So what? Need to think that through. Shorter window means faster response, less smoothing. May change max airflow the AEM can see. Can probably change VMAF_flow_max to bring it back then...

Hm. This is RPM based which means I can work out the actual time window vs RPM at the breakpoints... So what?

OEM compensates for temp and baro before becoming LOAD. So does AEM. Can probably duplicate the OEM comp tables in AEM. Breakpoints won't be the same but slope and intercept can be. It'll be interesting to see where that lines up.

The cell contents in the ignition map are just degrees advance in both systems so those should line up. What are the cell contents in the fuel map? Is it a straight injector pulsewidth or is there postprocessing?

Thanks a lot for this; this is going to open a whole bunch of doors (and pose almost as many questions)

DG

[Greg E]

That it is. Show you the code. Very simple. :)

Some tables use uncompensated load. Most don't. I tried to label the ones that aren't in V2 in the table description.

[99 vr4]

I don't know why they didn't code it as a table look up. Would have been simpler to code... Maybe this would be a great future Chrome Mod to give the user the ability to edit the baro comp.



Probably because anytime you have hard coded math it runs in less cpu cycles as opposed to math based upon lookup tables. My guess is that they hard coded the value everywhere it is used which would suggest Mitsu felt that this was very sensitive...

[Greg E]

Probably because anytime you have hard coded math it runs in less cpu cycles as opposed to math based upon lookup tables. My guess is that they hard coded the value everywhere it is used which would suggest Mitsu felt that this was very sensitive...

Maybe.

More opt to believe they did this because the baro sensor is the same in all their cars and the AIT sensors vary. They coded a table lookup so it could be edited for the various types of AIT sensors.

[99 vr4]

Maybe.

More opt to believe they did this because the baro sensor is the same in all their cars and the AIT sensors vary. They coded a table lookup so it could be edited for the various types of AIT sensors.

Yeah what he said... Lol

But... What if they had to change the baro sensor due to an unforseen issue...

Normally when programming, you would define a library of static variables for these types of things. But for highly sensitive calculations, you hard code values in the math due to cpu cycle overhead. The pro is less cpu overhead and faster calculations. The con is IF it changes, you have to touch more code. Normally accepted code protocol dictates that UNLESS you need the speed OR you don't have the ROM space, you ALWAYS define a static variable. This would translate vis the compiler in machine code to a 1d lookup, normally an address space like the ROM calibration ID.

The one thing I have learned about Mitsubishi code is that they do everything for a highly calculated reason. Very much ISO 9000. If a value is used more than once in a different area of code, they would have defined a static, unless something else dictates otherwise. These are not super fast CPU's, and code optimization tests may have determined that this was one area that a small change had a large effect.

[Greg E]

Sorry I missed this question.


What are the cell contents in the fuel map? Is it a straight injector pulsewidth or is there postprocessing?

The only tables which uses straight IPW are the startup tables and the Alpha-N fuel map (limp mode).

There's quite a bit of code after the fuel table look up before it gets processed with the IPW calculation. The next sub deals with knock enrichment, lean spool enleanment and closed loop modifiers. Things like warmup enrichment, accel enrichment, decel enleanment... All that is taken care of large IPW calculation subroutine.

[DG]

So I'm finally working on this.

I have this:

Load_OBD2 = (MAF Pulses Per Second/RPM) * MAF_Size * BaroComp * AITComp / 65536

For simplicity's sake, assume BaroComp and AITComp are 1 (legit if tables have same slope and same X intercept)

I'm bashing my head on the units... it's like I can't do friggin' algebra any more. Out of practice... But using Google's calculator (which does units!) and a bunch of scribbled-on paper, I came up with something that seemed reasonable, but was off by a factor of 2.

GregE, I need your help to sanity-check my work, and confirm that it is crank revs that are being used as the MAF count window, not cam revs.

What I need to make the AEM side of the equation is a number of pulses per rev that equates to a given load value.

So for example, those timing "big maps" span 10 g/s to 320 g/s. What is the equation to turn "320 g/s" into "n pulses/rev"?

Not pulses per second - pulses per REV.

Thanks,

DG

[Greg E]

It is CRANK revolutions being used, not cam. Pulses per stroke goes off the crank sensor.

Edit: let me get back to you on the g/rev conversion. Petty sure that g/s number is actually grams/stroke (or grams per rev however you want to word it).