MAF wish list

[Matt Cramer]

I've been talking with James and some customers about improving MAF support, and wanted to get a wish list thread started. This would apply to changes in both MS3 and MS2/Extra. What all would you like to see in such a MAF mode?

My own proposals:

MAF uses a table of voltage vs airflow in some sort of recognizable unit - or better yet, several recognizable units (standard cubic feet per minute, lb/min, kg/min, etc)

Tuning via the MAF transfer curve and AFR table 1. MAF transfer curve is editable as a standard curve rather than a sensor calibration, with option to save and load transfer curves.

VE table, if used, functions as a RPM/load correction table. 100% is no correction.

Support for MAF wired to MAP input pin for MS2 / MicroSquirt / MSPNP applications.

Decouple closed loop boost control from fuel load so that it would either use the MAP sensor in MAF mode, or if no MAP sensor present, use a MAFMAP approximation for boost.

[charged3800z24]

lbs/min and full GM MAF support (if it isn't allready).

[ashford]

smoothing or maf window/ sampling seperate of map. i scoped my maf and it gives me some strange results that changes with rpm. also i run almost no ae and it is a bit rich at lower rpms during accell.

[bubba2533]

grams/sec units also please

[shauer]

If we are going to need to edit the MAF curve as a calibration table, then I would recommend being able to display any correction curves as a function of A/D counts. Anything other than A/D counts requires conversion to see where in the calibration table you need to edit. I guess what I'm saying is either make MAF tuning so that you never need to manually edit the raw calibration curve, or make A/D counts the primary unit of reference.

I would like to see the manual MAT correction curve allowed as an option. See me thread here:
http://www.msextra.com/forums/viewtopic.php?f=131&t=44789&p=318805#p318805

I have an issue with my MAF sensor installation where the MAF sensor appears to be cooled somewhat by my cold air intake so it is seeing a lower MAT than is real. It would be nice to be able to correct for this via the manual MAT correction curve. I think this is already on the todo list?

This may sound radical, not sure, but I do not see any use for MAFMAP. In my installation, MAFMAP has no correlation to real MAP and no correlation to the MAF value. It is just another calculated load value to keep track of. I would like the option to use the MAF (g/s) in my VE, AFR, ignition tables etc. Using MAF as primary load for these tables is not an option currently and right now I need to keep track of MAF, MAFMAP, and raw A/D counts to manage my tune.

I am also confused in a few places in the configuration such as overrun fuel cut for example, is the load specified supposed to be MAP, or MAFMAP? This is just one example, but cleaning up the load specifications to use a single consistent measure would be helpful in my opinion.

The basic MAF support is sound, my car has never run better. I would like to see the rough edges to the feature cleaned up so I don't need to use Excel to manually edit a 1024 point calibration curve, keep track of 3 different load units, and allow some temperature compensation.

[jsmcortina]

Why ADC counts though? That's an internal artifact.

My plan was g/s against volts on a 32 point curve. i.e. merge the calibration table and correction curve into one exposed curve.
Frequency input MAFs are already supported and would use the same curve, where "0V" = minimum flow frequency and "5V" = maximum flow frequency.

Air temp adjustment seems fine.

The cleaning up of the load values is a good call too.

James

[bubba2533]

I'm not sure how but it would help to have the frequency MAF's be as similar to 0-5v MAF's as far as calibration curves and such.

ie. they use the same calibration curve, but there is an option to pick 0-5v and frequency. And this would automatically change the units of the curve to hz instead of g/s. (don't have a frequency MAF so I'm just guessing on units)

James beat me to it.

Edit: I would say 32 point may not be enough resolution. I'm just going by OEM's because Subaru has a 64 point transfer curve. (transfers the voltage to a g/s)

Here is the curve for a couple subaru's

[shauer]

My comment about using ADC counts was assuming that we would still need to manually edit the calibration curve file. That's what I need to do now using an Excel spreadsheet and since the calibration curve data is in ADC counts, that is what I currently use to see where I am running against the curve. It looks like this will no longer be necessary which is a very good thing.

I really like the idea of getting rid of the calibration curve implementation and instead using a single g/s vs. volts curve. That will fix a lot of my issues with the current implementation. 32 points should be enough, I would not go much below that though. I have a couple/three peaks and valleys in my current curve especially in the low-flow region. I think 32 points will be plenty to fully characterize what I'm currently running.

Can't wait to see this for real!

Why ADC counts though? That's an internal artifact.

My plan was g/s against volts on a 32 point curve. i.e. merge the calibration table and correction curve into one exposed curve.
Frequency input MAFs are already supported and would use the same curve, where "0V" = minimum flow frequency and "5V" = maximum flow frequency.

Air temp adjustment seems fine.

The cleaning up of the load values is a good call too.

James

[shauer]

Edit: I would say 32 point may not be enough resolution. I'm just going by OEM's because Subaru has a 64 point transfer curve. (transfers the voltage to a g/s)

Just looking at those example curves you showed, I can see how you could remove 50% of those data points and still maintain the shape of the curve. It would require some thought as to where to place the data points with a larger concentration of data points allocated to the low-mid range of the curve. The upper portion is almost linear and does not require many data points to define it. My curve is similar in shape as well.

It's always a trade-off between having to define a large number of discrete data points and not worry about how to distribute them, or being more careful about where you place the data points and having fewer of them to need to define. I would personally not mind having more than 32 data points, but I would like to see what the UI would be like for a table/curve with that many points.

[elaw]

Matt, I agree with pretty much all of your suggestions!

Re units, how about include some pretty common ones, but make them configurable via the .ini file? That way if someone really needs to enter/edit the calibration curve in slugs per millivolt, they can do so by editing the .ini.

[techsalvager]

in maf mode I would suggest turning the VE table into the MAF commanded fuel table.
I don't agree with using the ve table with maf sensor because a properly setup one covers its bases fine. People that have to add or mess with idle more then likely have improper injector settings or an install issue.
The current way makes the afrtarget table the commanded fuel table, so you lose functionality if you want to run closed loop fueling while using maf
I commonly run stoich into boost, but when I hit it I want the fuel to drop to a certain determined amount.
In reatlity you don't really need a commanded afr table, you could get away with a commanded power enrichement map and have mostly everywhere else be targeted at stoich or whatever set value you wanted.

going on eariler a maf setup requires two items
the load mafmap in this case to deal with load for spark\fuel
maf for the airflow

Obviously calc loaded follows the load\ engine tq output while the maf follows your horse power.

Baiscally you can have a flat map

normal operation map

Code: Select all

Lambda -  1      1       1     1        1   .95   .95  .95
RPM      - 1000 1500 2000 3000 4000 5000 6000 7000

Power Enrichment map

Code: Select all

Lambda -  .95   .90     .90   .85   .82  .82   .78    .78
RPM      - 1000 1500 2000 3000 4000 5000 6000 7000

closed loop map

Code: Select all

Lambda -  1      1     1.05  1.05   1    .95   .95   .95
RPM      - 1000 1500 2000 3000 4000 5000 6000 7000

Since the Maf tuned properly doesn't require a ve table we are wasting a lot of space that could be used for other stuff.
We really don't need these tables like 16x16, 12x12 to do maf tuning.

PE ( power enrichment ) would be enable either with TPS or calc loaded or both at certain set points

TPS vs RPM PE enable table

TPS% - 70 70 60 50 40 30 30 30
RPM - 1000 1500 2000 3000 4000 5000 6000 7000


MAFMAP - this needs to be renamed. It has no relationship to map, its a calculated loaded and when working correctly it does not come close to a map reading.

MAF lag factor needs to be separated from the map lag factor

Anything that has a map operation should have a calc load operation (mafmap)
fuel decel cut off \ overrun
table switching
ego control
knock sensor settings
etc


Baro correction should have the option to use the built in map port for those who don't use the map sensor for speed density operation.

A 32 point user editable voltage vs airflow table that can be live edited would probably suffice and I would suggest a trial of this. Ultimately the 1024 user editable file has better tuneability but can't be lived edited and has only a few live changeable points in the calibration correction curve.
I suggest staying with grams a second as its the common metric going between manufactures, chevy, mazda, subaru, toyota, etc.

Tunerstudio needs default voltage guage atlast to the x.xx digit, grams a second ( airflow ) needs to be also to x.xx digit atleast.

[techsalvager]

lbs/min and full GM MAF support (if it isn't allready).

can you explain what you mean by full GM maf support?

[techsalvager]

I'm not sure how but it would help to have the frequency MAF's be as similar to 0-5v MAF's as far as calibration curves and such.

ie. they use the same calibration curve, but there is an option to pick 0-5v and frequency. And this would automatically change the units of the curve to hz instead of g/s. (don't have a frequency MAF so I'm just guessing on units)

ie. they use the same calibration curve, but there is an option to pick 0-5v and frequency. And this would automatically change the units of the curve to hz instead of "voltage". (don't have a frequency MAF so I'm just guessing on units)

[charged3800z24]

lbs/min and full GM MAF support (if it isn't allready).

can you explain what you mean by full GM maf support?

Last I heard the GM MAF wasn't supported in any final release. I didn't see it mentioned in the manual either. That's why I said (if it isn't all ready). My 3800 has the MAF built into the Throttle body and would be a much easier install

[techsalvager]

lbs/min and full GM MAF support (if it isn't allready).

can you explain what you mean by full GM maf support?

Last I heard the GM MAF wasn't supported in any final release. I didn't see it mentioned in the manual either. That's why I said (if it isn't all ready). My 3800 has the MAF built into the Throttle body and would be a much easier install

any voltage based maf is supported currently. If there is no actualy maf transfer function that means you will have to create your own.
I have a guide on where to start with doing that.

[jsmcortina]

lbs/min and full GM MAF support (if it isn't allready).

can you explain what you mean by full GM maf support?

Last I heard the GM MAF wasn't supported in any final release. I didn't see it mentioned in the manual either. That's why I said (if it isn't all ready). My 3800 has the MAF built into the Throttle body and would be a much easier install

That's because there isn't yet a manual page for MAF on MS3.
EDIT: The MAF frequency input feature is in the pre-1.1 beta code.

James

[elaw]

in maf mode I would suggest turning the VE table into the MAF commanded fuel table.
I don't agree with using the ve table with maf sensor because a properly setup one covers its bases fine. People that have to add or mess with idle more then likely have improper injector settings or an install issue.
The current way makes the afrtarget table the commanded fuel table, so you lose functionality if you want to run closed loop fueling while using maf
I commonly run stoich into boost, but when I hit it I want the fuel to drop to a certain determined amount.
In reatlity you don't really need a commanded afr table, you could get away with a commanded power enrichement map and have mostly everywhere else be targeted at stoich or whatever set value you wanted.

I have to disagree with some of this.

In an ideal world, the MAF sensor would give a perfect reading of the air entering the engine, and the ECU would give perfect control of the fuel, yielding a perfect mixture. In the real world, there are a number of things that can potentially interfere with that. An imperfect airbox setup can disturb the airflow through the MAF sensor, causing it to read incorrectly. Obviously the ideal fix to that is to correct the airbox setup, but with space limitations that's not always possible. In addition, PCV and canister purge can introduce fuel and/or air that's unmetered. Having the VE table available to make corrections allows adjustment for these factors, leaving the AFR table for its intended purpose - to control the AFR and nothing else.

I also don't see what functionality is lost when running closed-loop? If you have things set up properly, the AFR target is factored into the fueling equation, bringing the mixture close to ideal instantaneously, then the closed-loop works to "trim" the AFR to exactly the desired value.

[jsmcortina]

techsalvager, when I write the MAF manual page for MS3 (and MS2/Extra) all will become clear. You can use VE2 as a fuel trim table and leave the AFR table real.

James

[techsalvager]

elaw I've explained a few times around here what funtionaility is lost.
Using MAF or MAFMAP fueling your AFRtarget Table is your commanded fuel table
Changing your afrtarget table values is how you specify what you want the fueling to be at.
In this case you lose the ability to have a separate fuel table and closed loop fuel table as they are both the same.
You ask whats wrong with this? I don't always want to target .85 lambda at 2000-3500 rpm and 80% load, Sometimes I want it to be at 1 lambda at that load.


Closed loop operation should deal with anything extra like if you have canister purge or pcv not some VE table.
My suggestion is to make VE table 1 become the commanded fuel table in maf\mafmap mode.

Upper and Lower bounds for the maf sensor.
Under or Over this much for certain time ecu knows the sensor has gone bad and can swap to speed density or alpha N

[muythaibxr]

Techsalvager:

You can do more or less exactly what you want by making your secondary load MAFMAP and tuning using VE table 2.

Ken