Mitsiman

This is a great thread and one that I will have to re read through again. In Australia our lancers, the equivelent of your Oz models in the USA, run a restrictor plate on the MAF sensor reducing the amount of air into the MAF by around 50%.

I want to be able to remove this "Restrictor" and this discussion is exactly the way to do it I beleive.

Would be great to find out if the USA "Oz" models with the 4G94 are also running a restrictor plate in the MAF sensor. If someone can pm / email me a base map from there vehicle it would be a great chance to compare the two.

Meanwhile. I will re read this thread again and really try to get this one under into my head.

shadow1

iTrader: (38)

Fostytou - so are your fuel map "AFR" numbers closer to your measured wideband numbers post MAF scaling? Would you say that your tune is better? I researched this recently, and from what I have read, MAF scaling is more accurate if you base it on airflow (eg, g/s or L/Hz) as oppsed to AFR like what you have done.

fostytou

iTrader: (15)

Well, if you look at the first image I posted my AFR map #s were relatively close in-spool. I think I go a little leaner up top, but as a function of the fuel pump being a single, not necessarily the airflow calc being off.

So far I've only done 1 pull and ~30 minutes of driving. The pull was definitely more accurate and the car drives much better. My only problem was the [first try] cold start this morning was really wacky going lean enough to die unless I was gassing it for the first couple of minutes. I'm not sure if that was as soon as the startup IPW decayed or a function of the timing reduction kicking in, but I definitely need to look at it.

The only other function I've used was back in my DSMLink days I scaled the MAF to match actual boost to estimated boost (which was a function of airflow). This worked well for WOT, but not as well for low throttle. At that time I just had a friend visually compare LTFT current and the short trim value while driving at the different AirflowHz and estimate the correct change. That definitely required a knowledgeable helping hand though.

Do you have any links describing your method?

shadow1

iTrader: (38)

Here is a link:
https://www.evolutionm.net/forums/ec...ing-table.html

fostytou

iTrader: (15)

That stuff is 2+ years old. It was good at the time, but I think we are beyond that at this point. He is essentially doing the same thing as I am there, just going through extra calculations to confirm findings about the MAF as far as I can tell. I don't see his connection between calculating those values and what he actually changes, so I'm not 100% sure.

Either way, if you are trying to get AFR to match AFRMap, my method should work just the same (now it is just a matter of which table is better to apply it to).

shadow1

iTrader: (38)

Keep us updated. I will attempt the same when you get this figured out!

shadow1

iTrader: (38)

One observation: if you base your MAF adjustments on AFR, those adjustments will change the wideband AFR readings. This will of course throw off your fueling. If you adjust the fuel maps then your MAF adjustments will be off again. You could go round and round forever like this. I do believe that the MAF has to be scaled/smoothed via airflow, not AFR. In the ideal world, a perfectly scaled MAF ought to let you just enter an "AFR" number of 11.2 in all your fuel cells under boost and result in 11.2 as measured on the wideband.

fostytou

iTrader: (15)

Right, but I'm not just basing it on AFR, I'm basing it on AFR compared to AFRMap as a percentage difference. This is the first time I'm using this method, as in the past I had a helper to tell me when I was at an airflow point and that allowed me to collect alot of data at that point.

In any case, no matter how well the car is driving I got to take it out for a long trip yesterday, and the LTFT low is closer, however the mid is further off. One thing my calculation method does not allow is the ability to capture every sample the engine does since MUT logging is so "slow". This creates a problem since you may, by chance, sample more often when the AFR is on one side or the other (for cruise and low driving). This is why the more data you have, the better... however excel has limitations here. This should apply when using this method or using the LTFTC+STFT method, so I think I may need to find a helper again and use a looser human visualization rather than a calculation for some of the lower airflow points.

I'm going to try to apply my calcs to the compensation table first and see how that goes. I will report back....

shadow1

iTrader: (38)

For closed loop fueling, fuel trims are sufficient to scale the MAF since the ECU is targeting 14.7 for the AFR. However, fuel trims won't help during open loop fueling. Hence we need to measure actual airflow compared to predicted and correct from there. Maybe I'm not understanding what the AFRMAP number represents? I thought AFRMAP is what the ECU thinks the AFR should be. If that is the case, then what I stated above is the flaw in your method.

03whitegsr

iTrader: (8)

Shadow, I could care less about how "accurate" my MAF is in an absolute sense. By matching AFRMAP and actual AFR, 11.2 in my fuel map will give me 11.2 in actual AFR.

