By saying this are you implying that you should use/log the realtime VE in order to see if the computer is acurate and if it isnt then should you adjust accordingly taking into consideration your LTFTs are in order?

 

I wouldn't use the LTFT's as a metric at all for the VE table - I would bring them in line with whatever combination of maf/ifr tuning that you prefer - but keep all the scaling to a constant factor (don't change the shape of the ifr table, etc. - just its' "offset")

The I would use the formula's presented above to calculate the VE. When your car is no longer completely stock you can't really test for accuracy as the VE *should* be different. Hopefully after you have done this your l-trims will deviate less from one another - but I still wouldn't use them as a basis for making the change.

 

Im looking forward to testing some of this information on larger engines (382+ ci). The VE may change, causing tuning difficulty with a simple IFR scalar. In trying to create power, I dont think driveability with larger engines has been thoroughly fleshed out. Thanks for doing alot of the mental work with this stuff. I understand it fine, and consequently appreciate it all the more

chris

 

It also proves to me once and for all that the stock computer was *never* meant to run turbos, and will never do so perfectly

 

Agreed.
It seems that boosted engines can be tuned well enough with the various band-aids provided with Edit, but precise tuning is beyond the capabilities of the stock pcm.

Richard

 

I think it's also interesting to note that the above formula's are evidence in them selves that the computer (MAF based) doesn't *need* ve tables (since it was demonstrated that you can calculate VE in real time from other unique data).

No no doubt(anymore ) the VE tables do come into play, so GM has to have had some reason for putting them in there - the only thing I can think of is that the MAF isn't responding fast enough to cylinder dynamics, so the tables are a sort of hedge against that - or that it would be to computationally expensive to calculate the VE in realtime (don't know the abilities of the processor), and the VE factor is used as a sort of "charge quality" indicator to better maintain an actual desired a/f ratio.

 

Simplicity (KISS principle).The same equation with identical end results for given variables equals = constants. Constants-> Table. Not trying to be a smart ***. I'm an old Non- computer type guy. Seems logical to me. However, I now see that it would be fairly simple to provide a continuous stream of "constants" and result in more ideal (precise) fueling. DUH! Thanks ChrisB!
joel

 

I dont think that the calculation is computationally too expensive... it seems too simple to require many clock cycles. What a table does though is pin the computation in the middle and localize error. If the equation were allowed to float on sensor data form end to end, the introduction of error would be amplified. Im trying to think way back to engineeering statistics classes, and it would seem to me that you should tie some of these equations to constants. Perhaps sensor response times and such created resonances and an unstable system.

I like the idea that we can gather data, attempt to use time and volume to reduce sampling error, and come up with our unique VE, which we can enter into the table and pin the equations with. zI guess the only remaining question i have is; Are the number of RPM divisions in the PE field enough? Not that we really have a choice

chris

 

About ChirsBs (actual airflow ratio compared with barometric) and Nogos (actual airflow vs. MAP, or intake manifoldpressue) method of computing actual VE...

Most all intake manifolds should see very very close to barometric presssure at WOT, as do most LS1s, so I could see where just using baro. would suffice.

In the case of the bigger motors (420 ci. +) however, arent some guys experiencing pressure drops at high rpm? In that case would you want to use the pressure ratio of inside the manifold? But being the manifold is technically inefficient at that rpm on a big motor, that would give you inflated numbers correct?

Or would the MAP kpa/101.3 pretty much take care of the loss of presure compared to atmospheric/

 

The formula I posted should correspond to NoGo's with the included addition of temperature as a factor. That is the one that seemed to me also to best fit the ls1's stock curve. If you want to check it out vs. barometric pressure just replace the MAP term with barometric pressure (in kPa)

The point you are missing I think is that the table works (and is the most noticeable) at part throttle also - and here you have a huge restriction due to the throttle blade itself. Basically when you use manifold pressure as the reference for VE you are measuring puping losses from the pressure sensor to the cylinder - if you use atmospheric as the reference you are measuring pumping losses from the atmosphere to the cylinders.


Re: needing the VE tables - if you use a formula you effectively have an infinitely granular table - you don't have to interpolate for points that are inbetween your lookup points as the formula gives you the exact answer - so the formula based approach in that sense would definitely be superior.

