View Single Post
Old 01-15-2008, 11:09 PM   #1
williaty
Scooby Guru
 
Member#: 71092
Join Date: Sep 2004
Chapter/Region: MWSOC
Location: Delaware County, Ohio
Vehicle:
2005 2.5RS Wagon
Regal Blue Pearl

Default HOWTO: One Man's Way of Scaling a MAF

One of the most common mods people do to our cars is to change the intake. One of the most common results of changing an intake is to change the relationship between the amount of air flowing past the MAF sensor and the total amount of air entering the system. Without adjusting the MAF scaling to reflect the changes to the intake, the ECU will constantly mis-calculate the amount of air entering the engine. This will affect nearly everything the ECU does from fueling, to timing, to the Closed-Loop to Open-Loop Transition. Re-scaling the MAF is a process of altering the programmed relationship between MAF sensor voltage and the grams per second of air entering the engine.

I'm going to show one way of doing using software everyone has access to (spreadsheet). It cuts some corners, so there are more accurate ways to do it, but this method returns good results.

Now, some notes about my process. First, it only works in Closed Loop because I'm using the stock O2 sensor and the A/F Learning and A/F Correction parameters. If you want to scale the entire MAF curve, you'll need to use a WBO2 and use the error between the observed air/fuel ratio (hereafter AFR) and the target AFR at that load and RPM instead of AFL and AFC. Second, I cut some computational corners to make this easier and quicker to do. As far as I can tell, they don't cause too much problem. Third, you won't nail the calibration in one shot for several reasons. When you make a change to one reference point in the scaling, it has an affect on the regions near it due to the way the ECU interpolates between values. The ECU also seems to be fairly inaccurate when the total correction is large (greater than about 8-10%). All of this just means that you'll repeat this process more than once. Note that it is VERY important that you collect data at a constant temperature. If you collect data at 30F one day and then 60F next week, it will totally screw up the process.

