If you dealing with psia, though, then you won't ever need to worry about baro, since it is incorporated in the psia value. You would only need a baro measurement if you want certain tables or calculation based off of psig, like if you wanted something based off of boost pressure.

 

From my experience, you want the IAT sensor in the plenum of the manifold, in the direct air stream. You want the sensor to “heat soak” because under the conditions that cause the sensor to heat soak, the air velocity is low and the intake manifold is heating up the air considerably anyway so you want to accommodate that “heat soak.” I made the mistake of putting an IAT in a charge pipe once and I ended up chasing my own tail for a couple weeks trying to get a stable tune that wasn’t subject to enleanment issues after stopping from a freeway cruise. Tossed the sensor in the plenum and the car ran nearly perfect A/Fs from that point on, regardless of how hot the motor was.

Acceleration enrichment is another issue with MAP based systems. From what I have experienced, if you have a good solid map built up, you almost don’t need acceleration enrichment. I have it nearly disabled in the cars that I have tuned and it only becomes active on very large throttle movements. It’s worth putting in though. You want it to act very similar to an accelerator pump in a carb where a change in throttle position gives you a change in fuel, the larger the change, the more fuel. A straight 2D table with delta throttle on the x-axis and an additional IPW being the y-axis seems to work well. You also need to be able to dictate how many cycles or a time that the additional enrichment is applied for.

 

The only thing I've seen a baro correction effectively used for on a turbo motor is for compensating for the higher exhaust back pressure. Many high end systems have actually gone over to directly measuring exhaust back pressure for this purpose instead of trying to indirectly compensate for it.

On an N/A systems with big cams and ITBs, they typcially use TPS instead of MAP for the main fuel axis and then use the baro reading to scale the whole table.

 

well, we do know the exact ammount of air going into the engine right now, don't we?

however.. I think we should concentrate on removing the load from the equation and supstituting it with a MAP signal.. as for the fuel, you can keep the AFR and do a closed loop patch for the ecu so that we can map the whole thing with a wideband... then that map is converted, in the ECU, in injector timing... you could have the ecu map be in injector opening time, and have a separate piece of SW on the PC running the wide band and changing the injector timing on the fly to correct the fuelling in order to hit the target AFR... once you do it, you do not have to repeat untill you change the VE of the engine.. (different turbo, cams etc..)

this way you do not have to calculate the airflow at all.. of course you should keep some sort of baro compensation... but that could be a simple 1D table..

as I said, the only problem I see is Mivec... first it is run as a load vs RPM, so it could be MAP vs RPM... but it will change the VE during operation..

cheers

vlado

 

Mivec could be handled in two maps using linear interpolation, but probably better to have three.

Low, mid and high advance with binomial interpolation in between based on cam position.

I have to wonder what interpolation method would work better for the fuel mapping. Would linear interpolation increase the ECU process speed enough to offset the error that may be ran into by allowing you to maybe make two complete calculations for every fuel injector event?

 

User definable tables for the IAT sensor and MAP sensor would be ideal. This would allow various sensors to be used.

For the IAT I believe you could get away with a two value table, Beta and Ro. These are parameters that characterize a thermistor to the equation R=Ro*exp(B/T-B/To). The disadvantage here though is that you would have to write an equation to use these values to calculate the temperature based on the voltage feed into the ADC from the thermistor circuit. With it being an exponential based equation, I assume you would want to use some Taylor series expansion, which gets a little more involved? A less taxing way, I assume, would be a 2D look-up table that used either linear interpolation with more values or binomial interpolation using fewer values?

For the MAP sensor, a simple offset and scale parameter could characterize most any sensors we would be interested in and simple linear interpolation would take care of the rest. It might be less intuitive to setup, since you aren’t programming a 2D input table, but it seems like it would be more straight forward and use less memory with equal or even less processing requirement since interpolation in a 2D table would still be needed?

EDIT: Sorry for the abundance of posts, OEM ECU based speed density would be the cat's meow for the EVO though and I'm happy to do what ever to help. Dontations? Info?

 

^ yeah I plan to implement (or hijack) the sort of voltage -> scaled IAT/MAP output.

I am not sure how MIVEC impacts on this apart from changing VE- in which case it becomes a VE tuning exersise rather than a code/ECU behaviour exercise.

My plan for the IAT (or CAT as it really should be called) is to place it in the same place as this picture below:
http://backoftheenvelope.blogspot.co...p-and-iat.html

Anyone see an issue with that?

OK, this is my todo list so far:

