HPTuner experiments

Parametric VE explained

2009-06-25T23:03:00.000-04:00

This is an explanation, representation, and pros & cons of the Parametric VE.
I was told to cut it out with the math, so here it is watered down for easy reading. I kept the math simple, I might have mentioned matrix multiplication once, but I think I got away with it.

It's way too involved to be a web page so here's the downloads:

Word2007 version PDF version

enjoy and for the love of Newton, please comment profusely,
Marcin

Spot the Surge

2008-04-25T23:20:00.000-04:00

This is a short demo of why in addition to the traditional MAX, MIN, and AVG aggregates of data we also need STD (Standard Deviation).

Normally when you graph data in a histogram, you just use the AVG view, so if you were to make such a view on a log with a surging idle only in one range of temperatures, you'd get a boring and useless graph like this:

However, if you look through few thousands frames on the Chart view, you will notice a pattern:
Low temp (27C):

warmer (43C):

warm (58C):

hot (72C):

It goes no surge, big surge, big surge, small surge, no surge. Strange, we didn't see that pattern in the average view in the scanner, did we? Only if there was a simple mathematical construct that compares the swings of a value in reference to it's average...

So here comes a new tool of mine called Tableau. I paid good money for it, so why not show it off, right? Watch and learn what your scanners should be able to do:

The top one is STD of RPM, the middle is STD of Spark, the bottom is STD of MAP. Also, for better visualization I took the liberty of splitting the ECT intervals from 12 to 6C.
All these graphs are very clear: there is very little variation at low and high ECT's, but somewhere in the middle they go crazy. The cool part is that all three measures here show the exact same behavior! You can trace the interval temps in the summary graph to the 'in time' charts from the scanner, and see they agree to where the engine surges and where it's docile.

So I made a one more experiment and wanted to see how my new tool would display the averages graphically, to see if maybe with better graphics the surging would be visible:

Nope, still not visible, averages 'flatten' the surging losing all the important details.

So here's my call to both HPT and EFILive:

INCORPORATE THE STANDARD DEVIATION VIEW INTO YOUR SCANNERS!

It's useful, I have a lot of other uses, but this is a nice and easy demo of how one extra function can save a lot of time chasing around the precise areas where the OLFA or RAF must be adjusted.

Feel free to annoy Paul and Keith until they code it up ;)

enjoy,
Marcin

Three Airmass Models

2008-04-06T11:23:00.001-04:00

In physics, when you're trying to get to the bottom of something, you usually have a model (a formula) and some data (variables with values). Then you usually calculate something, or compare it to something which values you already know, and find a variable or a constant you don't know. Then, these constants or calibrations can be used to be used for all other cases. Same methodology applies to tuning, however we have not been able to use it properly, due to the lack of models for many important aspects of tuning like airmass, fueling, or temperature.

So far we've been spoon fed some bullshit belief that tuning is adjusting tables because fueling changes. It happened because we did not approach it from the physics angle. But things have changed, and in the past 3 yrs we have determined the models for all the main processes that the ECU is using to estimate airflow and fueling.

For example, there are few different ways of getting to the airmass, the main value which determines fueling.

Airmass 1, from MAF sensor:

MAF= A*MAFhz^3+B*MAFhz^2+C*MAFhz+D
MAF= CAM1*CYL*RPM/120
CAM1= 120*(A*MAFhz^3+B*MAFhz^2+C*MAFhz+D)/(CYL*RPM)

this is nice because all the variables here are truly independent:
MAFhz comes from a sensor, and so does RPM. CYL is a constant we know.
The only thing left is to figure out A,B,C,D. Once we know these 4 constants describing the MAF calibration, we can give a precise reading of Airflow or Airmass, because then we have all the necessary variables and constants.

But how do we find the values of A, B, C, and D? The typical physics thing to do would be to somehow produce a situation in which we know the airflow or airmass, take the values of MAFhz and RPM, and the rest is a 3rd order polynomial fit, which is easily done in Excel or Matlab.

The problem is monetary: we dont have a device that could produce a wide range of known airflow figures. Thus we must resort to producing that Airflow or Airmass number from somewhere else, which happens to be...another Airmass model

Airmass 2, from fuel consumption:

CAM2= IPW*IFR*AFRwb

This looks nice and simple as the scanner gives us IPW, wideband gives us AFRwb, and IFR can be either scanned or just a lookup function based on Manifold Vacuum.
If we assume that this is a good enough airmass model, we should be able to use it to use it as the Airmass figure in the previous section:

IPW*IFR*AFRwb = 120*(A*MAFhz^3+B*MAFhz^2+C*MAFhz+D)/(CYL*RPM)

This formula looks long and scary, but it's actually quite easy to solve:

IPW*IFR*AFRwb*CYL*RPM/120 = [A B C D]* [MAFhz^3 MAFhz^2 MAFhz 1]

This is more for a Matlab setup, in which either polyfit or mldivide work great.
In Excel you can simply graph it, and then 'insert trendline, type: polynomial, option: 3rd order, print equation on graph' and you will get a full equation with all the coefficients on the graph. There's also a numerical way of doing with with the regression plugin, but if you know about this plugin, you probably can figure out how to use it. This exercise will be left to the reader (I always wanted to say that!)

Back to tuning... What this big ugly formula says is that the airmass from the fuel consumption is equal to the airmass from the MAF sensor. As long as all the elements in the formula for CAM2 are truly descriptive of the things they describe, this method is perfect.

Unfortunately the reality is much more complicated:
Fuel systems do not hold fuel pressure under load as well as we wished.
Injectors do not have linear fuel characteristics, so when commanding the injector to do 8ms of fuel will not result in 8 times as much fuel injected as when commanding 1ms pulse width. This is why we have the Voltage Offset and Short Pulse Adder tables. I'm not going to dive into details, as that could be its own huge article, all you need to know is that IFR and IPW and AFRwb are all prone to severe noise in data, and as such are not the greatest source of Airmass. Of course with enough data we could employ statistical tools to weed out the outliers, but WOT data is hard to generate as it is. Demanding great amounts of samples mostly increases our chances to get a speeding ticket.

So is this Airmass model of any use? Yes, if you have injectors for which you have full data in the format GM ECU's use. This narrows it down to stockers, which cannot support much power. Even then that's just IPW, IFR could use a fuel pressure sensor to be dynamically determined, instead of using assumptions of perfection in GM engineering <HA!>

Then there's another Airmass model #3 (Speed Density):

CAM3= GMVE*MAP/TEMP

GMVE is just a computational shortcut describing VE:

GMVE= CYLVOL*VE/R

Since CYLVOL and R are constants, using GMVE saves the ECU one multiplication and one division that would always yield the same value. That's why GM decided to use GMVE instead, as it's simply faster. To humans however, it is easier to understand 90% VE than 2.3 g*K/kPa. However, if you can scan values directly in GMVE, it does make the math easier.

TEMP is...well, if you've read my blog before you know I've spent the past year chasing after this little bugger. TEMP itself has multiple models, depending on model and year of your vehicle. In the simplest case:

TEMP= IAT+(ECT-IAT)*BIAS
where BIAS is a lookup table referenced against airflow

So we could use the same method I demonstrated in the previous section, and set CAM3 equal to CAM1 (if we have MAF tuned perfectly), or CAM2 (if we can describe fuel consumption precisely). Let's take a look at the CAM2 case:

IFR*IPW*AFRwb = GMVE*MAP/(IAT+(ECT-IAT)*BIAS)

tuning the VE (or GMVE) consists of solving for GMVE:

GMVE= IFR*IPW*AFRwb*(IAT+(ECT-IAT)*BIAS)/MAP

This doesn't look too bad, right? Well, the kicker is that GMVE will be determined by BIAS, which by itself is determined by Airflow, which is determined by GMVE. You ever seen a dog chasing its tail? This is exactly what this equation is doing. In practice this is a very difficult problem to solve, and remember that this is for the simplest TEMP model, I could've given you something from a '08 Corvette which has a Bias table based on Airflow AND Speed, and the Filter table introduces a whole new dimension, as it has a damping effect on TEMP, but it does it in reference to time.
Do not try this at home, you just might hurt yourself on a really sharp and pointy equation...

OK, so what about equating CAM3 and CAM1?

GMVE*MAP/TEMP = 120*(A*MAFhz^3+B*MAFhz^2+C*MAFhz+D)/(CYL*RPM)

Oh wait, this has the same problem as we just discussed, as it contains the dreaded TEMP variable, which is not only car dependent, but it also combines complexity of time travel with the witchcraft...

So it looks like either way we slice it, there's problems. Anything fuel related suffers from faults and imprecisions of the fuel system. Everything Temp dependent requires major modeling and simulation work.

