This post contains a MAF summary from posts that I have made. Each section contains the title and the link to the original thread. It will be linked to in the Prom Tuning sticky as 'MAF Miscellanea.' RBob. maf "the final question(s)?" http://thirdgen.org/techbb2/showthre...hreadid=114856 I've been staying away from controversial subjects. However, I just might be able to provide some MAF code insight. In studying the $32 BUA hac the scalar tables are used for calculating the gms/sec airflow. This is the value as displayed by the ALDL. There are also minimum and maximum gms/sec values that are applied after the calculation has been completed. The code goes something like this: According to an option byte either read the analog or digital MAF and save a raw MAF air flow value. If there is a MAF malfunction then calc the gms/sec term from tps & rpm, and skip the rest of the calculation. (edit: with no MAF malf reported, code continues) The appropriate scalar table is then selected and a lookup is made. This value is then added to the values from the last 4 lookups and divided by 4. This is a rolling average function. In the code it is called a sliding filter. This value is then tested against a minimum value. If less then this value the gms/sec term is set to this minimum value. This value is then tested against a maximum value. The maximum is from a lookup based on RPM. If the calculated value is greater then the max allowed by RPM then the max value by RPM is used as the gms/sec term. Otherwise the calculated value is used as the gms/sec term. HTH's RBob. I just went through the $6E mask (IE: ARAP) and discovered that the code is basically identical to the $32 code. The only real difference is that $6E only supports an analog MAF. One significant discovery that I touched on in the previous post is the use of a max gms/sec vs RPM table. Both $32 & $6E use this table. What it means is that no matter (sic) what the MAF is reporting for air flow, it will be max limited to the values in this table. Here are the table values as in ARAP: Code: ;---------------------------------------------- ; MASS AIR FLOW vs RPM, maximum value ; ; ARG = gms/Sec ;---------------------------------------------- ;---------------------------------- ; g/Sec RPM ;---------------------------------- LC600 FCB 23 ; 0 FCB 23 ; 400 FCB 30 ; 800 FCB 48 ; 1200 FCB 68 ; 1600 FCB 89 ; 2000 FCB 111 ; 2400 FCB 141 ; 2800 FCB 170 ; 3200 FCB 200 ; 3600 FCB 220 ; 4000 FCB 236 ; 4400 FCB 245 ; 4800 FCB 247 ; 5200 FCB 247 ; 5600 FCB 247 ; 6000 FCB 255 ; 6400 As you can see at 4400 RPM the maximum possible gms/sec airflow will be 236 gms/sec. Folks running MAF 383's and larger may want to keep this in mind. RBob.

I can not explain what you or kvu are seeing regarding
you MAF's. However, there are a lot of open ends.
Is it possible that someone else changed that
table before you? It is also possible that Diacom
is not displaying the proper gms/sec value.

For kvu, it is possible that the ECM is thinking
that there is a MAF error and it is going n-alpha
(default based on tps/rpm). This would show the
effect that you are seeing.

Trying to follow the MAF malf code is difficult. I
do know that there are 2 immediate MAF malf bits
that if either is set the gms/sec goes n-alpha.
These bits are not the same bits that are reported
through the ALDL line (the immediate bits are 6 &
7 of RAM location $40 (L0040)).

I do not have access to a MAF vehicle. So I can not
help in the testing/checking required to figure
out why the MAF does strange things (add sound
track from the Twilight Zone). The best I can do
is to go through the code.

RBob.




Ah, I think I figured out why Diacom is showing
a value greater then the max limit table. They
are grabbing the immediate gms/sec value and
displaying that.

While this is all well and good, it is not a
true representation of the airflow used for
calculating the LV8 and other items.

This immediate value is only used for hi MAF malf
and hi TPS malf testing. The final filtered/limited
gms/sec value (also available on the ALDL) is what
is used for LV8. This is the important term.

RBob.