1) Get the IAT installed
2) Get the IAT AND MAP sensor feeding into 2 (one for each) 2d tables that convert voltage into a Temp OR Psi - this means it doesn't matter WHAT sensors people get as they can customise then.
3) Get the ECU producing a g/s value for the mass of air(is that the correct terminology) going into the engine - Well aware that MrFred has already done this - But if I do it myself I will understand it all better

This still leaves the main part of the project which is to decide whether to go MAP axis OR use the g/s from above as the axis or whatever...

I also think that Acceleration Enrichment shouldn't be an issue as we are basically instantly updated on how much air is going into the engine so we can inject more/less fuel - Be good to get this point clarified.

One other thing - how does timing change with MAP vs g/s - ie does less air mass mean we can run more or less timing, or is it irrelevant - it it all about cylinder psi (ie MAP)

 

timig usually works best as a simple MAP vs RPM map... as that will take care of different VE engine has at various rpm's (remember, even with just an ordinary cam the engine can be "on the cam" or not.. VE changes during the RPM band)

accel enrichment is not an issue, but do not know about lean spool..
may I suggest you download the mapping software fot DTA standalone and see how those maps are organized, that is a pretty good and simple standalone..

 

This is one of the main reasons why I would like the axes to stay as a g/rev value. Timing is a function of mass aiflow/rev, not necessarily boost pressure. The same boost pressures in colder temperatures or greater VE RPM ranges will result in much higher mass airflow, and thus much higher cylinder pressures.

You either have your axes as map, which makes it look nice and easy to read, and have all of your adjustment tables that need to constantly be tweaked or you have your axes as mass airflow/rev, which includes all of the calculations already. You can still have the tables adjustable, like VE, for the fine tuning, but at least the temp and pressure is already in the axes.

Of course, this is only my opinion, and it looks like many more people favor a MAP axis, but it would be much more 'meaningful' to me if were a mass airflow axis and weather changes, etc, shouldn't affect your tune as much.


Eric

 

i would prefer a mass airflow also

 

Ok that's something I don't understand, airmass (g/s) is a function of RPM, so why would you use that as one of the axis's and rpm as the other axis?

Or is this what you mean by g/rev as opposed to g/s?

 

I think he means g/rev.

g/rev is merely a calculation of a VE, temperature compensation, and MAP along with engine speed and displacement.

You tune a table for AFR based on a RPM and g/rev and use a separate 3D table based on RPM and MAP that outputs g/rev. The second table is essentially a VE table.

Or you do an AFR table based on RPM and MAP and a separate 3D table based on RPM and MAP that is a VE table.

You're doing essentially the same thing, but IMO, it makes a lot more sense to do a VE table based on RPM and MAP and an AFR table based on the same thing. The numbers will make more sense and the graphs will make more sense visually as well. You can also lock the scaling of the two maps together to keep things less complicated. Otherwise, you'll be jumping from kPa to g/rev between maps. Which brings up another point, if you keep things in SI units, I think you'll be better off. If you want to see PSI, I would probably do it in the logging equations but leave all the ECU parameters in SI units.

If you try to do RPM and g/rev, you'll see that you are traversing cells diagonally despite holding a constant boost pressure because the VE changing across the RPM range will cause the g/rev to change as well. It's seems like a quick way to make tuning a little more cumbersome to me.

 

You could always try to make another 5 volt map sensor fit into the MDP hole you know tephra. Plenty of them out there including the one i'm using on my zeitronix setup.

BTW that paper of calculation substitution for Fuel mass as related to airmass over fuel ratio help you out?

You know if you wanted to figure out the VE of an engine it would be as simple as using the AFR via a wideband sensor and a bit of calculation substitution to come up with the real time VE.

Really its all a matter of what sensors you have and how you plan on making it work. You could i guess use a ball park VE kinda like the fuel trims and use a wideband sensor to find out how off it is. I think many system work like this.

 

Roadspike - It did, but I am still understanding all the issues in my own head

I want to make this as user friendly as possible so that everyone here can use it without a manual

So 03whitegsr - You are advocating the MAP and RPM on the axis for Fuel and Timing maps approach, rather than g/rev and RPM?

When you say Doesn't g/rev mean grams per rev? so therefore RPM has nothing todo with the calcuation (except for the VE of the engine at that current RPM)

But technically this is correct, same boost but better VE means a higher mass of air which means a different timing... I mean its still all going to be a 3D map...

 

Understood tephra.

As far as what should be used for the scaling i would simply use whatever other speed density tuning setups use. This will provide more documentation to the user since they can extrapolate how to use the device from other known sources of tuning material.