I honestly don't know, but I don't think it's to prevent problems with bad sensors, etc. - the MAF is going to be the primary factor in the VE formulae as well as in stock fueling - if either goes dead then the car is going to run like ****. Now if you have a separate VE lookup table you can reference that if the MAF dies - which is an advantage. I think any harmonics introduced by the continues sensor inputs would be resolved by "tweaking" the model itself. Just add a dampening factor if you need it.

The other question still remains though - what exactly do we need the VE table for - the MAF tells us exactly how much air is inducted - so we now how much air is in each cylinder (the basis for the top of the VE equation) - if you know the mass of the air in the cylinder, your desired fuel ratio, and injector flow rate you know exactly how long to pulse the injector to get that fuel in there.

So what exactly "real world" phenomenon is the VE table compensating/modifying for? Definitely not VE in a classical sense, as the MAF makes that uneccecary. Again, the only thing I can come up with is charge quality - as we are shooting for a perfectly atomized yyy A/F ratio, but due to this being the real world that doesn't always happen.

For this to work though the VE would have to be proportional to charge quality in some sense - well, in a way that required reduced fueling as VE goes down, and increased as VE goes up (as a bpw modifier).

Or it could be some other factor I am totally missing - I am just trying to figure out now the reason for inclusion of the VE factor in MAF based fueling?

 

Supposed this: Your driving at WOT, and drop to 15% cuise state throttle.

The MAF would have a high air flow rate - I dont think the air mass would instantly STOP - but the MAP would be a real large vacuum not close to baro like a high MAF flow situation would indicate. That would cause a fueling erro right/ Maybe the results are averaged, or one takes precidence over the other to cover sudden throttle changes?

Or are my assumptions that it would take some amount o time for the ir mass to lose velocity before the intake manifold pressure drops to vacuum incorrect?

 

i'm lost here.

tried making a calculated pid by doing the following

VE = (MAFFlow * (Temp + 273.15) / (Displacement * RPM * MAP) * 212544)* 30

mafflow being the MAF pid in efilive
temp being IAT
displacement .2
rpm being the rpm pid
map being the map pid

when I do this I get values in hundreds of thousands. way off.

what am I misunderstanding here?


thanks!!!

 

DO you have all your units right?
Temp/IAT in celsius?
MAF in gms/sec?
MAP in kPa?

 

What am I missing here. This is using efi live v6


*CLC-00-906
% 0.0 100.0 .2 "{SAE.MAF.gps}*({SAE.ECT.C}+273.15)/(43.25*{SAE.RPM}*{SAE.MAP.kPa})*212544"


TIA

I think I may see the problem. I used ECT instead of IAT and maybe a parentehses issue

What about this corrected using IAT and parenthesis for clarity

*CLC-00-906
% 0.0 100.0 .2 "(({SAE.MAF.gps}*({SAE.IAT.C}+273.15))/(43.25*{SAE.RPM}*{SAE.MAP.kPa}))*212544"

 

at first I did indeed have the wrong units.
i switched them but still getting the same results?
i wonder if I need to delete the pid and recreate it now that I switched units? hmmmm I will go try that.

 

Actually I tried to make the formula simpler - the displacement here should be for that of the entire engine.

Try

{SAE.MAF.gps} * (SAE.IAT.C + 273.15) / (347 * {SAE.RPM} * {SAE.MAP.kPa}) * 212544

all you need is that one set of parentheses

 

Don't forget the curly braces around the {SAE.IAT.C} PID or EFILive will treat the PID name as {SAE.IAT.C + 273.15} and complain that ther is no IAT PID with units of "C + 273.15".

Regards
Paul

 

Thanks that fixed it now when i get edit (hopefully sometime next week) I will do some cross checking

 

ok I got the ve pid working. now to sound really stupid.

now that I have all this data what am I doing with it?

am i supposed to build a table with the data to look like edit with map down one side, rpm across the top, and the ve values in the middle then compare this to the table in edit and shift the edit values towards the values I got when datalogging?

 

See [Dash-C] in EFILive?
In the next release of V6, that will be where you will be able to create parameter MAPs. Meaning, you choose the PIDs for the x and y axes and a parameter to plot in the map and EFILive will show you the recorded values for the selected PID based on the x/y PIDs' values. Exactly the same as the spark and fuel maps in V5 but instead of being limited to spark and fuel they will be fully customisable.

We are working on 3D imaging for the maps so you will be able to see them in wire frame 3D - sort of like a contour map of your parameter.

Paul