Disassembly: MAF tables and Air Flow Calculation

[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).



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

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



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.



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-r...tml#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).



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

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



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.



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