All this talk of STFT and LTFT corrections is a waste IMO. Just throw the car in openloop and drive around while logging. Trying to tune the MAF with closed loop active is just going to complicate the situation since your fuel trims will actually lag behind what the engine is really doing and won't do it in a 100% repeatable manner.

With talk of all the new MUT channels though, I have to wonder if we could log the accel/decell enrichments and possibly a fuel cut channel (???) and use that data to greatly improve the "accuracy" of tuning the MAF. The real issues while rescaling the MAF is trying to determine what operational states reflect reality and which states are being affected by other corrections. For example, 3500 RPM throttle closed while coasting downhill will invoke fuel cut, which will make the AFRMAP sit at 14.7 but actual AFR to go max lean. This creates a huge error which will throw off your data.

That's an extreme case though and fairly easy to filter out of the data. I think the bigger issue is the more mild enrichments. Being at 2500 RPM and stepping on the throttle to 30% will likely give you a decent amount of accel enrichment. Now you are mixing accel enrichment into main fueling. Add to that the slight delay you get between wideband reading and OBD-II reading and it's pretty easy to get erroneous data.

shadow1

iTrader: (38)

03whitegsr - Are you implying that you would just leave your car in open loop all the time? That would waste gas and pollute the air. In your downhill scenario, AFRMAP would be irrelevant in closed loop fueling. Interesting last point though. Unfortunately the gurus are still trying to sort out the accel enrichment tables and tuning.

fostytou

iTrader: (15)

I use AFRMap because I'm using MrFred's wideband based o2 feedback / narrowband sim.

Driving in open loop is just fine if you are tuned properly... if it is for tuning your car to run better then you are wasting less gas and polluting less also... gotta be in it for the long run.

I posted the flag for "acceleration" in another thread (same MUT request for clutch in, its custom but tephra posted it a few years back). Not sure what it defines exactly though... some testing would be great

fostytou

iTrader: (15)

Something I noticed. I think that LTFTC goes to 0 when you are in decel (but not necessarily fuel cut). This along with the accel flag I posted about could be used to get a better data set.

Another thing I had thought about, but hadn't taken into account was that AFRMap is instantaneous while actual AFR isn't being sensed until sometime later. The time-shift will obviously be different at different loads/airflows, but I imagine it is much more effective to log AFRMap, then AFR just after or shift your AFR column down one row relative to AFRMap at high load. This is my more main concern with the % error for the method I'm using.

Might be smart to switch to narrowband temporarily to get this tuned and use STFT, then switch back.

Switched to the compensation table today also. So far it looks like the "weight" of a percent is slightly lower here than using ((adder + scaling) * percent) - adder. This is actually a good thing in that a ~6% reduction there produced a ~10% difference in trims (for me). The compensation table seems to be somewhere right in the middle. I still have some more logging to do to confirm this though.

I'm still not sure where you guys got the percent128 thing from though. I don't know if the "accuracy" of this method is just a side effect of those values being *near* 100% or if there is actually some correlation there. I'm going to see if the difference based on % delta (as uint8) and % subtracted (as scaled percent128) are close at a later time.

No comment yet on whether or not using compensation instead of scaling has helped cold starts, I should be able to give info within a couple of days.

03whitegsr

iTrader: (8)

No, I am not suggesting driving around all the time in openloop. I'm suggesting you tune this table while in openloop, then put the car back in closed loop when you are done tunign the table.

AFRMAP is NOT irrelevent under fuel cut when you are trying to tune the tables because it gives you a huge error between what the AFRMAP value and the actual AFR. This error then works it's way into the data you are trying to use to tune the tables and affects your results.

Percent128 is just y=x/128*100. Thus 128 gives you 100%, 0 gives you 0% and it's linear inbetween.

From JCSBanks thread, the MAF Smoothing table is a multiplier and then some where on down the line it is divided by a constant of 128 (or some multiple anyway). Sclaing as percent 128 makes it a direct multiplier and a 10% change in the MAF Smoothing table WILL give you a 10% change in AFR.

A 10% change in the MAF Scaling table will give you something closer to a 6% change in AFR.

fostytou

iTrader: (15)

To follow up, after another 30 minutes of cruising my mid LTFT went to 12.5 (maxxed)... so the weight was actually higher using comp as %128 and directly subtracting my %. I spent some time in traffic, so that could have skewed the results but I was mostly in LTFT low areas.

I looked at the calc and I must have missed the constant of 128, that one was tough for me to digest so I probably looked over it. Gotta run to see terminator so I'll report back more later.