Personally, I like to think of the values in the AFR table as actual AFRs and not just some arbitrary numbers that you increase or decrease to lean or richen the fuel mixture. By scaling the MAF (whether running SD or MAF) you can achieve this pretty well.

If I understand the point you are making, you are saying that tuning fuel by MAF scaling doesn't account for changes in VE . However Load is proportional to airflow/rev so if the rpm changes the load value will change anyway (all else being equal) and it will put you in a different cell. The changing load actually is accounting for the VE change. True engine load and VE are really measuring the same thing.

Not saying I am right here, just trying to reason it out in my head. At any rate it works pretty well in practice,

Also, your fueling still has IAT compensation just the same. Remember this is really no different than MAF scaling while running a MAF.

 

I'm excited to give a whirl to a new form of code. Hope the 3d load table ends up being written .

Killer and I were just discussing his sd potential conversion. I keep thinkin of this new model because it makes very much more sense to me atleast, and new sd guys will be able to grasp it a lot better than before I believe.

 

When you disable "lean spool" you'll find the stock AFR map is VERY close to what you actually measure with a wideband if everything is right in the car with a stock intake system. Until you go past 1600Hz anyway (which is like 10psi). I agree 100% here, the fuel map is an lambda compensation map and is not arbitrary values. I feel that was the intention of the factory and that feature should be maintained with a SD hack. This idea the factory would spend millions on developing this software and use arbitrary values ANYWHERE in the ECU is absolutely ridiculous.


Nope. What I'm saying is, the MAF tables are only to convert MAF frequency into an airflow. This is done because the MAF is non-linear at low airflow rates. It's the physical limits of the MAF sensor. If you no longer have a MAF, why are we maintaining this non-linear compensation that has absolutely nothing to do with a MAP based system?

You also have a density correction table that kicks in at low airflow rates. You also have MAF filtering that changes depending on MAF frequency. Ideally, eliminating the MAF code altogether and getting rid of all these artifacts could potentially resolve the random stutter issues that have been seen. It would require a through look at the code though, and not just the MAF code but lots of sub-routines that split based on MAF codes.

LOTS of work.

 

Just thought I'd put up a visual to show the difference in the two methods suggested. These maps are identical in function. The engine airflow model represents engine VE where the Load Look Up Table represents the direct load look up method being suggested.



There is no comparison about which is easier to use and easier to see tuning issues on. The VE table is the better solution, OEMs and high end aftermarket ECU companies see it the same way. The direct lookup is an artifact from the old IPW lookup days and is a waste of time considering the minor code change differences.

I get where you guys are coming from where you are simply trying to make tuning easy by lining up MAF load and SD load. I just think it's the wrong way to do it. If you are knowledgable enough to tune a car properly in the first place, I really don't think this method is ANY harder to the novice but it actually makes sense to tuners that get paid to tune standalone engine management systems.

 

+1 for visuals!

For direct load look up if you don't have a maf would you not be able to tune it properly ?

Or just linearize everything ?

 

Without a doubt the load lookup table makes it easier if you are tuning a car that already has a good tune on MAF. If you are starting from scratch then it doesn't matter much.

What I don't like about the VE model on the Evo stock ECU is that it is not a true VE model as a standalone would use. With a standalone, all adjusting VE does is increase or decrease fuel enrichment. It doesn't change the lookups for timing and AFR (the fuel and ignition tables lookups are only determined by MAP and RPM). With the EVO SD implementation changing VE changes load and therefore does change the lookups as they are determiend by load and RPM.

 

With basic standalones, you are kind of right. You are referring to VE based fuel look ups, but I am referring to airflow based engine management systems. They are different.

You are completely wrong on the better ECUs and OEM ECUs for that matter (although VERY FEW use MAP any more). Higher end ECUs have the capability of running engine airflow model systems. The reality is, engines aren't really sensitive to MAP for ignition and AFR. They are sensitive to cylinder fill density and heat. Having an airflow based system breaks down compensations into air density and heat better than an IPW lookup or VE Fuel lookup system.

AEM Infinity has this ability and it is a HUGE step for them in the right direction.

Lots of standalones started using "boost comp" methods which is an approximation of an engine airflow model based system on the fuel side but does not address ignition advance.

 

IMO, you'd need to use excel a ton and basically create that 3D VE map I have created there. It would be very complex though as you'd also have to include IAT comp and any enrichment comps to figure out your VE curve.

From a good MAF tune, sure, the load look up KIND OF makes sense in the form of a hack. You are manipulating the data to simply reflect a baseline. You have no idea if that baseline is right or not, it’s just the last know tune that worked.