So while we have not established anything new here per say, it's clear what we should work on next, to further our understanding and ultimately develop tools to aid the tuning process.
The bigger point here is that even though we can convert one model to another, we still need a starting point. If we had fuel, we could have MAF or SD. If we had MAF, we could convert it to SD or vice versa. But there is no good start point. If the intake tract is stock, we could assume that MAF is the start point. If we a have stock fuel system with stock injectors, we could try to use the fuel as a starting estimator of airmass.
The only other solution (that I've been working on for quite some time) is to use numerical optimization methods to find calibrations that through simulation would yield the most consistant fueling. So far, this process has been partially sucessful, but plagued by the initial lack of information on Temperature models (now solved for most model/years), and my shortcoming in mathematical education. There's been some datasets that yielded clear results, but my methodology is not robust enough to deal with some of the more unruly cars producing noisy data, and ultimately throwing off the math so badly that the VE surfaces end up jagged and having unreasonably low or high numbers.

The short version: we got the plan for the attack, now we just gotta do the hard math.

Hope this cleared up some concepts, as multiple people lately have been asking some really insightful questions.
enjoy,
Marcin

Cranking VE approximation

2008-04-05T20:54:00.000-04:00

I created a quick and dirty spreadsheet that approximates CrankingVE, based on PrimaryVE table.

The tables are done in EFILive format, so HPT users for now have to copy and paste special->transpose their Primary VE table before pasting into the spreadsheet, and then the same thing before they paste the results into CrankingVE table.

Of course, if someone wants to create another version that works with HPT standards, I highly encourange you. I will include it in the future version, just like the injector spreadsheet.

My car is currently down so I can't test it on my own setup, so please use with caution and common sense.

DOWNLOAD OLD

April 05, 2008 update:
Aaron (aka 405HP_Z06) have just contributed a more complete version of this spreadsheet with both EFILive and HPT format tables. Enjoy, and thank you Aaron.
DOWNLOAD NEW

Temperature Models are important

2008-02-14T02:41:00.000-05:00

Both E38 and E40 ECU's have a Temperature Bias table with both Airflow and Speed axis, making us think that it's using both to determine the proper Bias value. But to just make sure that's truly the case, I made a little experiment:

How closely can I can predicting the temperature calculating it from components (Airflow, Speed, Filter, IAT, ECT) to the scanned values of Manifold Temperature?

I wrote few Matlab scripts to take the component values, and use the model I thought it was using. I must admit I went from pure observation and gut feelings on this, but it worked out great.

Test #1:
I made a simple model without any Speed dependencies, the Bias table was purely based on Airflow. I used it to model some E38 data, and it was just rubbish, completely different look and feel to the scanned vs the calculated values.

Test #2:
I expanded the previous temperature model to include Speed in predicting the scanned Manifold Temperature values. And the results were very positive: not only the graphs of predicted vs scanned values were very close to each other, but the set of parameters that yielded the best fit were very similar to the values in the tune which was used to generate this log!

Test #3:
A month or so passes, and I get some E40 data. Blindly, I grab the Temp modeling scripts I've been working with (the ones that worked so well for E38 data), and use them to predict some temps on the E40 values. The result was confusion and big disappointment: the predicted values were somewhat following the scanned ones, but the differences were sometimes quite large (~10 Kelvin). (click on pictures for bigger, more readable versions)

Then I remembered that I'm using the newer model on the data generated by an older ECU. Quick edit of my scripts, and the new predicted values were dead on overlayed the scanned.

This is important for few reasons:
1. We now know the temperature model for E40 (uses Airflow only for the Bias table)
2. We now know the temperature model for E38 (uses Airflow and Speed for the Bias table)
3. We now know that the Bias tables in the two ECU's even though they show the same in HPT (I haven't looked in EFI yet) are actually used very differently. This is a glorious display of phrases like 'looks might be deceiving' and 'verify your assumptions'
4. Newer models aren't necessarily backwards compatible.

Now that we know this, we can do some cool stuff, but more on that later...

Temperature Modeling, part 2

2008-01-12T22:02:00.001-05:00

Since my last “Temperature Modeling” paper came out, there was a lot of good discussion concerning the paper itself, the findings, the spreadsheet, the theory, and a lot of other concepts intrinsically bound to the airmass estimation process. I am going to try to address as many of these issues here for further clarification, as you guys really can bring up a lot of good points forcing me to go back, rethink, recheck, reevaluate a lot of previous notions.

The spreadsheet accompanying the paper is NOT a solution to the bias tuning problem. It is merely a simulation, a toy helping to understand the process of estimating temperature. It was my mistake to use the word ‘optimize’ anywhere near it, as a lot of people thought you can use it to figure out what you need to put in for the values in Bias and Filter tables. It is not. It is there purely for education and entertainment. I helped me a lot in understanding how the bias and filter work together to simulate smooth transitions of temperature of air in the intake.

What you can ‘optimize’ with it, is the model itself. While we have the tables containing data, we do not have the formulas governing them. For example, in the Bias table, intervals are 10g/sec (i.e. on the older F-body computers) or 4g/sec (on the E40 and newer computers). Are the values contained in the cells for the border value itself, or the centers of the range around them (32g/sec would be a center of 30..34g/sec on an E40 ECU)? What happens when the value we need to look up is not in the cell directly? Is it rounded to the nearest known value? Is it interpolated? What kind of interpolation: linear, spline, cubic, Bezier? Until we start hacking the code on the ECU itself, we will not know answers to these questions, however, a spreadsheet like this allows us to play with the different scenarios and see what works and what does not. Of course this is not a proof of anything, but the changes should be visible enough to see some interesting correlations.

Another important thing that came up during the creation of the spreadsheet is the final metric, how we evaluate the goodness of the model we conjectured. The traditional metric in HPT or EFILive is expressed by (AFR-AFRwb)/AFR. So when a metric of a fit is needed for a range of values, most people employ the average of the AFR%Error or BEN. The problem with that is these errors can be both positive and negative, so they can eliminate each other numerically. For example if you just used the traditional AFR%Error histogram and see 0%, you automatically jump to the conclusion you have the perfect tune, while in fact it might have been roughly the same number of errors on positive and negative sides. Considering that measuring entities often follows the normal distribution, the errors on both sides will quite likely be in the business of pushing the average toward 0. This is probably why it takes a few passes to get the fuel trims in the neighbourhood of where they should be to begin with. This made me decide that a better metric is needed to assess the different models we come up with. Just putting an absolute value on the AFR%Error will give you only positive values, making all errors ‘grow’ the average, not drive it toward a zero average. Also, since the number resulting from such a computation is an actual percent of difference, you can sum or even average the errors, getting a better idea on the nature of the errors in your system. Such a system would work just as intended with a great number of clean samples. However, in real world, lots of data is hard to gather, as well as outliers occur fairly frequently, throwing off the averages. Thus, someone had an idea of squaring the difference (AFR-AFRwb)²between the empirical data (AFRwb) and the intended target (AFR). This way, the small errors would contribute very little to the sum, while the larger errors would carry a significant weight with them. This approach is great for spotting systems with a large number of outliers, as they make the sum grow quickly. The problem is that too many outliers will weigh so much that the real data will become almost completely ignored. Yet another metric is the maximum error (max(AFRwb-AFR)). The good aspect of it is that while the errors might not be small, they’ll all be within a certain range from the target.

No matter which of these metrics are used, the goal is the same: to make our system predict/describe an observed function with more precision. Certain metrics are going to skew results in different ways, but altogether they improve the model. The important thing here is that there is no one ultimate metric, we have to know and understand few different ones, and use the ones that make most sense for what we’re trying to do. In the case of tuning AFR, you don’t want to go too lean or too rich; you want to keep the discrepancies close to the target AFR. For such a situation I like to use the maximum deviation metric, as it tries to ‘squeeze’ all the errors under the same level. However, I found practically that it’s not a good metric to start with, as the computer was having problems with finding an optimal answer starting from a wild guess. Sum of squared errors metric was much better for the initial pass, to get the parameters close to what we’d like it to be. With these initial parameters, the maximum deviation metric was much more useful.

So what is all this metric talk for really? The idea of optimization is to minimize errors. However, you cannot make a decision on which model is better, until you can put a number on every model. The interesting part is that in the end it does not matter what it is that you’re minimizing, the maximum deviation or sum of squared errors, as long as it is smaller than before, progress was made.

That is how I set up the spreadsheet. There are multiple models, with multiple metrics assessing the fit. Parameters in all of them are the same, but strangely enough, different models like different parameters, which only further stresses the importance of figuring out the full model, not just the parameter values. The Solver in Excel is quite good, albeit tricky sometimes, at arriving at the best set of parameters. It is however very intriguing to watch how the parameters change (or not!) depending on which metric was being minimized. The best part is to watch the charts change; MATbias, MATfilter, MATscanned, alongside with ECT, IAT and Airflow all dancing around, and the more you optimize, the closer the MATfilter would get to MATscanned. Another interesting thing is to see the more drastic changes in airflow (acceleration, deceleration) rapidly swing the estimated temperature one way or another. Depending on which metrics get optimized, certain patterns on the graph are either followed closer, while others get ignored altogether. I highly recommend spending some quality time playing with the different models and metrics, to get a real feel for what we’re dealing with here.

We cannot forget what this spreadsheet is however. It is an estimator of an estimator. We do not, and will not know the real temperature inside of the intake, until we use an old-fashioned empirical method of sticking an extraneous probe into the bowels of the intake somewhere. At best, if all the math and modeling we developed is perfectly the same as the one in the ECU, the MATscanned and my MATcalculated would be the same. Making them the same does not optimize the model to report the proper temperature; it only allows me to play with the components in such a way that I predict the result with greater degree of confidence. IAT, ECT, and the Bias and Filter tables are all a part of an estimator—that is all they do.

The purpose of all this mathematical gymnastics is to learn how the computer estimates the temperature in the intake. With understanding comes control. Control allows experiments and simulations to take place and either prove a theory or debunk a myth. If our model is consistently close enough to MATscanned though, it would be a good time to try the optimized parameters in the tune, and see if it follows what the numbers intended to yield.

The real complication is that it looks like we will not get VE tuning without arriving at the correct Bias tables, and we will also not get Bias without a solid VE table. I am trying to do it together, hoping that setting them to correct and realistic values would yield least errors across the full simulation, but it is neither obvious to understand nor easy to implement.

Few other points that came across very strongly in all the discussions: Proper attribution is key: other factors (i.e. timing, transitions) can have a significant influence on AFR, and the changes due to temperatures are lost in the noise from other factors (hpt thread 14996)

