VE-IFR transformation
In many cases, we don’t have the full set of information needed to create the fully correct, reality reflecting tables for everything. The final fueling decision is a series of multiplications and divisions, thus allowing for ‘the fudge factor’—we can account for imprecisions by artificially altering other values. MAP and TEMP are fed from sensors, so short of upgrading the sensors themselves, we don’t have a way to influence their precision. AFR is just an arbitrary divider that we can verify with a wideband oxygen sensor. As long as that sensor is properly calibrated, there’s nothing to fudge there either. VE or GMVE, paired up with IFR are very frequently used to make up for imprecisions. VE is not easily measured, and IFR as my recent fuel pressure investigations indicate, is more complicated that we originally thought. IFR however can be calculated, if we have enough data for it. So if we have all variables except VE and IFR, and we can calculate IFR, we should be able to arrive at a reasonably realistic VE. Since VE is such a crucial table, it’s worth the extra effort to arrive at the higher precision version of it.
Let’s start with understanding of what a good tune is: a collection of final fueling decisions that result in desired target AFR. No matter how much fudging in tables is involved, it’s possible to arrive at it the final figures in an infinite number of combinations—that’s what most ‘professionals’ tune, they do not concern themselves with the truthfulness of numbers, just with the final resulting AFR. While effective, I’d like to enhance our ability to arrive at the precise numbers that reflect reality.
Fuel decisions are nothing else but a set of Injector Pulse Widths calculated for every possible condition encountered in our engine. We calculate them using the formula:
IPW = GMVE*MAP/(AFR*IFR*TEMP)
So to convert from one set of parameters that creates a good tune, to another set of parameters that yield the same IPW’s, this must be true:
IPWnew = IPWold
So we expand both sides of this equality:
GMVEnew * MAPnew /(AFRnew * IFRnew * TEMPnew) = GMVEold * MAPold / (AFRold * IFRold * TEMPold)
And then solve it for the new GMVE:
GMVEnew = GMVEold * (MAPold/MAPnew) * (AFRnew/AFRold) * (IFRnew/IFRold) * (TEMPnew/TEMPold)
We notice that if the tune is good, if it preserves the final fueling, target AFRs will be the same, thus:
(AFRnew/AFRold) = 1
Temperatures are also the same across the full range, TEMPnew/TEMPold = 1
Same goes for MAP ranges, MAPold/MAPnew = 1
This simplifies the main equation to:
GMVEnew =GMVEold * (IFRnew/IFRold)
Also notice that since
GMVE = Vol * VE / R
and Vol and R are constants, thus:
VEnew =VEold * (IFRnew/IFRold)
This means this transformation applies to both VE and GMVE forms, allowing the same logic and methodology to be applied to LS1/LS6 and the newer LS2 computers.
The important thing to remember here is that while these equations work for singular values, these dependencies must be true across the full table.
IFRold-3D version
The easiest way to visualize that is by employing the histograms. We’re all used to looking at the VE table and IFR tables, that’s nothing new. Here, in order to multiply them all out just like the formulas would suggest, all the variables in question must be describing the same temporal instance in the engine. Then in order to perform the calculation, we also must have it in the same units. IFRold is the traditional IFR table, but viewed not in a traditional 2D way, referenced against Manifold Vacuum, but on the same axis as the VE table. How do we view it this way? The easiest way is to log GM.INJFLOW, and then make a custom histogram, starting with your basic BEN histogram, but then changing the data to be working on GM.INJFLOW, not BENs. This will give you a VE-like view of what injector flow the computer uses to calculate the final fueling. Displaying of the actual histogram is optional, it’s not mandatory for the final transformation to work, but it does help to understand what we’re doing here, and why do we need to grow a whole new dimension on a simple IFR table.
IFRnew
The tricky part is how we arrive at the IFRnew. As I found out from the Under (Fuel) Pressure write-up, Fuel Pressure varies not only based on Manifold Vacuum, but also on RPM and even smaller factors, like the Battery Voltage. Thus, to obtain the most realistic IFR table, we also must create a histogram that takes these variables into consideration, and then shape it just like the IFRold histogram we created in previous paragraph, to be able to do an element-wise division, for the final calculation. Just like IFRold histogram, this one is also optional, and one purely for educational purposes.
First we must log the Fuel Pressure. Hardware and setup necessary to do that is beyond the scope of this write-up, as it’s been wonderfully described in TAquickness’ document . Once we have CALC.FUEL_PRESSURE (or whatever other name you gave it, I’m going to use this name in this document for clarity), we need to create another custom PID that calculates the injector flow based on the injector rating, Manifold Vacuum, and the Fuel Pressure.
EFILive’s custom PID infrastructure allows us to do all this, and even have multiple units for the same entity.
First we add few units to calc_pids.txt:
*UNITS
#Code System Abbr Description
#-------- ---------- -------- -------------------------------------------------------------
PSI Imperial PSI "Pounds Per Square Inch"
KPA Metric KPA "kilo Pascals"
GPS Metric gps "grams per second"
LBPM Imperial lbpm "pounds per minute"
unit Metric unit "unit"
Then we create calculated PIDs for converting FP gauge voltage to PSI and KPA. This example uses GM.EGRS as the source of FP voltage, as per example in TAquickness write-up. If you have it hooked up through the external inputs, please refer to his manual how to adjust this PID definition.
*CLC-00-001Now we must calculate our own CALC.INJFLOW which is calculated from GM.MANVAC and CALC.FUEL_PRESSURE. Notice that in order for the calculations to make sense, they all are converted to kPa.
PSI 0.00 100 .2 "({GM.EGRS}*25)-12.5"
KPA 0.0 700 .1 "(({GM.EGRS}*25)-12.5)*6.89475728"
*CLC-00-002Notice that this is the place where we must hardcode the value for the rated flow and pressure of the injectors.
GPS 0.0000 30 .4 "42*0.125997778*sqrt(({GM.MANVAC.kPa}+{CALC.FUEL_PRESSURE.KPA})/(3*100))"
LBPM 0.000 200 .3 "42* sqrt(({GM.MANVAC.kPa}+{CALC.FUEL_PRESSURE.KPA})/(3*100))"
The 42 at the beginning is an example of a popular 42 lb/hr injector. This is where you insert the rating of the injector in lb/hr, and the conversion to g/sec is done for you. The rated fuel pressure is at the end, that’s the (3*100). Most injectors I’ve seen are rated at 3bar, and to convert from bar to kPa you just multiply by 100. So unless you have some really unusual injectors, you most likely will not need to change this, this is just for your information.
There are two versions of the same PID, this way we can display the calculated injector flow in both popular units for easier understanding.
Now set up another histogram, again with the usual VE axis (I like to use the BEN histogram as a starting point), and replace BEN’s with the CALC.INJFLOW.
Marcin Transformation Factor
We have now two histograms of IFR—one is the IFRold, and the second is IFRnew. We can create another calculated PID that will divide the two tables on element-by-element basis.
*CLC-00-003
unit 0.000 10 .3 "{CALC.INJFLOW.GPS}/{GM.INJFLOW.gps}"
And finish it off with the PRN section that binds all the previous definitions into coherent entities:
# ==============================================================================
*PRN - Parameter Reference Numbers
# --------------------------------
# See sae_generic.txt for more information on the *PRN section
#
#Code PRN SLOT Units System Description
#------------------------- ---- ------------ ---------------- ---------------- ------------------------------------------
CALC.FUEL_PRESSURE F001 CLC-00-001 "PSI,KPA" Fuel "Fuel Pressure"
CALC.INJFLOW F002 CLC-00-002 "GPS,LBPM" Fuel "Injector Flow from Fuel Pressure"
CALC.MARCIN F003 CLC-00-003 unit Fuel "Marcin Transform"
With the complete setup, we should create the final histogram—yes you guessed it again, on the same VE-like axis. This time, we use CALC.MARCIN for the data to histogram. You should get a histogram that has a bunch of values near 1.0. The more your Fuel Pressure was varying from the theoretical based pressure we used to use with the old IFR spreadsheet, the farther away from 1.0 the corrections are going to be. This histogram is mandatory.
IFRnew-2D
The other important thing that you can get from all these calculated PIDs, is the automatic creation of your new, Fuel Pressure based IFR. All you need to do is create another histogram, with CALC.INJFLOW as data, and GM.MANVAC as rows with 0..80kPa range with 5kPa step. This histogram is also mandatory. This is what you’re going to paste into {B4001} table.
Now you can copy the whole CALC.MARCIN table, and multiply it out with your existing VE {B0101} table, transforming it to account and agree with the IFR table that we just build in the paragraph above. Together, the new VE and IFR should preserve the final fueling, which if you had it perfect to start with, should carry over to the new setup.
Conclusions
While not instantly mind blowing, these concepts and tools have some deep consequences. Now you are able to convert any VE into another VE based on a different, hopefully better, IFR settings. This means, if you have a tune done by some hack tuner that jacked up your VE and IFR arbitrarily, you can log Fuel Pressure, and painlessly and without full VE tuning sessions, transform into a much cleaner, saner and meaningful, closer to reality VE and IFR tables.
Another application is playing with Fuel Pressure, or installing a new Fuel Pressure Regulator, on your already well tuned configuration. Normally, you’d have to start from scratch, and tuning VE yet another time. This allows you to be able to play with the FPR much more, looking for the perfect base and rising rate to compromise between good low pulse width idle quality, and regulating FP so at WOT you have a safe amount of fuel provided to the injectors. You can just try yet another IFR setup and see what it will do to your VE with no need for slow, ticket-prone retunes.
If you suspect your fuel system isn’t up to task, logging fuel pressure and histogramming it as described in this write-up will also show you the deficiencies. At this point you can either chose to just use the transformation described and account for the deficiencies, or go shopping for a more capable system. The important part here is, you don’t have to guess and eyeball anymore, you can quantify it and see it in black and white.
Side notes and Commentary
All of this is done in EFILive, no spreadsheets, no custom code, just utilizing a well designed infrastructure. This little exercise demonstrates just how powerful it can be. About 12hrs before I had the first functional Transformation Matrix, I never set up a custom PID. So it cannot be that difficult either.
On the other hand, we have HPTuners. I got some data with logged fuel pressure voltage, and while I was able to convert the voltage into actual Fuel Pressure, converting from BARO and MAP into MANVAC turned out to be outside of its reach. I’ve spent hours experimenting with it, trying to get it to work, with no results. I tried to refer to some other more hardcore HPTuners users out there, and not only they weren’t able to set it up, It also turned out to be really difficult to exchange the custom PIDs, as there is no clear configuration file containing such info. If anyone knows how to deal with these issues with HPTuners, please let me know, I’d love to have another version of document that explains it in HPTuners terms.
I highly recommend learning to harness the power of custom PIDs and custom histograms; this is how the raw data turn into information.
Special thanks goes out to a prof of mine, Mathias Kolsch, who in the process of teaching me Computer Vision, gave me lots of new tools and ideas, some of which directly contributed to this particular transformation method.
Big thanks also go out to TAquickness and Tordne, who had the insight to set up fuel pressure logging, and patience to explain all the EFILive intricacies to me, as well as being crazy enough to let me test my theories on their cars.
On a more personal note, this is probably going to be the last writeup for another 6 months, as I must finish my masters degree and write a thesis. I'd rather be tuning, but oh well. This isn't a complete retirement, I am trying to take some classes in which I could spend improving my tools (Human Computer Interaction), and learn more math to spot and analyze relationships in data (Data Analysis and Simulation) so there will be updates, just nothing huge.
Keep warm, and happy New Years,
Marcin