I've decided to create this thread to document my efforts at creating a replacement for the GEMS MAF. As some of you will know, the GEMS MAF is unavailable anywhere other than landrover (if its even still available) and costs a fortune. Aftermarket units are junk. After buying probably 4 or 5 used MAFs at this point, i wanted to find a solution.

My thinking is simple. If we can figure out the curve, we can build a "module" which can translate the values from some other cars MAF, over to signals the GEMS ECU expects.

Having had some background in tinkering with 2000's VAG cars, i know that their Motronic 7.5 ECU's contain a 512x1 table which contains the MAF calibration in a very simple format: kg/sec against voltage. As such i have curves available for many common VAG MAFs. Those VAG MAF's are ubiquitous, readily available, and cheap new. I also already have a few units knocking around i can use for testing. Half the problem is thus "sorted"

If we can acquire the same curve for the Lucas 20AM, we can then create a translation table between the two.

Trying to find this information online seems pretty much impossible. Tuning info on the GEMS is rare, and i havent been able to find the factory calibration anywhere. However when replacing my broken MAF with yet another used one recently i noticed something potentially useful. RAVE provides airflow figures that should be seen at various engine speeds. One reason i know my newest-old MAF is junk is that it massively overreads against these figures. However while staring at the Nanocom, i realised it was showing both airflow in kg/sec and MAF voltage...

My first attempt then was to drive around, and use the nanocom logging function to log these two values. Unfortunately nanocom updates extremely slowly and seems to only pull one value at a time, which means the displayed airflow and voltage dont line up in time, and thus its all a bit random. Perhaps with many miles of logged data, we could get something resembling a curve, but i wasnt happy with this approach at all.

Spent some time thinking about it, and threw together a MAF "stimulator". Essentially its an Arduino Nano, and a MCP4725 DAC. The arduino is programmed step from 0v to 5v in 0.3125v intervals. Fishing about in my box of parts i found a matching connector for the harness MAF plug, so i can plug this contraption in, inplace of the MAF. The idea being that instead of driving around, i can just sit on the drive, ignition on, engine off, and feed in the sequence of voltages and log the output.

So, tonight, i went to give it a try. And, provisional results are that it worked, kinda! Nanocom kept disconnecting, and i realised the battery was flat, which potentially was causing the nanocom weirdness, however i managed to capture a bit of data before i gave up with the battery down to 7 volts and went and fished out the battery charger instead.

Interestingly you can see the lag i was talking about in the log due to how the nanocom polls each value. In order to try and minimise this, i'd set the Arduino to step the voltage once every 10 seconds. It appears to update the voltage first, then airflow shortly after.

As you can see it was a struggle to keep the thing connected for more than about 30seconds, but you can also see some nice clear data points. Will revisit later in the week when it has a charged battery and see if we can capture the full sweep.

Wow, that’s serious stuff. Good luck and I’ll be looking forward to seeing how it goes.

Well done you!

silly question
even if it only read close to the parameters, (thats a differant MAF) wouldn't the computer trim it in or just not read it .

mad-as wrote:

silly question
even if it only read close to the parameters, (thats a differant MAF) wouldn't the computer trim it in or just not read it .

The long term trim is a single multiplier applied to the whole curve. If the whole curve was somehow scaled, then the trim would work.

The curve however is not linear. Voltage changes much faster at low airflows, and much slower at high airflows. Which means if the curve ends up the wrong shape the ECU simply cannot trim it out.

Once I get some more data points I'll throw up a graph showing how different the curves can be.

Interesting stuff! I'll be watching this.

In the past I've used pull-up / pull-down resistors to get failing MAF signal voltages something like as they would be for a good MAF.

I've previously suggested (though a while ago and maybe on a different forum) using electronics/micro-controller with AD and DA convertors to make signal from one model MAF match signal from another model MAF.

I know the 0.3125v intervals were just for testing purposes and you'll know that in application you'll need more resolution than 0.3125v intervals... on some vehicles a difference of 0.01v can make a difference to trims at idle and low load airflows. Lots of reference points and then interpolation for in-between points?

Not sure exactly how different intake air temps (and to lesser extents barometric pressure and humidity) will affect things.. In theory both MAFs should be self compensating for those aspects because they measure mass directly but I'm not sure if that's always absolutely true with different MAFs? Would in any case get the IAT reading close to actual (and charge the battery lol) before getting deep into matching the signal voltages.

Expect the lag between voltage reading and KG/hour reading will just be due to update speed of the Nanocom, the ECU itself will immediately react with fuelling changes to voltage changes?

Wonder what the ECU's internal sampling speed is for MAF readings? What will the Arduino input sampling / output voltage refresh speed be? Wonder if there's any difference in voltage ramp times between the 2 MAF's?

yeah exactly, i'm hoping that either i can get a nice "curve fit" trendline that works with my 16 data points and extrapolate there, or i'll do some more passes with a tighter interval. Probably a bit of both. If the Nanocom will stay connected i can just get the arduino to cycle thru with a very small step size and log the whole series.

The bosch maf table is 512 entries long, so thats a voltage step of a bit less than 0.01v between each entry. I'm not sure how good the Arduino ADC is, but i guess if we can build a translation table thats at least 256 entries we should be pretty close, ideally we can do some interpolation between lookups too.