This temperature accounting discussions brought out few new people: For example, one dude named Adrian had this simple, but very profound idea. If MAT=IAT+(ECT-IAT)*BIAS then MAT-IAT=(ECT-IAT)*BIAS, so with a MAT probe we could determine BIAS. If MAT=IAT, then BIAS=0, which is nice, because not only it satisfies scientific formulas, but also makes common sense. With an extra temperature probe in the intake (probe part number GM PART # 25036751) we could arrive at BIAS in a very simple way. Any takers?

Another interesting point that came up in the discussions was the reason for the whole temperature estimation model, instead of a simple probe mounted inside of the intake. Would it be reasonable to think that the whole complex estimator was created because probes in MAT were measuring the temperature of the intake housing, and not the air inside?

Another guy, Phillip, did some experiments and brought up to light that the temperatures do not affect MAF readings, while SD is clearly affected by temperatures. This means that with a proper MAF calibration, VE calibration can be obtained by mapping out the MAF airflow on the traditional RPM/MAP axis, and back calculating VE based on the temperature estimates. This is interesting, as one of my first contributions to the tuning community was the idea that MAF tuning is easy, because all you have to do is map out the airflow resulting from the VE-based SD calculations onto the MAF scale, which is the exact reverse of what this newest batch of research suggests.

A thing that bugs me about the various bias tables is how they differ from one model year to another. There are straight lines, two sloped straight lines, lines that look like exponential delay… ultimately, they all point at the same patterns: at small airflow numbers the bias line starts toward ECT, and quickly works toward IAT, asymptotically leveling off at the end. To make estimating the bias curve possible, we must have some sort of idea for the function. Exponential decay curve makes for such a line, as it has all the properties we need (BIAS=a*e^(-k*MAF)+b). Another great thing about the exponential decay curve is that we can manipulate its shape using three parameters, making the fitting process about as complicated as a polynomial or even a straight line, but results in a fairly complex curve shape.

Tunes often have tables that are either unused, or used in irrelevant ways. For example there’s a voltage multiplier for IFR, which is just set to 1.0 on most cars. However, on the 4 cylinder cars you can use it to achieve the effective IFR higher than its natural limit of 64 lbs/hr. On all other platforms I tried, changing these values has no effect. Such ‘occasionally functional’ tables make me wonder what is the purpose of adding a dimension of speed to the Bias table in the E40 ECU on the 05-06 GTO. The Bias values do not change along the speed axis, making it effectively useless. Is the full table used, and the calibration just does not take speed into account, or is the computer still using only one row of values, and the rest of the table is unused? It is not that extra complicated to account for it, but I do not want to introduce variables to the model that are simply not there.

Most discussions about system modeling end up with someone attempting to oversimplify a complex system. Reducing GM’s MAF/SD hybrid to pure MAF or pure SD to tune a particular table is an example of simplification in the name of gaining control. On the other hand, we have people setting the Bias table to one value across the entire table, simply because they do not understand how the system works. The combination of the Bias and Filter tables is a great example of how an ‘overcomplicated’ system can easily (and properly!) become a simpler, older version of the same system. You can think of it as an evolutionary process, where evolution was forced upon insufficient precision of the older, simpler systems. In the beginning there was a single IAT probe which was used for air charge’s temperature estimation. It probably did not work too well, so they decided to move this probe into the intake, hoping to be ‘closer to the action.’ This also turned out to be a fiasco, as the probe ended up measuring the temperature of the intake more so than the air inside the intake. The decision was made that since you cannot apparently measure the temperature in the intake, then it would be better to estimate it, as it is going to be between the two sources of the extreme temperatures in the engine bay—the airbox and the coolant. A first attempt at this estimator was made using the Bias table alone, a simple matter of proportioning the two temperatures based on airflow involved. If you simulate it, the sequence of temperatures resulting from such proportioning yields rather choppy and abrupt final temperature function. Since most things in nature have smooth transitions, such a model demonstrated a need for a smoother output. Such an output was provided by introducing the Filter table into the model. The more airflow is involved, the quicker the temperature will converge to the newly present conditions. If that was not complicated enough, the Bias table have grown a dimension to accommodate changes in bias depending on speed of the vehicle. I would guess this is due to the fact that at higher speeds the incoming air not only gains density, but it also has lower temperature of the air charge. So the system have evolved from a single sensor with no corrections on it, to a monster with three sensors (IAT, ECT, SPEED), and two tables (Bias is 2D, Filter is 1D), proportioning and dampening the inputs to create an estimator of temperature in the intake. Let’s say we have a car with the fully evolved implementation of this estimator, but we have no clue how to calibrate all the necessary tables. However, we might know how to deal with a simpler system, let’s say it’s the one without the filter table and with a 1-dimensional Bias table. If we fully understand the system (even if we cannot control it) we can set the values of the Filter table to 1 (instant change) practically eliminating it from the system. Then, if the Bias table’s speed dependent values are set to be identical for each airflow, the Bias table would become its own simpler version, fully emulating the behavior of an older system; hopefully it is close enough to yield good results, and simple enough that it is solvable.

Here is the best example of how not to simplify the complex systems. This is picked from some older bias adjusting discussions on the HPTuners’ forum:

“well..my cylinder bias temp is 1.0 across the board for now..and because they are all the same value my filter settings basically dont matter you would think this is a bad idea..but sometimes de-engineering GM and simplifying is a lot better than trying to use thoer whole dam slew of BS they throw in there..LOL”

site updates

2007-11-03T12:44:00.000-04:00

I just went through the site and fixed all the possible dead links, pictures, spreadsheets, etc. I could find, so the site is back to a useful state. It's entirely possible I missed stuff, so if you see anything broken, PLEASE LET ME KNOW.

I'll probably work on modifying the template, as the narrow column display is good for cheerleaders posting about their feelings, but not exactly fitting for all the graphs, charts, histograms and other crap tuning requires. So if the site looks goofy this weekend, just have patience and keep checking back.

Temperature Modeling

2007-10-07T20:47:00.000-04:00

Well, I'm back. I'm done with school, so I finally got time to do tuning stuff.

This is the first part of a larger thing I've been working on. The goal is both MAF and Speed Density tuning that works day, night, summer, winter, and at any altitude. Temperature is one of the three components needed.

Here's the paper: DOWNLOAD (370kb)

The 'nice' version of the spreadsheet is coming soon, as I still gotta write up some instructions for it. If you must have it now, here's the DOWNLOAD (Excel 2003, 7.1Mb) and DOWNLOAD (Excel 2007, 3.7Mb)

Enjoy,
Marcin

Natural limits and bad weather

2007-03-03T16:18:00.000-05:00

So in the previous post someone asked me to post my spreadsheet for one of the pictures I posted. To be honest, I cooked it up really quick, and I think I nuked it at the end, so I had to make one from scratch again. This time however I had some fresh data from a LS2 with the Maximum VE tables upped into a reasonable territory. The problem with this data was that it was taken a day after the horrible tornados that went through The South recently, so maximum MAP for example was about 96kPa, while I've seen over 102kPa on this car before, so I know it's the weather, not a physical limitation of the car.

Also, since I've started dealing with LS2's, few limits became apparent: first it was the IFR table, then it was the GMVE, now it's the extra low airflow and airmass limits that I wrote about few days ago. All these limits got me thinking on what are the real limits of the stock computer. Afterall, with 63.95lb/hr of fuel I knew we'd run out of ability to describe fuel delivery, and 4.096 K*g/kPa on the GMVE table would limit the amount of airmass and airflow we could report.

Put all these things together, and I ended up with two spreadsheets: first, the correct version of what I created for the last writeup (yes, it was wrong! I'll correct it later), and a spreadsheet where I can convert gathered data into a much more comparable airflow and airmass figures, corrected to SAE conditions (99kPa, 25*C).

I'll start with explaining what I've done before and how it's all better now.
I took the Maximum VE values, and converted them to airmass, and then airflow values.
This shows that at extreme conditions of 188F IAT (why I picked these, I'll explain bit later) we'd get about 280g/sec of airflow at 6400rpm, which is also the limit expressed in other tables, so they make sense all together.

For exploratory purposes, I also added 2 'reverse' scenarios, for the pupose of seeing what kind of GMVE values one would get to achieve a certain airmass (or airflow in the second case).
Notice that with near max'ed out GMVE numbers, we'd get about 68lb/min airflow. If that sounds familiar, that's because it is. MAF's maximum number is 512g/sec which is the same damn limit. So this means, GM made the expressive powers of both VE and MAF tables equivallent, even for the worst conditions, which is the proper OEM thinking, always engineering for the worst possible scenario. So this means that no matter whether we use SD or MAF tuning, the limits are going to be the same.

The middle section (GMVE from airmass) was made becuase I wanted to see what valued I should expect from a well flowing big cam/heads setup, as I've seen some put down over 1.05g/cyl airmass. It's not exactly crucial, but it helps the total understanding.

Then I wanted to see how the numbers would change, if we made the aircharge temperatures slightly more optimistic, let's say about 80F (27C for these living in countries with a sane unit system), and I got these:

Turns out, that when temperatures are sane, we can get the same airflow as before, well below the GMVE table's limit! This is where a big bulb went off over my head. The reason why we've had so much problems with VE tuning in LS2, is becuase GMVE, while generally proportional to the old fashioned VE we're used to from LS1 computers, also reacts to pressure and temperatures! This means, unless we normalize pressures and temperatures while SD tuning, resulting GMVE are going to vary with the atmospheric conditions!

Yes, these statements require exlamation marks. In LS1 world, VE was nice to have, because it was temperature and pressure invariant. Here, we dont have this comfort anymore. OOPS, no wonder LS2's didn't want to easily converge on a stable GMVE table!

Good luck for my research, and bad luck for Alabama and Georgia, tornados hit them hard lately, and I just happened to send one guy who lives there to a dyno, to see what our recent extensive SD tuning managed to achieve. He wasn't happy, because the numbers were down from previous hacks performed by various pseudo tuners. So partially to cheer him up, and partially to find out just how much power can bad weather 'steal' from a car, I started some more number crunching.

Because these were dyno runs, I displayed all kinds of data against RPM. Temperatures, airmass, airflow, pressures, all got dumped into a table, as I didn't quite know yet what I'm going to need. Also because I wanted to get as close of numbers as possible, I grabbed data from the ECT vs IAT bias table. For these who havent played with it, it's a table that based on how fast the air is moving in the intake (airflow), the temperature used to calculate airmass (and thus airflow) would be weighted by different amount for IAT and ECT.

So first I calculated the temperature bias based on airflow and the temperatures. From that I was able to get the temperature that the computer (hopefully) uses to calculate other stuff.
Having that temperature, I was able to backcalculate GMVE values that gathered airmass figures would yield. To verify the correctness of my simulation, I calculated airflow using my new GMVE values, to compare against the airflow gathered directly from the computer. Error through the whole range is less than 0.7% in all cells except the edge ones, which is understandable, as we're using averages values, and on the edges we dont have data gathered from the entire range (ie. we're using 6800rpm to calculate airflow in that cell, but the data gathered from it would be calculcated from 6600-6800, so the average should be more like 6700). Either way, I can live with 0.7% error in my simulation.

With the GMVEs calculated for these particular conditions, I decided to see what the airflow and airmass would be like in SAE conditions. Low and behold, they would go up, quite significanly too. 2.5lb/min at peak airflow and 0.04g/cyl at peak airmass extra. I've been using a metric of 9hp per each 1lb/min of airflow for ballpark estimation, as it usually creates reasonable numbers, useful for more 'common sense' comparisons. So in the case of this car, we'd get 24hp correction.

Then I decided to yet again, calculate GMVE for the corrected airflow, to see how it would look like at these SAE conditions, and how far off it was from what we had, hoping we would see a correspondence to the AFR%Error logged.
Almost all new GMVE values ended up being about %2.4 off from what we calculated earlier. AFR%Errors are much more varied in both magnitude and direction of the correction. So that's not what cause these AFR swings. Where it really came from will be a whole different study.

Ok, so this was a lot of stuff... What's the point, what's the punchline here?

We cannot tune GMVE the same way we used for VE. I dont know how the hell I missed it the first time around, but that's what you get for theoretical tuning. You guys really oughtta buy me a GTO--Please paypal all your donations to marcinpohl at gmail dotcom ;)
Joking aside, but this is going to need another tool/spreadsheet/customPIDs or something creative like this. The new way of doing LS2 VE table is going to need taking into consideration not only current VE table and AFR%Error (or BEN's for EFILive folk), but also temperature and pressure. We will effectivelly have to convert the GMVE into VE, apply the correction there, and then convert it back to GMVE based on some conditions that the computer has to assume as standard values.
I will definitely make a tool for it, but not now, I really really oughtta get back to my thesis right about now.

MaximumVE spreadsheet DOWNLOAD
Bad weather correction DOWLOAD

LS2 airflow uncorked?

2007-03-02T00:59:00.001-05:00

I'm not sure if anyone noticed this before, but when you're tuning LS2's with the new funky GMVE units, they go up, reshape, but ultimately reach an early upper bound of about 2500. I always wondered about this, as it made no sense, most LS2's VE table and the resulting airflow would not reflect the real torque and horsepower gains.

Today, completely by accident I find a table called Maximum VE, sitting right there under Airflow->Dynamic Airflow. In EFILive, the symbol is {B2030}.

I open it up, and low and behold, it maxes out about 2500, with a peak at 4400-4800RPM, just like most LS2's peak torque. I quickly punch in some numbers into a spreadsheet, to see what kind of Dynamic Cylinder Torque am I going to see. Again, everything agrees with near stock LS2 numbers, around 0.85g/cyl airmass at peak.

This little spreadsheet also shows how much airflow you'd see with these airmass numbers at given RPM.

So I grabbed some recent logs from a well flowing, healthy, well tuned big cam LS2, and started charting max Dynamic Cylinder Air vs RPM. To make this task easier, I try to find a table that's already preconfigured for the same RPM intervals, as the VE Maximum table. Not only I found the VE Maximum table, but I also found few other tables that seem to pertain to the same problem: Maximum Airflow vs RPM, Maximum Airflow vs IGNV, and Maximum Airflow Delta vs TPS. They're all set up to deal with stockish power, 280g/sec (37lb/min) airflow, and small MAP and Airflow deltas. On the editor side of things, you can find them under Engine Diagnostics->General->Diagnostic Tests. In EFILive, the symbols are {C0803} to {C0806}

I quickly eyeballed what the numbers mean, and what they should be set to more realistically, and came up with this:

So this should work for most NA LS2's. I hope this is the limit, because it would explain a lot of issues I've been having tuning a large cam LS2, and the more airmass we'd get, the more timing would get pulled without a reason. Hopefully this is yet another Torque Managment issue, this time trying to save the engine from too much torque by pulling timing when hitting airmass/airflow limits. With this

The problem is that I still don't have a local access to a damn LS2! Anyone around Monterey wants to be my lab rat and get their car tuned in the meantime?

Anyway, I need you LS2 folks who have already braved the weird VE table and are running abyssmal timing to prevent it from Knock Retard, this might be your solution. I need you to change these limits that I posted pictures for above, and watch what happens to your Dynamic Airflow and Dynamic Cylinder Airflow. I'm predicting it's going to go up a significant amount. This means it might need a retune. Suddenly you'll be using deeper regions of timing tables, so please alter them accordingly.

Of course, this is all liability free, you're ready to blow up your engine, yadda yadda yadda, can't sue me stuff...

Please report back with your results, they're absolutely crucial as I don't have direct access to a LS2. The best way to do this would be to have a before and after pairs of logs and tunes, with the only change in between being the changes I recommended above. Remember that because you're going to 'uncork' your LS2 vehicle, you will probably experience lean conditions so please proceed carefully, set your PE ratios on the rich side with a healthy amount of safe margin.

The great thing about all this is that you will possibly be able to get more timing out of it, and get even more torque. So far I've had to cut down the timing on the big cam LS2 I've been helping with lately to below 20* to get rid of most, but not all knock. Without limits, the preemptive KR should disappar, airmass and airflow should skyrocket, timing would not have to be severly limited to push the airmass under the 'safe' limits.

This should really help. Airflow numbers should be realistic, torque should improve, and we'll all support the economy by buying new tires and clutches.

Got airflow?

Injector Sizing Explained

2007-02-25T17:05:00.000-05:00

This was written a while back in response to some stellar forum exchanges. I finished it up because apparently it's still badly needed.

Injector sizing concerns itself with the two ends of fuel consumption: idle, and WOT.

At idle, you are limited by time a given injector takes to open, spray minimal amount of fuel, and then close. Different injectors have different characteristics, but generally speaking, the bigger the injector, the bigger the minimal amount of fuel it wants to spray. If this minimal amount of fuel injected is bigger than the need for the fuel at the given airflow consumption, you will dump more fuel than it needs. This will cause carbon buildup, mess up spark plugs, eventually kill O2 sensors, and it generally going to make the car run like poo, since it's basically over fueling. Over fueling is easily recognizable as surging. Engines with big cams, or any other 'race' modifications have a significantly diminished efficiency of the motor at low pressure and low RPM. This means that it needs a lot less fuel than stock setups at idle. On the flip side, hopped up motors have need for bigger injectors at higher RPM and pressures, to match the increased airflow. These two aspects often clash, as the bigger injector is not capable of injecting smaller amount of fuel at idle. This is when the injector sprays the minimal amount it can do, which is often bigger than what the motor needs and you're back to over fueling and surging. This is why you have to raise idle RPM on such setups--bigger cams get up to higher efficiency very quickly with more RPM. You have to figure out at what RPM the airflow requires more fuel than the minimal pulse width of the injector. There are a lot of variables involved, and very few of them are linear, so this is not a problem with an easy solution.

At WOT, the situation is the opposite. You just have to make sure that at any given airflow, the amount of fuel needed isn't bigger than ~85% duty cycle of the injectors. On naturally aspirated setups this is simple, as the airflow usually just goes up with RPM as MAP is pegged at atmospheric pressure's level. On boosted setups, you can boost a lot more in midrange than up top with fairly small injectors. This is exactly what the 'chipped' 1.8t Audi/VW's do, 17psi at 4000rpm, and back to like 7psi by redline, so the dinky stock injectors have enough time to spray in required amount of fuel at high RPM, while at lower RPM they just take longer to provide adequate amount of fuel. These are two crucial ideas:

1.Injectors cannot regulate how much they spray in any way other than how long they are ‘ON’. That time has to be smaller than the time between ignition, and that’s exclusively RPM dependent. So don’t look just at the Pulse Width, you can only judge it against RPM.
2.Airflow depends on many factors: VE, boost, RPM and of course, displacement. You must take ALL of them into consideration at ALL possible values. A small engine at midrange RPM can make a lot of airflow with enough boost.

The duty cycle is an often misunderstood. It's a ratio between the pulse width required for proper AFR and the length of time you have to inject that amount of fuel. It is dictated by the RPM and the Otto cycle. 20ms pulse width at 3000rpm is just fine (50% duty cycle), because the 'window of opportunity' is 40ms. But the same 20ms pulse width at 6000rpm is 100% duty cycle because the 'window of opportunity' is also 20ms. Very often on forums you get people making statements like 'my car runs just fine at 130% duty cycle, so the stock injectors must be underrated.' What they really mean is their injectors don’t have the capacity to provide enough fuel in the time allotted. The computer calculates air mass, figures it needs 30ms worth of fuel and starts spraying, not thinking if it has that much time before the next ignition or not. This is where the ridiculous 'acceptable' duty cycle numbers come from. Computer calculates that it wants 30ms fuel with 20ms to do it in, it's going to show 150% duty cycle. This however doesn't mean the fuel gets there. It physically cannot get there in less time than it's allowed, as the intake valve closes shut. So what happens then?

Not only the ignition will happen without all of the fuel necessary at the time, but the fuel is still spraying during the power stroke, puddling on top of a hot valve. Then the injectors turn off and recharge for another spray cycle half way through another cycle already, when they should be spraying fuel. So while one cycle might be fueled fine, another one is going to be lacking proper fueling. Such sequences of events cause severely unpredictable fueling and widely scattered AFR, fluctuating EGT's, and generally making it unpredictable and difficult to tune. In addition to that, you're stressing the injectors beyond their operational range, overheating them, and possibly causing a pre-ignition.

Without proper injectors, at best your car is going to be running like shit; at worse it will cause a meltdown. It's just not worth risking. Injectors are cheap, I will never understand people who are willing to drop 3k in heads that flow few CFM better than others half the price, but won't even think of spending $300 to make sure that the airflow can be matched with fuel and your expensive parts don’t melt away. Don’t be a cheap dumbass, be fast and reliable instead.

VE-IFR transformation

2006-12-30T16:50:00.000-05:00

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-001

PSI 0.00 100 .2 "({GM.EGRS}*25)-12.5"

KPA 0.0 700 .1 "(({GM.EGRS}*25)-12.5)*6.89475728"

Now 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.

*CLC-00-002

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))"

Notice that this is the place where we must hardcode the value for the rated flow and pressure of the injectors.

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

Fuel Pump sizing

2006-12-26T23:56:00.000-05:00

My fuel pump pressure post gave me a lot to think about, and few people had some interesting questions as well. One of the simplest, yet most important questions was 'is the fuel pump holding up?' I looked around, and amazingly, I have not found much information on how to estimate how much fuel your fuel pump needs to be able to pump so injectors can keep with the demand.

Most fuel pumps are rated in how many Liters of fluid they can pump an hour. I'm not exactly sure why they'd go with a volume flow rating, when injectors are mass flow rated. The easy way around it is to convert one to the other, which should be easy, as mass=density*volume. Of course there are various types of gas, so the density specific to particular types of petrol will differ, but the generally we should be close to desired rating. I found numbers of 690g/L to 770g/L, so I'm going to use 730 for an easy average. These translate to 0.690kg/m^3, 0.770kg/m^3 and 0.730kg/m^3 respectively, for the more traditional measure of densities.

This spreadsheet converts the rated flow of the pump into units comparable with the units used for injectors, and then divides the flow of the pump by the number of injectors, to see if the flow provided to each injector is larger than what the injector would flow at WOT at standard LSx 58psi fuel pressure.

It's all very simple, but the funny part is that once I started plugging in typical fuel pump flows, the per injector flows were very closely matched to the flows provided by the popular injector sizes!

190 lb/hr fuel pump outputs just above what SVO red tops need.
255 lb/hr fuel pump outputs just above what SVO green tops need.
350lb/hr fuel pump outputs just above what Mototron 60's need.

I'm not sure if it's coincidence or not, but it works so nicely, it's a really easy 'rule of thumb' to match injectors with pumps for a well balanced system.

Here's the DOWNLOAD if you want to play with more specific options.

More fuel system investigations coming soon.
Stay tuned,
Marcin

IFR spreadsheet for Logged Fuel Pressure

2006-12-21T23:56:00.000-05:00

Here's the new, promised IFR spreadsheet that calculates IFR table accounting for the variable Fuel Pressure.

DOWNLOAD

This is NOT a replacement for the old IFR spreadsheet! This is only for people who set up their Fuel Pressure sender units to log. If you don't have such a setup, continue using the old one.

Remember that this will only work if you log your fuel pressure first against a variety of driving conditions. I'm not going to describe how to log it, as I've already seen it set up as the EGR voltage, or as the separate input (just like a wideband). HPTuners and EFILive setups differ as well, so deal with it appropriately. I don't have resources to describe every possible combination of hardware and software here, and this is a more advanced thing to do anyway, so I'd rather not give people a false sense of assurance.

One important note: remember that most pressures in the GM PCM are absolute. IFR for some strange reason, is based not on MAP just like about anything else, but on Manifold Vacuum. In EFILive this is easy, MANVAC is just another PID to pick. In HPTuners, I haven't seen it yet. I tried to make it with a custom PID of BARO-MAP, and then use it to create a custom histogram of the new MANVAC-like PID against the Fuel Pressure PID. Easier said than done, after many hours and help from people that know HPT in and out, I just gave up. This is what you get for hacking custom PIDs into HPT at the last moment, and not having them as a part of design and infrastructure from the get go.
Anyway... If anyone figures out how to get FP vs MANVAC histogram going in HPT without major hacks, please let me know, right now it's a bloody mess.

Just like I mentioned in the last writeup, FP apparently varies even within the same MAP range, making tuning IFR against the logged Fuel Pressure closer to The Truth(TM) but still not perfect. For now, we're still stuck dealing with the VE table making up for non-MAP related IFR variations.

Next up: transforming VE's using the new IFR without retuning.
Stay tuned,
Marcin

Under (Fuel) Pressure

2006-12-17T16:34:00.000-05:00

After a year and a half of using the IFR spreadsheet, I came to the conclusion that while it is not wrong as far as the information given, it leaves much to be desired when it comes to truly reflecting reality. The biggest problem it has is the lack of expressing how fuel pressure differs at various loads (Manifold Vacuum).

Unexplainably high VE values on some cars made me think that even though we 'fixed' some old-school arbitrary IFR choices, we're still fudging somewhere, because there's no reason for the theoretical VE numbers to be that high.
Once I created the equations for airflow I realized that the only spot where the 'fudge factor' could occur would be the IFR. The rest of terms in the eqations is either logged (MAP, temps, RPM) or not exactly changable (number of cylinders, cylinder displacement). In the meantime, TAQuickness and few others started working on a simple setup that would allow us to log fuel pressure alongside all the usual PIDs, not just a simple gauge you can look at at idle.
Eventually all the experiments came together, and provided me with some very interesting data. The car from which the logs discussed here come from is running 42lb/hr@3bar injectors running at 63psi. On the table and chart below, the values calculated using the standard IFR spreadsheet are labled IFRcalc (pink dots, values on blue background). The other data series is calculated from logged Fuel Pressure (comes in as a EGR voltage, so it's evgs in the table) which then gets converted to PSI for easy lookup/calculations (marked FP).
Once we know the nominal flow of the injectors and the real Fuel Pressure, we can calculate the real flow of injectors (labeled IFRfromFP, blue dots, yellow background in the table)
As you can see, the blue dots are nowhere near pink dots. Apparently measuring the fuel pressure at idle (no load) doesn't give you the best numbers. That's fine, that means you just need to reconfigure IFR for new FP, right? Wrong!
Not only the FP numbers going in aren't close to what they are, they are also non-linear. We need to update the IFR spreadsheet to be able to take various FP inputs, depending on the MAP. Easy enough I think, and quickly make some adjustments to the spreadsheets.

The Fuel Pressure drop seemed significant enough that I wanted to understand it deeper, it didn't just seem to be some underpowered aftermarket junk part, but a more complex issue. I wasn't quite convinced that the Fuel Pressure drop was solely a function of MAP/Manifold Vacuum. So I started graphing FP against various entities to get a better feel for it.
There was an obvious relationship between MAP/Manifold Vacuum and FP, as we already have seen with the data above.
I graph it against RPM, and there's another definite relationship. Now I'm confused--how can it be, if the crucial IFR table is purely manifold pressure based?

Another popular view is airmass based, like the timing tables, I thought, maybe it's load/compression/torque dependent, afterall that's when the most air gets consumed.

I graph FP vs DynCylAir and I keep getting the same shape drop when I did when I graphed it against RPM. Why not do a 3D graph of FP vs RPM and DynCylAir? I'm starting to see a cleaner relationship, the more DynCylAir coupled with RPM the less FP we get.

So I'm thinking: DynCylAir is like torque, and DynAir is like horsepower, and TQ and HP are bound through RPM, so why not graph DynAir vs FP?

BINGO! This graph seems to be very linear, with a high degree of confidence.
But then I start to think what does this mean--why higher Airflow makes the Fuel Pressure drop so consistently linear? Obvieously more airflow needs more fuel flow, they're coupled through the AFR, RPM just enforces the time intervals to do the fuel injection in, and IFR tailors it to the injector size and fuel pressure.
From the Speed Density paper I've discovered that:

AIRFLOW=CYL*RPM*IPW*AFR*IFR/120
and we know that
IFR=IFR(rated)*sqrt(FP/FP(rated))

which for the purpose of this discussion(meaning keeping everything else constant) means that Airflow is directly proportional to RPM, and the square root of Fuel Pressure. This is not what this graph says, at least with the given precision. This graph, even though introduces a lot more noise for the high Airflow values, still seems to lay along a straight line. So the possible explanation might be that because we're using a fairly small range of FP values, we don't get see the curve that would result from a square root relationship.
Another explanation comes from the way I obtained the data for the Airflow vs FP graph itself; I histogrammed the Airflow into 5g/sec bins, to equalize the number of samples along the axis, because it's hard to log large number of samples in higher airflow ranges on the street. If I fit a line to a large number of samples, mostly in the lower ranges, the fit would be good there, but the scarse upper range data would be largely ignored. While the histogramming first gets rid of the weighing to the large number of samples problems, it potentially loses a lot of precision, in our case enough to not be able to tell which type of relationship it is.

So this investigation leaves us with more questions than answers:

Why does the FP drops so much more than it officially supposed to (proportional only to MAP)
If the FP is so well proportioned to Airflow, is that by design or by accident?
Even if I log FP precisely for my fuel system and adjust IFR values directly based on that, the swings if FP values within the same MAP range (since that's all we can differenciate by in the IFR table), are still significant.

The only table that's able to account for the RPM swings is VE. This is not what I wanted to achive here, I wanted to free the VE table to be the 'catch all fudge table' and have it become the true theoretical Volumetric Efficiency. So where else could I move the fudging duty to?

The good part is that now we know just how bad our fuel systems are when trying to hold up to a moderate (400lb/min of airflow ain't that much, I've seen cam-only LS2's flowing 450+) power. Throw in a better flowing system, more cubes, or god forbid any forced induction, and our FP shrinks down in the moments when we need it most--WOT. So, if you want to impulse buy anything this xmas, I highly recommend a return fuel system with a manifold pressure referenced fuel pressure regulator.

This investigation started really small, I just wanted to see how badly does the Fuel Pressure drop and what effect it has on the IFR. Now I see the shortcomings of the fuel systems, computer's inability to express all the changes that take place, and shortcomings of my own IFR spreadsheet (new version coming up shortly).
There will definitely be a lot of other stuff coming out of these observations, as this is very scary, considering how much trust we put in aftermarket pumps, and they simply fall short of expectations. I've always told people to get bigger injectors and run with a healthy margin left. Apparently I didn't know just how right I was--in this case running with IFR falling 10psi from what your computer knows about yields 9% less fuel delivered! When you're trying to get your AFR within 1-2%, 9% error in one of your data is going to seriously monkey wrench your system.

So this xmas, be afraid, be very afraid...

New IFR spreadsheet, and then automatic translation of your VE based on the new IFR are going to be the next targets of attack for me toolwise.

Stay tuned,
Marcin

Why tune VE?

2006-12-17T12:44:00.000-05:00

This is a post in one of the forums, I usually don't like to duplicate information, but singular forums posts tend to get lost in the noise, so I'm posting it up here as this is something that should be very clear to everyone that's trying to tune their car.

The question was:
Does this (VE tuning) gain me anything performance wise?

This is a very good question, I'm glad someone is trying to understand what it is that VE tuning is actually about, not just how to do it.

1. Without VE being perfect, you'll never be able to find out proper timing. When computer detects the tiniest tendency to run lean, it will be very trigger happy to pull timing with usually no good reason. Thus, if your VE is on the lean side (and it usually is, after all that's what adding better flowing parts is about--flowing more air) you will get a lot of knock in random spots, and no amount of pulling timing yourself will cure it, causing your car run like poo.
2. Sudden transitions are hard to get right. Without VE being dead on, you are making it almost impossible to get right. Bad transitions cause knock, which lingers around, doesn't last just when going over the areas that aren't perfectly tuned. I've seen knock last over 5 secs. If you're a drag racer, that's diminished performance for half of your run. That's why it's also important to tune not just some of the VE, but ALL of it.
3. When your car develops a problem, you will notice it. If your VE is well done. airflow numbers will be down, knock will appear, but you know it's not the fault of the bad tune, but a result of some hardware component failing.
4. When VE is perfect, it is meaningful. If you add a part that supposed to improve engine's breathing, your VE will go up, and if you get it tuned perfectly before and after, you will know just how well the part works, and for what MAP/RPM range.
5. With perfect VE, your airmass and airflow numbers will be meaningful as well. with their close correspondence to torque and horsepower respectively, you can optimize your powerband.
6. Perfect VE enforces other tables to be meaningful as well. For example, to obtain the same proper fueling with wrong VE, you will have to hack either your IFR or PE numbers. With all of them perfect and meaningful, when you want a 12.9AFR, you can just command it in PE and it will happen, instead of taking stabs in the dark hoping that some arbitrary PE will make it happen by accident.
7. Since VE dictates airmass and airflow, everything based off such tables will work better as well. Shift tables for automatics need to know how much power you're really making. If you're lying about VE, then this power estimation is also wrong, making the transmission misbehave.

In general, VE in itself is important. A lot of other things are derived by calculations based on numbers calculated from VE. It really ends up being a domino effect. If VE is meaningful and proper, then it forces other things to meaningful and proper as well. But if you botch/ignore VE, then the bad effects will propagate, making the entire tune a major hack, making the car drive horribly, and sending the tuner chasing his tail. You pick which domino effect you'd rather experience.

In the long run it's really just easier to do it Right.

Unscrewing a bad tune, Part 2

2006-12-04T03:07:00.000-05:00

Sunday mornings are usually connected to fuzzy slippers, eggs and bacon, extra long lounging session in the tub...but not today. Barely did I sit down in front of my computer, I was asked to look at some Forced Induction tunes. The guy asking these questions was rather skeptical about the correctness of some examples he's received. Of course, the people who he got the tunes were claiming their turbo setups running well.

So I dove into one of the tunes, and all the usual marks of a bad tune were there: arbitrary IFR, untouched VE and MAF curves, super aggressive PE triggers. The whole tune was pretty much based on the PE table, assuming identical boost and airflow at the same RPM, and ignoring all other variables. The car supposedly was running well at 10psi, making me wonder if I can learn something from it. In order to do that, I decided to 'unscrew' the hacked up tune. If the measured AFR was correct, that would indicate that the final fueling decisions were made correctly, despite the wrong input data. Since this is a staple of every 'pro' tuner out there, I decided to see if it's possible to see if two wrongs can make a right.

Since the car was running in MAF mode, and the MAF signal completely maxed out by applying some healthy 10psi, I knew that the airflow figures are going to be wrong. While looking at the IFR table, I learned that the injector flow values were completely arbitrary. PE was the only real tuning device, and the resulting Pulse Width was the only non-wrong, non-fake value in the whole setup. Thus, task 1: calculate the IPW.

This part is easy, I thought. Plug in the wrong numbers, in my case 59lb/min of airflow (max'ed out MAF), 41.3lb/hr injectors, 11.15 PE value for 6400rpm which was the redline, into my VE2IPW calculator and be done. I realized that's no so easy, as my VE2IPW calculator is optimized for working with Speed Density data, not MAF. There is no field for Airflow, only its components, and Airflow gets calculated dynamically behind the scenes. I looked into the Speed Density paper for some equations, but they were no help either, as they also expected either VE, GMVE, or rho (air density), and I didn't have any of them available. If you want the hairy math details, read the updated paper. If you don't, here's a short version:

IPW=120*Airflow/(Cyl*RPM*AFR*IFR)

This means now we can calculate Pulse Width directly from the airflow number, no matter what the source of it might be, MAF or Dynamic Airflow are both fully viable sources. In the case of the hacked up FI tune I knew the car ran on maxed out MAF, so I just used the maximum value from the MAF table, 59.8 lb/hr. Few quick unit conversions and simple math operations later, I arrive at the IPW at 6400RPM: 18.9 msec.

OK, so now what? I figured I wanted to first see what the numbers would really look like if the tune was done properly. I inversed the formula to calculate the Airflow from IPW:

Airflow= IPW*Cyl*RPM*AFR*IFR/120

The big change this time I wasn't going to go with fake, ridiculous PE and arbitrary IFR. I found out what the injectors really were, calculated their flow against the fuel pressure I was told the car ran at (48.5 lb/hr). I used the AFR values from what the car supposedly ran at, 12.0AFR. Again, do some unit conversions, and out pops out the real value for airflow we should get: 576g/sec (75.6 lb/min), which is beyond the max value storable in the MAF table. So yet again, MAF being useless on Forced Induction comes out again.

Then I decided to compare this estimation of the real airflow with one of my older spreadsheets (INJsize.xls) to see how close the two are.

So I quickly punched in 8 cylinders, 5.3L (it was a truck tune), 6400rpm redline, 100%VE, and 10psi of boost. The result says 576.7 g/sec (76.1 lb/min) of airflow. That's within 1% I was happy to see consistency between the two completely different methods arriving at the same conclusion. Of course, a quick glance at the injector sizing spreadsheet pointed out that he needs almost 100% of fuel flow capacity of 48.5 lb/min injectors, and that to make it go down to 80%, he'd need to flow about 60 lb/min. Another popular myth busted--you can't run much of a FI setup on the popular 42 lb/hr (@3bar) injectors, need to step up to something bigger.

I'm posting the updated Speed Density paper HERE, and the example 'bad2good' spreadsheet HERE.

happy unscrewing bad tunes,
Marcin

Terminology and Confusion, part 2 (OLvsCL)

2006-11-04T01:30:00.000-05:00

Open Loop vs Closed loop tuning is another huge source of misunderstanding. Partially because it's just few terms out of a huge body of Control Theory (PID also comes from the same area), without understanding the rest of the principles and theory behind it. Another reason is because of how people use it, it's almost always referred to as 'OLSD', as if it was one thing, which it is not.

Open Loop and Closed Loop are just a methods of control of fueling. OL is basically a system with no feedback. Think of a sprinkler system that sprays the lawn whether it needs it or not. To contrast that, you have CL--a system which takes the output if its own operation as in input for the next round of calculations. In practical terms, it would be a sprinkler system with a ground wetness sensor, and only activating the sprinkler system if the ground is dry. The good part is not wasting water when the lawn doesn't need any more. The bad part is that we actually need sensors, threshold levels, hysteresis models, and other scientific junk, just to keep the damn lawn from drying out. This is definitely a place to consider effort vs benefit.

So what does it mean for a car? The main benefit of OL control is the direct relationship between what you tell it to do and what it does. It will do exactly what you tell it to, which is good if you tell it the right thing, and potentially catastrophic if you don't. That's why most tuning is done in OL--you want to see exactly how much airflow (MAF or VE) and which commanded AFR (OLFA or PE table) yields a particular AFR. This is the entire logic behind tuning--once commanded and resulting PE agree 100%, you can back calculate the airflow from displacement, pulse widths, injector flow rate, RPM, MAP, IAT and AFR. This is how you obtain airflow characteristics of an engine, no matter if it's with MAF or SD approaches.

Once you obtained that airflow characteristic, you could continue running in OL, and all the environmental changes would show up as change in airflow numbers. In SD, VE table is calibrated in what I call GMVE units, which take temperature and barometric pressure into account. This means that if that pressure or temperature changes, it is easily recalculated to current conditions. In MAF mode it's even simpler, more airmass cools the hot element of the MAF sensor better, automatically giving you a new, adjusted reading. Both models work just in any condition. (this is an answer to all the 'do I have to retune for weather?' questions that show up at least 3-4 times a week on forums)

So if it works so well, then why would we ever need CL one might ask? Doing math for all these models is great, everything agrees, but in practice, things like airflow measurement, or air fuel ratio measurement are an inherently difficult problem. Tuners drive around and scan and know what to adjust when. Normal people dont do that, they hop in and just want it to work, without scanning, analysis, and reflashing their car's computer. Thus, CL became that automatic tuner. It looks at data from different sensors, and if it consistently points at a new better setting, it adjusts. It's a perpetual feedback loop, not so commonly refered to as the Closed Loop. This model of course has its limits. While it will adjust to things like weather changes, or driving through the Rockies, it will not adjust for racing camshafts, huge heads, changes of displacement, and other significant changes to the airflow. Car's computer is willing to adjust, but also must be able to detect hardware failures. To a computer, airflow reading way out of its usual range is flagged as an abnormal event that should be looked at, while to a human it just might mean we put some heads on it. Computer has no way of knowing which one it is, we must tell it.

If you read and understood the last two paragraphs, you might have noticed, that a human tuner, and CL mechanisms (fuel trims) have the same function: to observe and adjust airflow changes. If you think about it, what we usually call the OL tuning method, is really CL--except that the mechanisms doing the adjustments are not automatic and computerized, but human, and done outside of the system.

This brings me to conclusions: in part 1 of this writeup we learned that MAF mode doesn't really work off MAF alone, and now we learned that Open Loop is a human powered Closed Loop.
I think what happened here is that we got lost somewhere between lack of technical understanding, and the traditional American tendency to polarize and zealotize (is this even a word?) concepts. This isn't your usual Coke vs Pepsi, Chevy vs Ford, Republicans vs Democrats war of ideologies. Reality is complex, and simple models are just too simple to describe it. That's why when we want a flexible system we end up doing hybrids, as there usually is no 'one size fits all' solution.

So the lesson from this is to learn, explore, and never be afraid to look at an alternative solution, as in more cases than not, you'll both be right and wrong at the same time, just for different set of parameters. There are very few absolute rights and wrongs, but if you are comfortable with all the alternatives, then at least you have a good chance of picking the best solution for your application, your purpose, your environment. If you're a tuner that always wants to run on the rugged edge and get as close as possible to 100% of potential, you probably want OL-SD. For a daily driver that doesn't get scanned too often, CL-MAF or CL-SD are the way to go. If you're bracket racer and you want as much consistency and control as possible, OL-MAF will probably yield you the desired effect.

Don't be a close minded zealot--just because a buddy with a fast ride told you something, doesn't mean it's going to work for you.

Terminology and Confusion, part 1

2006-10-18T15:32:00.000-04:00

A lot of big words get thrown around on all the forums, but how many people actually understand what they're saying? Once you actually read into their posts or problems, it quickly becomes obvious that they either don’t know what they're saying, or they just answered their own questions without knowing it.

The usual example: MAF tuning vs. SD tuning.
MAF tuning is not a _pure_ MAF tuning. During sudden changes in throttle input, or any other MAP jumps, the PCM prefers to refer to the VE table for airflow lookup/calculation. If you're not sure how VE table express airflow can, I highly recommend reading my 'How Speed Density Works' paper. If this was a "pure" MAF system, ALL requests would come from the MAF and MAF alone.

GM decided to make it into a hybrid system. Why would they do that, might you ask? MAF can deliver very precise, low noise signals, providing simple devices that can be easily calibratable to different applications, and have a reasonable range and resolution. But it also has a problem with not having the cleanest signal when not much airflow is going through the MAF sensor, or failing to deliver a smooth, universal airflow. Speed Density calculations however are just that--math. It's not dependent on physical conditions, thus not affected by the non-uniform airflow at lower MAF frequencies. As long as all the necessary sensors (RPM, IAT, MAP) are healthy, and all the lookup values (VE, displacement, IFR) are correct, the airflow numbers are going to calculated correctly, despite physical conditions like low, or reverse airflow. The PCM itself is very much airflow source agnostic and it uses whichever source is better suited, or at least yields less erroneous values. Another neat side-effect of having both Speed Density and MAF working together side by side, that if you detect MAF failure (DTC codes P0102 or P0103), the computer seamlessly falls back onto then pure Speed Density mode, so you can safely drive it to the mechanic.

So to all the MAF pundits: you can complain about SD all you want, but the truth is, you're running in SD at least part of the time you run your car, as there is no such thing as 'pure' MAF move on our PCMs.

Some smart guys saw it as strength, an advantage to this dual-source approach, and SD tuning became a reality. Turn off MAF, run in pure SD, and dial in your VE, so it precisely describes the breathing capability of your setup. What do we do with MAF then? After 4000rpm it's going to take over completely, and we're going to be ignoring our new perfect VE! That's when I figured out how to 'map' the airflow calculated from the VE table onto the MAF frequency-based scale. This way we have brought back the dual-mode capability to the system, just like the system is designed to work, but now it has new data, tailored to our application. Because of that single source of airflow data, if the PCM decides to jump from MAF to VE based airflow, the airflow numbers should be smooth fit, not causing wrong air mass readings (that's used to look up timing advance, which in effect can cause bucking), or airflow, which in effects causes knock, or at least hesitation, making for a terrible drivability.

An alternative, interesting approach was to use AFR%Error to manipulate MAF airflow numbers, to establish the new MAF calibration. While theoretically it should yield an identical result as it would with my Dynamic Airflow onto MAF frequency mapping, the reality is too fuzzy, and often yields discrepancies significant enough to cause the engine to get different numbers than it should have. While I do not recommend this method for MAF tuning, I _highly_ recommend using it to verify the VE tune, as well as to observe daily environmentally influenced fluctuations.

Another note to MAF pundits: If you claim that MAF is better purely on basis of not being able to get SD working correctly, you might want to watch out for your 'MAF' tune (I put it in quotes because it's still a hybrid with SD). Every time you get on the gas more vigorously, your untuned VE table will rear its ugly head, and give you an AFR spike, bucking, knock that's hard to reproduce, hesitation on takeoff and general unpleasantry. There is no escape from doing VE on these systems. Even the most hard-headed MAF tweakers out there have given up, and modify at least the idle areas of VE as without that, making the car idle is somewhere between difficult and impossible.

To farther prove my point about the MAF having very different characteristics on low vs. high airflow situations, let me demonstrate a typical spread of samples from < 5000Hz, and above 6000Hz.

As you can notice, the scatter is quite significantly higher in the lower frequency areas (look at R^2 values). I use different sets of parameters to filter out noise for these two distinct regions, because of their different characteristics, I use 5500Hz as the usual boundary between high and low noise areas. I had a very large smile on my face, when I downloaded LS2 and LS7 stock tunes, and saw not one, but two MAF tables, switching at 5800Hz! Apparently GM also has two different sets of filtering parameters for the two distinct characteristics of MAF and the signal quality based on airflow.

In the end, remember what SD or MAF is: a source for airflow figures. If the PCM doesn't care where it gets the numbers from, why would you?

Most of the arguments out there stem from lack of understanding of how they work, and what are their limitations and applications. There are a lot of myths out there, i.e. SD not being able to compensate for altitude or temperatures. This is just plainly not true, as that's precisely why MAP and IAT sensors are there for. MAF has problems with the small upper airflow limit, and reversion on some setups, so it's not perfect either. Understand both, use what works better for you.

Part 2 is going to be an Open and Closed Loop, should be up in few days.
Hope this helps,

Marcin

Tuning Methodology

2006-09-26T18:44:00.000-04:00

Someone brought it up on the forums, and it's a good thing, so I'm reposting it for the sake of completeness on my site.

1. Try to keep tuning sessions as close to repeatable as possible, same gas, same route, same time (like driving to/from work) work great. This way you get approximately the same amount of samples in the same temperature range. If the weather is particularly extreme (super hot, extra humid) take a note of it, expect your values to skew one way.

2. Long steady inputs--I can't stress this enough, this is #1 reason why most people never get their numbers straight. If you get on the throttle--hold it. If you get off throttle, don't half-ass, lift completely--this way it's easy to filter unwanted (transients/not steady airflow) cells. In HPTuners, there's now way to ask for a derivative of anything, so there's no way to know if you're accelerating or decelerating. EFILive has 'filter out if value changed more than X %' capability

3. Warm up the WHOLE car, don't just look at the coolant temperature. Fuel warms up too. If you don't believe me, go scan for a while, and then go fill up with new fuel, and continue scanning, I promise you your trims are gonna go nuts. Fuel temperature affects atomization, which affects how complete is the burn, which affects the resulting AFR. The rule of thumb here is 15 minutes of normal driving before you log for VE.

4. No lugging it in tall gears (5-6th). Laziness gets the best of you, and you end up tooling around at 1500rpm in 6th, give it more gas, it knocks. While it's not a real dangerous knock, but it will show up in your logs, and you might end up pulling timing where you really didn't need it. Avoid doing it in general, not just for tuning, if you need to accelerate, downshift.

5. Be creative -- use the environment. Hills are GREAT for getting the more extreme cells. how else you're gonna get these 20kPa at 4000rpm cells without decelerating? (you can always use a real dyno, like Dyno Dynamics)

6. Be observant, learn the ways of your car. There are things that are particular to every car, and the most seasoned tuner won't notice them, simply because they don't have the milage on your car you do. Use it to your advantage. My car, for example, has random knock 1600-2000 rpm; it's just tight suspension on lousy roads, making things rattle and set of knock sensors. If you give it more throttle and it binds up, then there's no knock, but driving gently makes it rattle. Pure 100octane and lame timing won't cure it either.

7. Organize, label, and take notes on your logs. Temp/pressure/humidity/terrain often explain a lot of goofyness in the logs. once I was chasing what I thought was an intake leak, but it turned out to be that the guy lived in some serious hills. During a 20 minute commute between work and home, his WOT MAP would drop from 100kPa to 93kPa max. I didn't know that, he didn't tell me. It took us a while to sort it out.

8. Tuning is science--don't ever forget about that. Repeatability, changing one thing at the time, taking notes, not falling into routine or assumptions, all these boring things psychotic science teachers tried to drill into your heads in high school--they weren't cool, but they were right, so deal with it.

9. Keep your hardware fresh and clean. If you see AFR scatter more than usual, check your filters. If you see MAP not getting up to where it used to be in the same conditions as before--your cat might be clogged up. If you installed headers and you're tuning for them and it's starting to converge on some new numbers but then out of nowhere they go crazy on you--retorque header bolts, something might have gotten loose after few heat cycles, etc.

LS2 VE tuning spreadsheet

2006-09-23T03:22:00.000-04:00

I've started reading LS2/GTO/Vette boards, and a lot of people seem to have a problem with tuning their VE, simply because it's different than what they're used to with LS1.
The funny part is that the form we see in LS2's is not functionally any different from the old form. It's just different numbers, but the shape of the 3d surface is the same. Now that my Speed Density paper is out, we know that the factor is exactly R/CylinderVolume. However, because it is a linear factor, mutiplying the VE table by AFR%Error should be the same, no matter what factor is there. So viewing the table in the traditional VE is more for information than actual functionality.

Theo ne new thing I'm trying with this spreadsheet is to see how people use them:
Do you want everything on one tab?
Do you want step by step on different tabs?
Do you want everything on one tab, with multiple copies of the setup, so you can keep track of progress?

Leave comments, send email/IMs or whatever, I just wanna know how I should make them for the future.

DOWNLOAD

Enjoy,
Marcin

How Speed Density works

2006-09-23T02:54:00.000-04:00

This is the most important work I've ever done, or at least it feels like it. It takes you from sensor data through calculating pulse widths, and all the forms of VE and their particular meaning.

I feel particularly proud, because it all makes sense so far with everything else we've been discovering how these cars run, how the PCM operates and explains a lot of peculiarities of the model GM decided to employ.

The understanding of concepts helped me tremendously. Some things you take for granted, others you just kinda understand, but this puts it all in black and white, solid, precise numbers that show you what and how you wanna run in your car.

I tried to make it as universal as possible, but because of the GM-particular VE form (that I refer to as GMVE) a lot of the paper deals with that. However, the rest is just about universal. Some of the language like ECT (coolant temp) or IAT (aircharge temp) might not be universal, but I tried to explain what they all mean at least at one point, so you can change IAT to AIT if that's what you're used to.

The cool part is that I have gotten some data that confirms the formulas. I've logged all the sensor data necessary, and tried to calculate data normally we'd obtain through PIDs. Cylinder Airmass seems to be very close, with less than 2% error through the whole range of values. Other values dont seem to be that far off either. Considering how many filters there are on anything airflow related, I consider this to be a very good result completely backing up my work.

Due to the fact I needed a lot of math formulas displayed nicely, I had to put it in a Word document, and not a webpage. If you know a way to easily convert it over to a webpage, please let me know, until then, it's just a paper.
DOWNLOAD

I also include a spreadsheet with stock 2004 Z06 values, and convert them to other forms using my math, side by side with the originals.
DOWNLOAD

I hope you guys like it, cause this was a shitload of work.
Enjoy,
Marcin

Cylinder Volume Spreadsheet

2006-09-09T22:49:00.000-04:00

This is so simple I'm embarrassed to post it. At the same time, I've seen it messed up too many times to be unaddressed.

Math:
Cylinder Volume= Pi * radius^2 * height
Engines:
Cylinder Volume= Pi * (bore/2)^2 * stroke

To justify releasing it, I integrated a trick where if you so far have tuned your VE but haven't changed your Cylinder Volume, I also give you a number to multiply your entire VE by. This way you don't have to retune the whole VE again.

Also, the inputs are in inches (unfortunatelly popular with the LSx crowd) but it gives you output in Liters, which are the units to be used in HPT's Cylinder Volume field.

DOWNLOAD

enjoy,
Marcin

Rated fuel pressure on SVO 42s is...

2006-09-06T23:44:00.000-04:00

Rated fuel pressure on SVO 42s is 43.5psi (3bar). End of argument.

Here's a proof:

So apparently my empirical experiments year and a half ago were right 3bar it is.
and now we know better...

UPDATE:
I got another one from another friend, so here's more examples on a typical flow spread

Unscrewing a Bad Tune

2006-08-30T14:41:00.000-04:00

This is something I keep happening time over time: you build up your car, you get a mail tune, or a dyno tune done by some hack, and you hate how the car drives and performs, so you save your pennies, get yourself a tuning package, and you try to do it all yourself. This is exactly how I started, and back then there was little in terms of writeups. These days the problem is that there's too many writeups, and some of them are better than others, however, as a newbie, you have no way of telling. Another big question that keeps coming up is 'What do I do first?' which is a great question, however there's no good answer to, as that depends on what's screwed up.

So this writeup is pieced together from a long collections of emails and forums posts.

1. Set IFR to your injectors and fuel pressure. Please measure it,
see if it holds fairly stable when you give it some gas, you might be able to find a weak spot or a deficiency in your fuel system.
2. Set Primary VE to something that makes sense. Start with a known good tune for a similar camshaft, heads, and headers. It doesn't have to match perfectly, as every car is different regardless, but it will get you in a good starting position.
It wont be perfect, but it should be much closer to what you need than a stock tune.
3. If you have older car with Primary and Secondary VE tables, then do an 'adaptive copy' (just
copy the relevant rows) of the new Primary VE to Secondary VE , or use http://www.marcintology.com/tuning/VE2bar.xls
to do it for you
(http://redhardsupra.blogspot.com/2006/02/new-ve-tuning-spreadsheet_03.html
has a description of what does it do)
4. Copy high and low octane spark tables from that 'good' tune into yours. If you can't find a good one, I like to start with 02+ Z06 spark tables, as they account for more compression, better flowing heads and a higher lift cam, which makes it closer to what most modded cars have.
5. Blend in the idle areas of spark with values that start at 36* at low rpm and end at about 30-32* at your rpm/cylinder airmass.
6. Use the same blended values in idle areas of spark in the "idle
spark in gear" table. If you have an automatic, also copy it over to "idle spark in park/neutral".
7. Copy RAF drive table over from a good known tune. Again, just like in #3, it won't be perfect, but will be closer than stock. If you dont have a well tune RAF example, up the RAF values in the usual range of ECT by about 3g/sec.
8. Put the car in SD (MAF Fail Frequency set to 0Hz). Start it up, verify
that it goes into SD by reading DTC's (it should throw P0103). if it
doesnt, turn it off, start it again, sometimes it takes 2 or 3 starts.

At this point, you have 2 processes to go through: RAF and VE. VE
has multiple ways of doing it, and of course everyone claims their to
be the best, I'll show you the simplest one that should work perfect
to get the initial 'daily drivability' to be really good, and can be done on any car as it uses stock oxygen sensors.

If the car doesn't die, start driving around, logging for LTFT and
STFT and O2s on both banks. (default setup will do that if you're unsure of what to log, just hit 'reset' in the 'Display Table')

Again, these procedures only make sense in SD, so make sure you're truly in SD.
One trick is to set the codes to set SES light upon the MAF faliure, this
way when MAF fails (aka SD takes over) you get the SES light. I refer
to it by now as the SD light ;)

Drive around in SD, let's get the daily drivability done first, so
keep it under 3-4krpm (depending on gearing and powerbands) logging
fuel trims.

Once you get about 25 samples per cell across the whole range you're
trying to tune, stop, save the log. Then open up the VE2bar.xls I
mentioned earlier, and copy and paste the appropriate tables into it.
Let it do it's thing, and copy the results out of the full- and half- resolution tables, and apply them to the corresponding VE tables. On the
beginning do 'paste special--% full' so it will get big changes done
quickly. Once you get much closer to the target (less than 5% off) I do 'paste
special--%half' so the changes are more subtle and you dont 'overshoot.'
This spreadsheet is made so once you get some values within that -4 to
0 range, it doesn't try to adjust them. The reason for it is that if
you'll tune it perfectly for 0%, you'll have what I call a 'knifeedge'
tune, a tune that will run rich or lean depending on atmospheric
conditions, and as such, will be unpredictable. Once we're a little
bit on the rich side, computer treats is as the same safe set of
settings, and will not try to preemptively pull timing, like it would
if some of the tune was on the lean side.

Once you get a correction done, save it to a new copy of your tune,
flash it, and then reset the fuel trims (that's in the live controls
section of the scanner).
Go for a 10-15 min drive. Because of the reset, the fuel trims will
initially go nuts. That's good, that means it's learning aggresively, and
trying to find it's new set of 'happy' settings. Stop the car, turn
it off, start it up again, do NOT reset fuel trims now, just start
another logging session. The second session has dual function:
1. It verifies that the changes made sense, and they do work better
than the previous setup.
2. It gathers data for another iteration of the VE tuning.

If you gather enough data (it's very useful to set the 'minimal cell
count' to 25 on the LTFT and STFT charts, this way nothing will show
up until you get 25 samples, which guarantees a clean, consistent
dataset) just start looping through the process of
scan/calculate/adjust/flash/reset/ride to adjust until the fuel trims
will all come back in the -4 to 0 range.

Once that's done, do RAF:
1. Scan from full cold start to full warm. Turn off fans for this
purpose to let the car warm up to ~220F. Scan for ECT and STIT.
2. Create a custom histogram of ECT vs STIT, and display the gathered data in it.
3. Do "Paste--Add" the resulting table to the corresponding RAF table.
4. Wait till next time the car is fully cold, and redo the whole
process again. Repeat until the STITs are <0.1g/sec>
throughout the whole range.
5. (automatics only) You get to redo the whole process again, but not in Park, but in Drive, as the RAF tables in Park/Neutral are little different.

If the car doesn't want to idle with the initial settings, you have to
ballpark the VE some more. Usually you're overfueling (which is made
very visible by a 'surging' idle) so cut down the idle range VE values
by 10% (select the cells in question, put it 0.9 and press * to bring it down to 90% of previous values), flash, try again, until it's reasonable enough to do a real VE scan which will get the VE tables set precisely. The whole goal of this 'ballparking' is to get it close enough that it can idle on its own, thus allowing us to gather data for a proper adjustment.

If you're familiar with tuning VE with OL and WB, then you can do that
instead, but it's really not much different, just few extra steps.

Enjoy,
Marcin