From the earliest versions the donor XDF’s have included an undocumented patch which is simply named **MAF Patch**.

A few people have asked what it does, and my response always includes something along the lines of “I really should document that!”.

So here it is finally - the documentation...

## What it does: short version

The **MAF Patch** alters the **MAF Calibration curve** and **ai_analg_multip: MAF** parameters to extend the usable range of the stock MAF sensor.

With this patch the stock can read out to around 850kg/hr before going out of range.

## What it does: tl;dr version

As you’ll be aware from the MAP recalibration tech note the ECU uses a resistor divider to reduce the voltage entering the Analog Digital Convertor (ADC) to 90.7046% of the original value. This is primarly to protect the ADC inputs from over voltage damage.

The ADC uses a reference voltage of 5000mV, so can convert an analog voltage in the range of 0 - 5000mV into a digital value between 0 - 1023. These digital values are known as ADC codes.

A voltage greater than 5000mV will result in an ADC output of 1023.

The following plot shows the relationship between sensor output in mV and ADC codes.

It should be apparent that the maximum ADC code output of 1023 corresponds to a sensor output of somewhere around 5500mV.

More precisely the maximum sensor output that can be represented without clipping is:

```
1023 / 0.2046 / 0.907046 or 5512mV
```

The ADC codes and “magic numbers” are covered in detail in the MAP Recalibration post so I won’t go into detail again here.

The stock map parameters use an **ai_analg_multip: MAF** of 5388 and **ai_analg_divisor: MAF** of 1000.

Working backwards from the default MAF limiter voltage of 4950mV we can determine the ADC output in *codes*

```
4950 * 1000 / 5388 = 918
```

And the corresponding sensor output voltage is therefore

```
918 / 0.2046 / 0.907046 = 4946mV
```

So the **ai_analg_multip: MAF** of 5388 reverses the scaling of the hardware and ADC, and the **MAF Calibration Curve** map is used to determine the Airflow value in kg/hrs.

The obvious thing here is that there is a bit of untapped range available in the ADC convertor. And we know the MAF can output much more than 5000mV.

For the patch I decided to use 5000 as the **ai_analg_multip: MAF** scalar. So lets assume the same 4950mV limiter and calcuate the ADC Codes:

```
4950 * 1000 / 5000 = 990
```

The sensor output that produces 990 ADC codes is

```
990 / 0.2046 / 0.907046 = 5334mV
```

You could probably go higher, but I’m keeping it on the safe side. After all range that we are using is quite literally uncharted territory beyond the calibration range of the stock MAF.

The problem now is that the a MAF output of 4950mV now produces

```
4950mV * (5000/5388) = 4593mV
```

I resorted to MATLAB’s Curve Fitting Toolbox to come up with a best fit for the stock curve, and then extrapolated the curve out to 5334mV.

Obviously extrapolating a curve in this way comes with no guarantees of accuracy, and the further you move away from the known the more quesitonable the extrapolated value. This is another reason I was reluctant to push to 5500mV with the stock MAF sensor.

Once the curve had been extrapolated the next problem was that retaining the standard column header values made it very difficult to obtain smooth integration of the new maximum flow values.

To solve this problem I used a table optimisation toolbox for MATLAB. The toolbox allows you to load a curve and then specify a required number of columns. It then optimises the breakpoints to minimise the deviation from the orginal curve.

The result is of all this was a new MAF curve that reads out to over 850kg/hr, and has a maximum error of +/-1% when compared to the stock MAF curve.

The error plot is slightly misleading - the maximum error is at lower sensor outputs of around 100kg/hr. The larger deviations of 2.5kg/hr occur at flows of 500kg/hr and above, so are in the range of +/-0.5%.

So there you have it.

The MAF patch is basically a take it or leave it affair due to the fact that it’s been optimised to minimise error as far as possible compared with stock.

I’ll look at adding MAF limiter editors in the next revision of the XDF’s which will allow the MAF sensor to saturate at the maximum rather than limiting.