Sure. However, I would like to go through the
entire chain of events leading up to the final
gms/sec airflow value.

1) The MAF ADC input is read. The ADC Vref value
is 5.1 volts. 5.1 / 255 = 20mV per/count. So a
MAF output of 2.1 volts will be 2.1 / .02 = 105.

The value 105 is the value within the ECM.

2) The ADC value is multiplied by 7 and stored
as a double (2 bytes). This is required as the
MAF scalar tables are a holdover from the digital
or frequency based device.

105 * 7 = 735 = $02DF (I'll use hex from time to
time as it will be easier at some points).

This value will be referred to as: MAFv*7

3) An overflow test is made on this value. It is
a holdover from the digital MAF and is not
required for the analog MAF.

4) The MAFv*7 value will be broken into two
pieces: the MSB and the LSB. The MSB is $02 and
the LSB is $DF (from step 2).

If the MSB is 1 then the MAFv*7 value is divided
by 2 (halved). This is required as the 1st MAF
scalar table has half the resolution as the
others.

5) The MSB of MAFv*7 is used to select the MAF
scalar table. As the MSB is $02 (2) then the
second table is used. If the MSB was $03, the 3rd
table would be used.

6) A 2D lookup is done into the selected MAF
scalar table. The loookup index is the LSB of the
MAFv*7 value. Here it is $DF or 223 decimal.

As it is an interpolated lookup the value retrieved
from the table will be 237.

7) Now the table scalar value comes into play.
The scalar for this table is 48. The math is
to multiply the look'd up value by the table
scalar and divide by 256.

(237 * 48) / 256 = 44.4 gms/sec airflow

The 44 gms/sec value is saved in L00BD. This is
the immediate unfiltered, unlimited airflow term.

The gms/sec value plus the remainder are saved
in L00F1 & L00F2 as a double. This is the same
value as above without the / 256.

This is done so that the filtering and LV8 calc
has higher accuracy.

8) Dependent upon an option bit the full gms/sec
term is filtered (done in ARAP).

9) The gms/sec term is now tested against a
minimum airflow (3 gms/sec). If less then that it
is set to that.

10) The gms/sec term is then tested against a
maximum airflow based on RPM. This is from the
table as descibed in a previous post.

-done calculating the gms/sec term-

It is this final gms/sec term that is used to calculate the load variable LV8.


So now, we get to a MAF scalar table:


The column following the FCB is the actual value
that will be found in the bin. Every column after
that one is informational. All of the above math
may be applied to the columns.

Take the line with 'FCB 198'. If you take the
198 and multiply it by the scalar and divide by
256 the result will be gms/sec:

(198 * 48) / 256 = 37.125 gms/sec

The BIN value of 672 is the ADC counts * 7:

672 / 7 = 96, 96 * 20mV = 1.92 volts

The #/Hr column is probably the conversion from
gms/sec of air to lbs/hr of air. Have to find the
conversion for that to prove it.

In closing, I'd like to point out that if the table
scalar term is changed, the entire table changes.
This is due to the math in step 7 above.

RBob.

It would be interesting to change the ALDL table
to output the intermediate values along with
the MAF status byte L0040. It would be easy
to follow the code and discover what is happening
at any point in time.

Easy enough:

LV8 = inverse RPM * airflow * scalar

This causes a higher LV8 at a lower RPM (given the same gms/sec).
And conversely the higher the airflow (gms/sec) the
higher the LV8. The scalar may be found before the
beginning of the MAF tables.




I would imagine that changing the gms/sec value in a bin editor
will change the bin value. The only way it could do this correctly is
to use that tables scalar term.

The way to check this is to use a binary utility (hex workshop) to
look at the bin values before and after editing.

RBob.




I understand your question. The first column would be the
one that changes when editing the MAF scalar table (the 198
value).

To do this properly the bin editor would reverse the above
equation. If the user wanted to change the 37.1 gms/sec value
(1.92 MAF volts) to 40 gms/sec:

N = (gms/sec * 256) / scalar

N = (40 * 256) / 48

N = 213

The value 213 would end up in the first column of the scalar
table replacing the value of 198. The reason I listed the MAF volts
is due to the MAF scalar tables being referenced to MAF voltage.

As the MAF volts is not available via the ALDL it is understandable
that most folks refer to gms/sec locations whenever they work
with the MAF scalar tables.

This does make it confusing. Just need to remember that the
MAF scalar table locations are based on MAF voltage. The table
values are the gms/sec of airflow at that MAF voltage. Then of
course the MAF voltage is the actual output from the MAF based
on how much air the MAF feels (bad pun) is flowing through it.

RBob.

P.S. If I were doing MAF scalar table tweaking I would change an
ALDL location to output the MAF volts. In that manner the MAF
tables could be more accurately referenced.

LV8:

http://thirdgen.org/techbb2/showthre...hreadid=210456



Understood. The K is a constant that is a calibration term. In the BUA (a $32 mask bin) it is at location $C69A, right before the MAF scalar tables. Here is the location, commments and stuff:



It isn't easy to just plug the numbers into a calculator and get an answer. There is all kinds of scaling going on in the code. If it helps the following is a moderately commented section of the code that does the conversion from gms/sec, RPM, and K to LV8.

RBob.


RBob.

Just a good thread:


Exactly what does the ECM read in from MAF sensor?

http://thirdgen.org/techbb2/showthre...hreadid=176009

MAFless in seattle(I mean st. louis)

http://thirdgen.org/techbb2/showthre...hreadid=236677

Anyone like math?
Here it is, an un-reduced equation that converts airflow, AFR, RPM & Injector
flow rate to a PW in msec.

The .01526 is the msec time span between clock ticks.

Note: I corrected the .01526 multiplier and the DRP to RPM 983040 terms
for this post. Be aware that there are incorrect in the original thread.


RBob.



One more calculation question-MAF BPW

http://www.thirdgen.org/techbb2/show...hreadid=259482



Reduced PW equation:

PW = (((((DRP * gms/sec) / 512) * AFR) / 256) * InjFlwRate / 128) * 0.01526




How is LV8 calculated on MAF cars?

http://thirdgen.org/techbb2/showthre...hreadid=287843

Here is the LV8 equation as actually implemented in the BUA code:

LV8 = (((DRP * gms/sec) / 256) * Scalar) / 64

The DRP can be found be reversing the RPM calculation:

DRP = 983040 / RPM

-gives-

983040 / 1550 = 634

Then gms/sec at 14.01 and the scalar of 80 (decimal):

(((634 * 14.01) / 256) * 80) / 64 = 43 (the LV8, or Load Variable, 8 bits).


RBob.

RBob, great information. I'm a newbee and I ran across this thread. Read it multiple times and it has really help me understand. I have an 89 IROC, 40 over 350, vortec heads, ZZ4 cam, ported TPI, screens out MAF, headers, 28 lbs/43 psi injectors, heated O2,and $6E. If gotten the car running fairly well on a modified ARAP Bin. Idles good. BLMs are close, but still need some adjusting. However I lied to the ECM and set the Injector Constants at 24 lbs. Based on some threads, lieing to the ECM is not good, so I'm concern I've kludged it to make it work. I tried 28 lbs, but it was way to lean and took major changes to the Scalars to get the BLMs out of the clouds. Lot of work ahead if I go down this path. So here are my 3 questions.

1) Can you reverse engineer the MAF tables and scalars by datalogging my currrent configuration and use the Injector pulse width values to calculate backward the Scalar and MAF table values using 28 lbs as the injector constant? This might be an easy way to get the MAF tables/scalars close.

2) You mentioned modifying the XDF file to look for MAF voltage instead of MAF gms/sec. Has this been done and how do you do it?