After a load of about 80, none of this matters anyway as the ECU goes open loop and doesn't have any random compensations based on load. Below 80 though, you can definitely run into odd load conditions with SD that end up tripping other sub-routines. I think this was the cause of the idle issues I noted on numerous occasions. I would see a HUGE change in AFR as the car transitioned to idle conditions. My theory, the load was dropping low enough that it was triggering sub-routines that aren’t typically active. Could have been a temp sensor failure state. Some weird emissions sub. Who knows. Either way though, if it dropped load low enough to hit 13:1 AFRs at idle, the ECU would start cutting fuel randomly at idle and AFRs would go into the 17s and I would get misfires. The only option I had was to inflate the RPM VE values so that AFRs stayed in the low 12:1 range then I would no longer get these odd AFR swings. I ran open loop at all times so the ECU never hid this rich condition. I have a feeling this is probably very common, but most keep closed loop running so the ECU covers up this odd operational state.

Last I messed with it, I was looking at the EVAP stuff and some of the periphery bits and I was actually able to induce this lean condition under all operating conditions. I just never looked more into it to figure out which sub was causing it. I think the key to getting the engine airflow model to work would be tracking down these random compensations and getting rid of them. If you look at MrFred’s thread on the main IPW, you’ll see some comps that aren’t really well documented and I believe they are related to this issue.

 

We are getting off topic here, but I am not sure what the distinction is between a VE based lookup and airflow modeling. As far as I understand, with airflow based modeling, there is a 3D VE table (with rpm and MAP as the axes) that are used to determine VE. The VE table is used to estimate airflow (taking into account air temp, coolant temp, displacement etc.). There is also a 3d target AFR table that has MAP and RPM as the axes. So a lookup for target AFR is done and based on the calculated airflow the IPW is determined. I guess the difference may be that the lookups for fuel and ignition use airflow vs RPM instead of MAP vs RPM.

 

I don't think it would be a hack if you had your MAF tune down to the point that your target AFRs matched your actual AFRs. That should mean that your airflow model was pretty accurate.

BTW, I hope you are not finding my posts annoying, I'm just trying to expand my knowledge is all.

 

Yes, in an airflow based model, virtually everything is looked up based on load vs. RPM, instead of MAP, for fuel and ignition. This includes other things like accel and decel as well.

Yes, if you have a locked down MAF tune that had AFR target and actual AFR matching under open loop conditions, you would likely have a pretty close match to an airflow model. The one issue here though, there is a decent amount of accel enrichment that takes place below 4500 RPM with changing load and RPM conditions. This skews the map to some degree. If you were to use a statistical method, you'd need to either eliminate these samples with accel/decel enrichment or you'd need to compensate for them. The difficult part here though is the sample rate as I beleive the logging feature makes the request and then the ECU sends those values out at its leasure so you aren't getting time sync'd samples. The accel and decel stuff changes rather quickly so it would likely be hard to compensate for these changes. Also, you have a time delay with the wideband. I've been able to use a fixed time offset and greatly improve results there, but it's not perfect.

I've done statistical comparisons while on SD and that is actually how I've noticed the issues I've seen with SD. Even after eliminating the accel/decel data, time compensating the wideband, using a huge sample size, and using very controlled drive patterns, I've noticed the data has a huge variation band at low airflow rates. Below about 40kPa and 4000 RPM, the data is all over the place. In all honesty, I got the best results by simply tuning by feel at the low load sites as when I went by the statistical model, I never could get a good result below 40kPa.

 

It seems that SpoolinUp is ahead of the game and already has an updated SD harness with a plug for a stock 1-bar MAP sensor on the baro circuit. I guess I need to get this patch done.

Just as a heads-up, this is not going to be a free patch - its going to be part of a new ROM with many other features. ROMs will be keyed to the ECU and not transferable among different cars. However, no special software will be required to read, write, or log the ECU. Its taking some time to get this worked out.

 

mrfred,

Its about time, you deserve some compensation for all your hard work! count me in. Will you supply the harness as part of the patch upgrade and make it a package? Hint, hint.

 

Sounds good. Hope it doesn't take too long to come out. What other features are you looking at? I would love to see programmable outputs that could be used for water/meth, nitrous etc. or whatever tied into map switching.

Someone might have mentioned it before, but maybe you could have options for VE Maps in the ROM and you select which one you wish to use to satisfy those who rather VE% and those who prefer going straight to load , in a similar way to how you can select regular fuel cut or double fuel cut.

 

Making the outputs into general purpose outputs is a pretty tall order, but a few of them will have dual function. I do plan to allow the SD maps to be displayed as either VE or load translations.