The first thing to do is to log a VERY LARGE AMOUNT OF INFORMATION. While a smaller amount of data can point you in the right direction, I try to end up with about 10,000 lines of data after sorting. Considering that you'll throw about half your data out during the sorting process, this means you need to start with something like 20,000 lines of log file. For me, this takes about an hour of driving around to collect. While logging, you want to be recording A/F Correction #1 (AFC), A/F Learning #1 (AFL), CL/OL Fuel Status (CL/OL), Intake Air Temperature (IAT), and MAF Sensor Voltage (MAFv). Set up a log profile with these parameters as you'll be using them repeatedly. Start the car and drive around until your coolant has been up to operating temperature for about 10 minutes and then begin logging. While logging, try to move the throttle pedal as slowly as possible. Quick throttle movements are too much for the ECU to keep up with and result in bad data (this is a big part of what we'll be throwing out). Again, log for about an hour and then head home.

When you get home, open the log in any spreadsheet. I'll be using Excel, but the functions I'll be using are extremely basic and will be present in pretty much anything. OOO.o and the google spreadsheet should both work if you're looking to do this for free.

The first thing you need to do is to add a column for the rate the MAF voltage is changing. Since I'm a geek, I'll call this dMAFv/dt. Fill this entire column with the formula
Code:
=ABS(((V2-V1)/(T2-T1))*1000)
Where ABS() is the absolute value function, T2 is the time from the current row you're working in, T1 is the time from the row before the one you're working in, V2 is the MAFv from the row you're working in, and V1 is the MAFv from the prior row. What you've just done is to calculate the rate of change of MAFv in Volts per second. The higher the rate of change, the more likely the data is to be unreliable.

Now create an XY Scatterplot of Time vs dMAFv/dt. It will look something like this:


Notice how almost everything is scrunched up on the bottom with a few outliers way up in the air? That's not very useful. The y-max needs to be reduced so you can see what's going on down near zero. Making y-max 10 times less results in this:


Now we can see data beginning to float up away from the bottom of the graph. On my car at least, I still need to reduce y-max even more to see what's going on. Making y-max 5 times smaller yet results in a useful graph:


OK, you can see a whole bunch of data piled up on the x-axis indicating that we have a lot of samples where the MAFv wasn't changing at all, which is a good thing. You can also see that there's a bunch of samples where the MAFv was changing slowly. We can probably get away with using those samples. You'll need to look at the graph and try to come up with a level where you're keeping as much data as possible, but you're throwing out all the random data points that are too high. For this graph, I would choose 0.3V/s because most of the data is below this level, but most of the spikes are above it. Now that you've picked your threshold, go ahead and delete the graph. Yes, really. Finding the threshold was all it was for.

Highlight all of the columns, and click Data->AutoFilter. After that click on the AutoFilter widget for the dMAFv/dt column and select Custom. You want to set the filter to Greater than or Equal to the threshold you found from the graph. In my case, this is 0.3V/sec. Now, highlight all the rows returned by AutoFilter and delete them. You've just deleted most of the data where the MAFv was changing too rapidly. Note that this is one of the corners I'm cutting and I'm sure I'm making the stats/engineering people froth at the mouth right now, but it seems to work in practice. Anyway, after deleting the rows, delete the dMAFv/dt column as you won't be needing it anymore.

Click the AutoFilter widget for the CL/OL column and select 10. 10 is Open Loop, which is useless to us. Delete the returned rows, and then delete the CL/OL column.

Back to graphing. Make an XY Scatterplot of Time vs IAT. It'll look something like this:


As you can see, there's sort of a flat trend on the bottom punctuated by spikes upwards. The flat bit at the bottom is good data where the engine was getting cool air. The spikes upwards are traffic lights, stop signs, stop and go traffic, etc where the intake heatsoaked and IATs rose. The AFL and AFC values will change A LOT with IAT so you need to keep IATs as stable as possible. Much like we did with the last graph, the point here is to pick a value that throws out the bad data and keeps the good. So, spikes out, bottom flat bits in. For this run, 40* looks pretty good. Once you've found your IAT threshold, delete the graph.

AutoFilter the IAT column with a custom filter that's greater than or equal to the threshold you picked in the last graph (40* in this case). Delete the returned rows, then delete the IAT column. Finally, delete the Time column.

Now, sort all of your data by MAFv, Ascending. This will make it easier to group the data together. After grouping your data this way, select all the data (but not the column headers) and Cut it, then Paste it about 30-35 rows lower to make room for what you're about to add.

Add a column called Cor% that will be the total correction for each row. Fill the entire column with the formula
Code:
=AFC+AFL
Where AFC and AFL are obviously the cells, not the letters AFL/AFC. Then add a column named Mean and one named Mode.

If you look at the MAF Scaling table in your ROM, you'll see that it's just a list of MAFv and the g/sec that they correspond to. The first thing we have to do is figure out what MAFv's get tossed into what cell on the ROM. In other words, we need to divide up the entire range of MAF voltages possible into chunks that correspond to a MAFv in the Scaling table so we can figure out what to adjust. Keep in mind that the values in the table are center points and the ECU interpolates between them. Confused? OK, I'll use a small example. Looking at the bottom end of MY MAF Scaling table (and yours might be different, so don't use my numbers), the MAFv row looks like this:
Code:
0.78	0.82	0.86	0.90	0.94	0.98	1.02
So, if those are the centers of the ranges, your job is to work out where the ends of the ranges are. For example, the 0.78 cell actually runs from 0 to 0.80 volts. The 0.82 volt cell runs from 0.80 to 0.84 volts. Likewise, the 0.86 cell runs from 0.84 to 0.88. You'll need to make yourself a little cheat sheet listing all the voltages from the MAF Scaling table from your ROM and the corresponding range for each cell. It's a pain in the ass to do, but you only have to do it once.

Once you have your cheat sheet worked out, you need to type in the MAFv values from your ROM into the MAFv column in your spreadsheet in the opening you just made. In the example log I'm using, the MAFv ranged from 1.14V to 3.01V, so I don't give a damn about anything below the 1.13 cell from the MAF Scaling table or above the 3.01 cell. This picture shows the addition of the MAF Scaling table's cells to the spreadsheet along with the Cor%, Mean, and Mode columns:


Now comes the grunt work. It'll get faster the more times you do it, but it's a pain in the ass for sure. For each of the MAFv's you added to your spreadsheet, you need to find out the mean (average) and modal (most frequent) correction for that range. To do this, you're going to use the average() function for the mean and the mode() function for the mode (duh). The process would go something like this: in the row for the 1.13 MAFv cell, type "=average(" into the Mean column, then click and drag over the Cor%column for all the rows containing a MAFv voltage value in the correct range for the 1.13 MAFv cell (in this case, basically only 1.14). Then, do the same thing in the mode column with the mode() function. Life will go much quicker if you click and drag to select the cells for the average() function, and then just copy and paste the cell range over to the mode() function rather than dragging again. Do this for each MAFv cell and you'll end up with something like this:


Now, that's actually everything you need to scale your MAF, but I find just the numbers kind of hard to grasp so I like to graph them too. If you create an XY Scatterplot of MAFv, Cor%, Mean, and Mode and then beat on the formatting for a minute, you'll end up with this:

Now THAT is a lot easier to interpret! I can see where I have a lot of data and where I don't have any. I can see trends up and down and get a feel for where the data really is headed. Congratulations, the hard bit is over!

Once you have all your data summarized like this, all that's left is to figure out how it changes the MAF Scaling table. The easiest way to do this is to create another, VERY SIMPLE spreadsheet. The spreadsheet will need four rows: 1) The MAFv cell values from your ROM 2) The current g/sec for each MAFv cell in your ROM (basically just copy your MAF Scaling table into a spreadsheet untouched) 3) The % correction and 4) the resulting corrected g/sec. The only math you need to do in this table is to calculate the corrected g/sec from the correction percentage and the current g/sec. The formula for that is
Code:
=Current_gsec*((cor%/100)+1)
Fill that formula all the way across the row and fill 0 in all the way across for the cor%. This should result in the Corrected g/sec being the same as the Current g/sec. Now, looking back and your calculated Means, Modes, and the big graph, enter the correction you'd like to use into each MAFv cell in the current spreadsheet. It should come out looking something like this:


The last step is to type the Corrected g/sec values into Enginuity to update your MAF Scaling table. Save the ROM and re-flash your car. Repeat the process until you're happy with your results. After 3 iterations, my mean and modal corrections are all less than 1%, so I'm pretty happy.


One thing you should look out for is to make sure you're fixing the right problem with the right adjustment. The log you just took will show you problems with MAF scaling, Injector scaling, and Injector Latency. This should make it clearer.


OK, that's a graph of 3 different general shapes for fueling error graphs. Unfortunately, in the real world, you'll usually be seeing 2 or more of them going on at the same time

Error Type 1 is a vertical offset or zero error. The graph has a general trend all in one direction and basically all the same amount. This can be caused by things like incorrect injector scaling, placing the MAF in a different-than-stock sized housing or a new bend before the MAF. This can be fixed with either MAF scaling or Injector scaling. You should alter whichever scaling you've physically changed. This means that if you've just changed injectors, change the injector scaling. Likewise, if you've just altered the intake somehow, change the MAF scaling.

Error Type 2 is a slope error. It will be is a straight line with a constant slope in either direction, possibly crossing 0. This is likely caused by injector latency, but with how ornery MAFs are, I bet you could cause this to happen by changing the intake too. This can be corrected with either Injector latency or MAF scaling. Again, fix the scaling for whatever hardware you just changed.

Error Type 3 is a random error. The graph isn't a straight line and has peaks and valleys. 90% of the time, this is the MAF being pissy about resonance or turbulence. This can only be fixed by MAF scaling. Adjust MAF scaling until the error is a straight line, then evaluate it for Type 1 or 2 error lurking within the MAF scaling corrections you just made. Again, make sure you're adjusting the right thing. If you just changed the intake, and then you got a bunch of fueling error, MAF scaling is what you want to change, not anything else.

So as you can see, you can fix any error with MAF scaling. It might not be the right way to do it though.
* Registered users of the site do not see these ads.

Last edited by williaty; 03-23-2008 at 08:12 PM.
williaty is offline   Reply With Quote