3) The Injector constants are based on 40 psi. Is this with vaccum connected to the Fuel Pressure Reg or vaccum off? When cruising, vaccum is on and my pressure is around 35-37 lbs. So I'm wondering if setting my constants to 24 lbs is really lieing to the ECM?

HaHaHa
The maf value is not coded to output to the ALDL stream ie code changes to the actual code. RBob just gave us true insight to the how the program uses the values.
Now if I could just get it into my hard head...LOL
Thanks
This Post is mind boggling.
Ed

mind boggling is putting it lightly. I have read this over and over looking for A post by IIRC I about how to get the MAF voltage to show in the datalog. I have searched for that user name and still came up with nothing more than a headache. Oh well, maybe I'll find it next time.

To place the MAF voltage in the data stream several steps are required. The first step is to edit the calibration's ALDL list. The $6E code saves the MAF voltage in location $00F3, so that needs to be edited into the ALDL list.

Pick a location that isn't very helpful, such as the startup coolant temperature. Then edit the calibration by placing the address $00 $F3 there.

This is byte 9 of the stream, and is at address $67F. Currently it is $00 $60, change that to the above value $00 $F3

Save the BIN and use it in the ECM.

Second step is to modify what ever data logging program you are using. Byte 9 of the data stream will now be the MAF voltage. However, it needs to be converted differently then the start up CTS.

So change the data-logging/display to display the value with the following equation:

Volts = N / 51

N being the value from the data stream.

RBob.

RBob,

Nice summary of very useful information.

I've worked with just about every aspect of the MAF signal from input, signal processing, useage and data output as you have described above during my Ford MAF conversion project for tpi. The only thing that I didn't see posted here is information on the signal A/D channel read on channel A.

I think others will find this information useful in their MAF endeavors.

Has anyone done this with TunerPro? This sounds simple enough but I use the APYP_wb bin and the only thing I find in the bin about startup coolant temp is idle rpm vs. coolant temp, if I do an item search on $00F3,$67F or $00$60 all I find is 00F3 being a spark advance table. I can fine the startup coolant temp in the datastrean definition but havn't changed yet.

RBob posted this almost 2 months ago(thanks RBob) and have searched and read the maf treads several times because I wanted to figure it out without asking again but after spending the last 8 hours (at work, nothing happening) reading and searching I have 2 options. 1- I give up, 2- I ask more questions.

If its not in TunerPro like described please tell me where to look. I just hate to thing its right here and I can't see it which would make me feel like an

My shift is about over, I'm beat from reading on here all night and keeping my trainee straight.

The location within the ALDL stream that needs to be changed may not be in the TP XDF file. Since this is a one time change using the Hex Editor works (Tools->Advanced->Hex Editor). Then go to location $67F and you will see the $00 $60 as the two bytes at that and the next address.

Change them to the shown values and save the work (Action->Commit Changes). Then save the BIN.

Then change the .ADS file so that TP-RT shows byte 9 as the MAF voltage.

RBob.

That helped a bunch. I got it edited and went out to do a datalog at idle just to see what happens. At idle I was at 11.?? gms/sec @ 1.7 volts.

I know that has to be wrong but now that I know where to edit I can figure out what I did wrong.

I want to learn all I can about how the code works but if it wasn't for people like you I wouldn't be able to got anywhere. I read the stickies and all the treads I can on tuning because I hate having to ask questions about the same stuff more than once.

RBob, your a great help and and I just hope that one day I know even a 1/4 of what you do about this stuff.

THANK YOU.

Hi, this has been a very informational post and it totally explains something that I was perplexed about. After I made a change to the headers and exhaust on my car, I didn't measure any increase in air flow and I certainly thought I should have seen one. It turns out I was already at the max air flow limit with the old headers (383 with ported iron eagle heads).

But I still have a question, if the max air flow limit is reached and the measured air flow is replaced by the max, then it should be getting too little fuel right? But with both of my measurements the engine is running rich according to the O2 sensor. Why would that be?

Thanks