The wonky IAT is apparently quite common on GEMS cars, i've not looked into it too closely, but i will try to measure and take some readings there too.

The MAF should self compensate for all those things like you say, its measuring mass, not volume, i would hazard that the newer Bosch units are probably doing a better job than the 20AM though.

The lag between the kg/h and volts is definitely a nanocom issue (or perhaps just the ECU's diagnostic interface/protocol) and yeah, i would expect the ECU to act instantly to changes in MAF voltage. As for everything else, i really dont know. The DAC i'm using can apparently perform updates at around 6khz, which i would hope is plenty fast enough

Sounds like a good project. I would make sure your AMFR is set to zero (which you can write directly in the settings page) before taking the MAF readings as that adjusts the air flow rate reported.

Thinking about this I do wonder how hard it is to get at the actual MAF output without introducing errors so you directly know what the ECU is seeing.

If that can be done with the resources you have then I'd look into putting the two MAF sensors in series as close together as possible and log the outputs simultaneously. Switch them round and repeat to verify that there is no systematic error due to position. Shouldn't be as both sensors will read the same airflow. Divide one output by the other and, in theory, you have your conversion factor directly.

Of course its never that easy but if you can simultaneously measure the outputs from both sensors under the same conditions a heck of a lot of potential errors go away.

With this sort of thing you have to pay very careful attention to the result you want rather than trying to characterise things and sorting it out later once you have, hopefully, accurately calibrated measurements on both.

I'd expect the tuning fraternity to have add ons to their flow benches for testing and verifying actual MAF outputs on a modified engine. They aren't particularly accurate devices in instrumentation terms. Repeatable if well made but production variations are wider than I'd like.

Clive

@jacckk - Thanks i'll take a look at that, is that why Nanocom shows "adaptive airflow -0.6"?

Clive, this was my initial thought. However to do that you need a known working (correctly!) MAF, and those dont exist ;) If they did then i wouldnt be doing all of this :(

All youd achieve otherwise, is perfectly replicating your faulty worn out 20AM thats not working properly!

Cool project ..!

Had another go last night, and it was a frustrating hour fighting with the Nanocom. Seriously unimpressed with that POS tbh.

It refused to stay connected to the ECU when displaying the "AIR - IDLE" tab. you'd get 20-30 seconds at most before it would just stop updating. To get it to reconnect, you had to exit all the way out to the main screen and go all the way back in again. and every time you did that, nanocom stops logging. In the end i just used my phone camera to record the screen, and manually plucked the values out later by rewatching the videos later while sat in front of the computer. Ofcourse each time you start logging its in a random place in the sequence, so you need to do it multiple times to actually see all the figures.

Managed 14 of the 16 data points which when plotted in excel makes a fairly nice looking curve.

I then used the "trendline" function to plot a line and used the resulting equation to produce 256 data points from the curve. its not 100%, but its very close and i'm sure its good enough for an old V8! So we're getting somewhere. I'll post some of the data in a little while.

Missing values are 2.5v and 5v

i just could not get the nanocom to capture the 2.5v point. I might reconfigure the DAC to output a constant 2.5v and see if that will give me a reading. I did get multiple readings for the 5v point, but it displayed 788kg/hr, which doesnt fit the curve at all. I suspect they've set full scale around 4.8v and anything beyond that is probably used to indicate a fault. In any case, 777kg/hr is around 270hp worth of airflow, so i dont think it'll ever be going beyond there in normal operation.

Awesome stuff! Maybe if you keep the code flexible you'll be able one day to produce a universal unit that will turn a specifc MAF into the MAF of your choice?

another respectful WOW! I was always interested it this airflow data stuff, but this is really great.

Seems to be turning out great with the smoothly curved response readings etc. Well done :-)

Most OBD systems report airflow in grams per second rather than kg per hour but of course it's simple to convert between the two.

I doubt that in practice readings of less than around 4 grams per second (15kg per hour) need be accurate because below that kind of level the engine would be in over-run no fuel mode, so probably won't need to worry much about matching response accurately for voltage below around 1.1v

Also interesting that from the maf readings we can work out how many bhp or kw worth of fuel an engine uses just to idle.

Dear All,
Excellent work, well done.

Thanks guys.

Not done any more yet, i need to get the bosch unit powered up on the bench and sort some basic code to take readings from it. Unfortunately my "bench" is currently the carpet in the middle of the floor of my study as i'm half way thru remodelling the room which doesnt help!

And yeah, it should be flexible enough to be able to run any MAF. i guess its just a couple of lookup tables in the code. Read input volts from the ADC, lookup airflow in the "input" table, then lookup the representative voltage in the "output" table and set the output. I guess we might add some interpolation as undoubtedly we'll end up between points, i would imagine there are functions pre-existing to do that part anyway.

The other option is a single table in the code, directly mapping input and output, and a supplementary excel sheet which you feed both tables and it creates the output table for you. I'll have a play with both options and see where it goes.

This is really impressive stuff. I am in awe Aragorn.
I don't remember Excel having a curve fitting function. Must have been added in the later versions.

Maybe a generic OBD diagnostic reader will give faster updates from GEMS ? Most generic diag will talk to GEMS ok, just not the other ECU's.

I like my Nanocom, but definitely agree it's a bit slow to pull data.