HPTuner experiments

Scanner Basics

2010-12-04T17:22:00.004-05:00

I've been playing with this tuning business for almost six years now, and one of the things that keeps me baffled is how come people still don't use the scanner to its full potential. The scanner is the doorway into a goldmine of information, so it would logically follow that mastering operating that door would be crucial. Thus, in this post I'm trying to show few simple tricks and setups that can give you more insight.

The graph below I call the 'Street Dyno,' and it is the simplest, the most fundamental graph for assessing performance. DynAir is basically HP, and DynCylAir is TQ. They're directly related, so I use these two pairs interchangeably. With this in mind, the bottom graph is your typical dyno chart, except in terms an engine management system can understand. The top graph has RPM and Throttle, and they're there mostly for reference, so you know when you went WOT and how far did you get on RPM. The unique thing of this particular data is that by about 7000 RPM, the Dynamic Airflow gets pegged at the maximum of 512g/sec, which is an internal limitation of this ECU. Also, for Throttle, I changed the scale to go not from 0 to 100, but 0 to 105, so when you go WOT, you don't have the Throttle line overlapping on the edge of the whole graph, as sometimes, depending on color combinations it might effectively 'disappear.' Simple trick, but useful sometimes.

On this graph, you also have time, so in this case you get one gear 'pull' which is nature's way of 'integrating the area under the curve'. It is a very good way of assessing the full power, not just looking at peak numbers. If you got few different settings you want to try, this is the chart you want to use. Make your changes, keep doing the same run, compare how long it takes to traverse the same intervals of RPMs, and you'll get much closer to the optimal AFR and spark combination. To gain precision it also helps to keep the number of scanned PIDs to minimum. The number changes for different ECU's, so I'll let you figure out from HPT's help files how much is too much for your particular platform/year/model.

The graph above is 'Street Dyno' with the addition of temperatures, which often are an indicator of hardware issues. Both AFR and spark have multiple modifier tables that are referenced against ECT or IAT, so it's good to know both temps are in a 'healthy' range, and not introducing more problems indirectly by altering your fueling or timing. If your IAT goes up and not down as you increase your speed, your intake is not getting any of the cold, moving air; take a look at your airbox, how it seals, whether it takes in cold outside air, or warm engine bay air. Similarly, ECT should get some better cooling at speed, if it doesn't, you need to look if the air is going through the radiator instead of around it. This graph is an example of a healthy setup. IAT drops the moment you increase your airflow, and ECT follows, it's just slower to react as it deals with liquid not gas. Another addition to this graph is Knock Retard, which i purposely placed right against the horizontal divider to show you how sometimes even despite different colors, graphs can be nearly invisible. It might be visible on your computer at home, but how visible would it be on a small laptop screen with the 'high gloss' coating? Sometimes you have to help your hardware with small tricks like I've described in the previous section.

This setup is all about fuel monitoring. It lets you know if your injectors' fuel flow is keeping up with the airflow. The base on the bottom is just in the previous graphs, the 'dyno' graph. But now we also get to monitor AFRs and IPWs. It's good to know that both banks of injectors are in good working order, and it's usually easy to see when one side is quite different from the other. It's important to have both injector settings set up to the same scale, as this way if they're identical you will see one line, but if there's discrepancies, it's easy to see the two lines diverging.

Similar trick is used for the AFRcommanded vs AFRwb. If you set them up on the same scale, they should follow each other closely. Of course widebands aren't very precise instruments, so even on a well tuned car expect some jitter. In this case, when the car is just cruising, you can see the AFRwb get a little off on shifts, but the moment the car goes WOT, the AFRwb follows AFRcommanded very nicely.

Another thing on this graph is the Injector Duty graph. It's a good quick indicator if you're not stressing your fuel system too much. On this graph you have a system that's utilized to the fullest, but doing it safely. At peak it reaches about 90% of it's full potential, which is about as high as you'd want to go.

This graph is about Timing vs Torque. This setup usually takes some fiddling with scales of both measures. Peak TQ means the highest compression, which means the highest flame front speed, thus needing the least time to burn the entire mixture. Thus peak TQ should be accompanied by the lowest spark advance. So in general, peak in one should be the valley in the other. As you can see in this pic, that's usually the case. The highest the green line goes, the lower the red line gets, and vice versa. I placed the white vertical line at the peak TQ (or in this case, airmass, which as I've mentioned, are conceptually interchangeable) to see if it matches the lowest valley in the spark graph. It doesn't, it's not far, but it might be something to adjust, if ever so slightly. Also, we can see that the timing is fairly low on the beginning of the WOT run, in lower RPM. Since the airmass isn't very high there, we could probably gain a good amount of power by upping the timing in that range.

After I wrote this post, I sent the draft to few friends, to get some feedback, and lo and behold, one of them found something in the logs that I overlooked. Look at the graph comparing the two oxygen sensors (the narrowbands)

One of the sensors is dead. No matter what happens, it gives the same output. The other sensor shows signs of life just fine.

And this is probably the most important point of looking at logs. If you're like me and looked at the WOT data, because that's what I was asked to do, you might skip over important bits of information, which seem to be irrelevant; after all why would I look at narrowbands during WOT? Someone with a fresh set of eyes and less bias might come in and spot something as important as a dead sensor right away. Reading logs is all about a scientific approach--don't go in with expectations, because you will only see what you want to see, and not what's truly there. After all, you want to learn/spot something new, don't you?

MAF vs SD comparison

2010-02-20T16:08:00.000-05:00

Long time ago I realized that we never look at the behaviour of the stock cars, only at the (often misbehaving/miscalibrated) modified ones. Thus, we don't really know what the cars supposed to behave like from the tuning perspective. Some time ago I talked a friend of mine into scanning a truck of his that only has a K&N on it, which is about as close as we're going to come to stock. The good part about this guy is that he's as mind-bent on tuning properly as I am, thus he's got a wideband AFR sensor on it, with the serial output for increased reliability and precision. So he went for a ride, scanning all the usual suspects: RPM, throttle input, temps, pressures, airflows and airmasses from both SD and MAF modes. The logs were done in OL, so no fueling modifiers should be active. I wanted to see how good SD and MAF are when it comes to predicting the correct airflow without any aid from corrective mechanisms (CL).

Everything I do in this writeup is pretty much a demonstration of concepts discussed at length in Three Airmass Models so please refer to that if you'd like more details.

What I did here is I used the formulas for the three separate ways of calculating Cylinder AirMass (CAM).
Two of them (MAF, SD) are predictive--they try to describe the airmass by either measuring the sideeffects of airflow itself (MAF), or measuring the attributes of the airmass passing through the sensors (SD).
The third way (CAM from fuel usage calculations) is unique in the way that it gives us an approximation of what has happened, not what is going to happen. We take information of the fuel usage (IFR, IPW) and the observed AFR to obtain the airmass figures.

All three airmass numbers are describing the same entity, thus they supposed to be identical. Assuming that the engine is a closed system, we should be able to assume that the airmass in the intake should result in the same airmass approximated by the wideband sensor on the exhaust side. This is a perfect setup for performing calibrations. We can either calibrate the MAF by juxtapositioning the MAF-resulting CAM against the CAM from the exhaust. The same idea can be done in parallel for the SD model, placing SD calculations' based CAM against the CAM from the exhaust side.

IFR*IPW*AFRwb=15*MAF/RPM

IFR*IPW*AFRwb=GMVE*MAP/TEMP

Once you perform all these calculations for your log, you end up with three new columns, and they all estimate cylinder airmass. In the perfect world, they would be identical. In this world, they won't. It would be pertinent however to take a look at how do the resulting values differ from each other when you look at them not one value at the time, but as a whole dataset.

The silly side effect of doing calibrations this way is that if you plot the various CAM pairings against each other, they should form a straight line, after all y=x, so all points in the set should be of the (x,x) form, for example (0.1,0.1), (0.3,0.3), (0.55,0.55) etc... This makes it very appealing to look at this problem graphically, as most data should be right along the y=x line, while the more troublesome data points will be easily spotted simply by visual inspection of the graph. We'll see more of this later, but for now just try to expand your thinking from single-point calculations to calculations for a whole set, and their graphical representation.

So this picture has the CAM from fuel on the horizontal axis, and it has the two airmass predictors (MAF, SD) on the vertical axis, grouped by color. The numbers on the axis are the values for the airmass. As you can see, there's some obvious outliers, and no clue to their source. So how would one go about getting to the bottom of the source of the outliers?

Excel isn't particularly useful for exploratory data analysis. Matlab has some new 'data brushing' functionality in it, but it's still a bit clunky. A while back I found a program that is quite perfectly suited for such a task: Tableau. Officially it's a program for 'business intelligence,' whatever that means. I use it because it's lighting quick to adapt to changes, which allows me to rip through hundreds of different scenarios and ways of looking at the same data. Not only it does the regular charting, but you can group, filter, color, summarize, subtotal, etc on just about any number of parameters. I've been using it for few years now, but I haven't had a really good clear case where I could show off why it's cool. Searching for the source of outliers in a large dataset is a good showcase of what it can do for us.

First, I did a graph of SD-sourced CAM against the fuel consumption-sourced CAM. That we've seen already. So the new thing here, is I colored the data samples according to their corresponding MAP value. On the right side you get a little color scale of which color gets used for what MAP value. The scaling of the colors is adjustable, and I adjusted the center (gray values) to be at 35kPa which is a common value for MAP at idle. This way all samples with MAP smaller than 35kPa are red, and everything above 35kPa is green. I did this to isolate at what conditions do the outliers occur. We clearly see that all outliers are very red (below <35kPa). So it is not likely that knock retard could be a cause of these skewed readings, as knock usually occurs under high pressure, which is not the case here. So what else could it be? How about temperatures?

IAT also does not seem to be the cause, as the outliers seem to have the same values as many other samples that fall directly in line. What about ECT? All I had to do is change the source of color from IAT to ECT, and we get a new graph.

ECT also has a variety of values for the outliers, but again, no clear pattern emerges in which the outliers would react to different ECT than the 'proper' values. What else could it be? How about different throttle inputs?

In this graph I scaled the coloring in such a way that the off-throttle/very light throttle would show up as gray. There's a definite uniformity in that the outliers all occured at off-throttle/very light throttle. So let's summarize what we know so far: outliers occur are independent of temperatures, and they occur only at very light throttle and very low MAP values. Could it be deceleration? If it is, DFCO could be activating, wreaking havoc on fueling. So how else would the DFCO show up in our data? If it lives up to it's name, it cuts fuel delivery, causing abnormally high lean condition. Let's color up our graph based on the AFR from the wideband sensor:

AFR is definitely significantly lean in all the outliers. So I think it is quite safe to say, that the DFCO caused lean condition is the cause behind some of the CAM estimations being severely off, creating these visually sticking out outliers.

Another not only cool, but also very useful part of Tableau is the ability to select groups of points, for either inclusion or exclusion. I selected all the outliers, and I excluded them from the graph, creating this:

Isn't is a much cleaner graph? Look at the values on the axis--no more samples with 1.6g/cyl, which is achievable only on a FI car with a generous amount of boost. There are still some values that stick out, that are not exactly on the trend line, but they are the inherent noise in the system.

Now that we know how to get rid of outliers, let's compare MAF and SD directly against each other:

MAF is on the bottom, SD is up top. They both have noise, but they both also do a very good job of sticking to the trend line. The MAF seems to be a little noisier, especially on the low end of airmass values, where SD seems to excel. This is exactly why the GM uses the hybrid MAF/SD model: they leverage the stability of SD for lower airmass situation, and MAF for the higher airmass. It it quite literally the best of both worlds.

Since everything we've done so far been graphical, let's take a look at some numbers, to see if they back up what we could see by observing patterns.

There's a bunch of statistics tricks that are used to describe how closely two functions are to each other. I'm not going to explain all of them here, but here's the rundown for these who know what they mean:

Trend Lines Model

MAF:

SSE (sum squared error): 2.19023

MSE (mean squared error): 0.0002055

R-Squared: 0.998423

Standard error: 0.0143366

p (significance): < 0.0001

SD:

SSE (sum squared error): 1.07925

MSE (mean squared error): 0.0001014

R-Squared: 0.999398

Standard error: 0.01007

p (significance): < 0.0001

SD wins overall. Better R^2, lower SSE and MSE, smaller standard deviation of errors.

That was for the cases where we cleaned up the data. Out of curiosity, let's see how they fair when we look at the data before the cleanup.

MAF:

SSE (sum squared error): 22.7658

MSE (mean squared error): 0.0020751

R-Squared: 0.983645

Standard error: 0.0455531

p (significance): < 0.0001

SD:

SSE (sum squared error): 29.177

MSE (mean squared error): 0.0026694

R-Squared: 0.983759

Standard error: 0.0516667

p (significance): < 0.0001

In this case, MAF does a little better than SD.

So to wrap up:

Exploratory data analysis doesn't necessarily have to be painful and laborious.
Outlier explanation can be meaningful and insightful.
GM had good reasons to go with the hybrid MAF/SD model.

Hopefully this cleared some things up, as I've been getting a lot of questions lately about my methods of calibration. If you got any questions, post them up here, on IM/email me.

--Marcin

Injector grouping, the exhaustive search

2010-01-16T08:27:00.001-05:00

As you saw in the previous post, the way we grouped injectors was very simple, we simply sorted them by flow and picked 'top 4' and 'bottom 4' and that was it. It seemed to work well, but how do we know there isn't a better method.

Last night I realized that there are 8 injectors, so there's factorial(8)=40320 ways of organizing the injectors. Seems like a lot, but I figured there'd be a lot of repetition within each bank as we don't care if we get [A B C D] or [D C B A] or any other related permutations. Thus I figured this would be problem small enough that I could calculate the flow spreads for every possible permutation (exhaustive search, by the way of brute force).

Matlab of course has a function that can generate permutations of any set of numbers, so I let it generate the 40320-entry long list. Then I split the resulting lists into bank1 and bank2, and then executed all the calculations presented in the previous post. An additional step at the end was summing up the two AFRdifference results, in order to come up with one final number describing the 'goodness' of the combination. Then I found which flow permutations came up with the best (lowest spread) number. I pick one of them, and that's my 'best' injector grouping.

So how did the exhaustive search results compare to our 'sort and split down the middle' approach? Pretty good actually! I ran the optimization for 3 sets of injectors and 2 of the 3 permutations we came up were actually optimal, according to this script. The third permutation was different only in placement of 2 swapped injectors, and even then the resulting difference from what we picked was minuscule. Why does the simplistic approach work so well then? I think it happens because if you pick a group that isn't a 'bottom half ' or 'top half' of flows, then you end up with one group that's very closely matched, but the other group ends up inherently with flows that are from two ends of the spread, negating the positive effect of the extra close group.
I have some other ideas on how to generate the final 'goodness' number. For right now it's just a sum of the AFRdifferences, but it could be something completely different, I could go with standard deviation of the flows within the bank multiplied out with the range of the means between the means of two banks for example. It's just something to play with, and now that I have an infrastructure set up for it, it should be easy.

I put the quotes around the 'best' when talking about finding optimal grouping, because there are many other permutations that generate different, but effectively identical permutations. So once you get results, you still can rearrange the numbers within the bank, to match that particularly high or low flowing cylinder.

When I originally came up with this, I figured I'm going to have to figure out how to eliminate all the 'duplicate permutations' of numbers that are reorganized within the bank, to speed up the process. There was no need for it. The entire script, with setup, calculations, and display of results, took a grand total of 0.03 seconds on a 2yr old 2.4GHz CPU. Right now this is just a Matlab script, which I know is not particularly popular with gearheads due to cost ($2000!!! unless you get the $100 student version). I will try to figure out how to make a standalone program from this script, so you have optimal flow groupings every time you redo your injectors.

--Marcin

Per-Bank Injector Grouping

2010-01-10T14:22:00.003-05:00

So while discussing my findings from earlier this morning, I had this stray thought: since we know what which injector flows separately, why don't we group them in a way that the Fuel Trims can account for easily?

One common trick is to put the highest flowing injector on the leanest running cylinder. This makes sense; we might not know how much more air that cylinder is getting, but at least we can give it some extra fuel to accommodate it better. This is obviously not the most precise technique, but as far as rules of thumb go, it's not a bad one to practice.

This approach made me think though: what kind of fueling are the other cylinders getting? We might be OK on average, but it does not mean that the per cylinder fueling is anywhere near proper. So how would we make this better, make the per cylinder fuel delivery more consistent?

We already know the flows of all injectors individually. We don't know, and unless you stick an O2 probe in each runner, we will not know which cylinder is flowing what amount of fuel, so we can't just pick the best injector/cylinder combo and hope that airflow distribution is similarly close. What we have however is Fuel Trims mechanism that in Closed Loop treats the engine as two banks with two separate corrective values.

So what would happen if we group our injectors accordingly not to their individual flows, but in groups of four? The discrepancy between banks would be bigger than if we placed injectors randomly. But the fueling within each bank would be much closer! We cannot control fueling within a bank of cylinders, but we can control it per bank. Thus the discrepancy among the banks will be corrected with Fuel Trims, but the discrepancy within each bank is going to be minimized, thus providing us with a consistent fueling.

Enough blabbing, let's see some numbers:

These are three sets of SVO greentops for which I have flow sheets handy.

Some explanations are needed:
The colors in the graph are in accordance to the flow number. The highest numbers in the set are red, the lowest are green, and the rest is somewhere in the middle accordingly.

Avg-bank are the average flows for each bank (bank defined in as the first four and the last four injectors). They're fairly close, as random placement tends to come up with good averages. This is however not what we want, as we'll see later.

Range is the difference in flow within a bank, how far the maximum and minimum are spread apart.

Within Bank is the percentage of how big the range is comparatively to the average.

AFR Difference is the impact that 'within bank' difference in flows has on AFR, when commanding 14.7.

As you can see, the differences in AFR within each bank can be up to 0.24. Remember all these flow sheets data I have are already for injectors that have been cleaned, so stock injectors can be in a lot worse shape that what you see here.

Now let's take a look at the same injectors, but grouped. On the next picture, I simply sorted the flows, and the rest is the same, but look at what difference it makes for the differences in flows within the same bank. Since the coloring is tied to the values, and we sorted by values, now we can see the groupings of injectors with similar flows by being of similar color. Kinda cute.

Across all the injector sets, the AFR fueling differences dropped about 0.1. Set 2 has one injector that flows significantly more than the rest, and that's not something with can get rid of, having only 8 injectors total, 4 per bank.
The Daniel set has nice consistent gains, bringing one of the banks to within 0.03.

So why do I care for AFR change of 0.1? Because there is no extra cost associated with this process. You're going to be installing injectors, you already know what they flow, so why not install them in a way that yields more consistent results? All it takes is a simple sort and then installing them in the ordered determined by injector flows. You're getting something for nothing. The good part is that there's a gain. It's not a large gain, it's not going to solve all your fueling problems, but it should nudge it in the right direction.

--Marcin

SVO Greentop 42# testing at 3 and 4bar

2010-01-10T10:45:00.004-05:00

This is nothing new; I've written about it before HERE. However, I don't know why this is still such a ripe source for arguments, thus I figured it's time to revisit.

A friend of mine got some SVO Greentop 42s, and send them to Deatschwerks for some cleanup and flow testing. He wanted the injectors tested not at some arbitrary rated pressure that the injectors will never see in his application, he actually wanted to see what they would flow at the intended rail pressure. He called up Deatschwerks, talked to whoever did the service, and asked about the additional testing at the GM standard of 58psi. They said no problem, and sent him not one but two flow sheets: one at 43.5psi and one at 58psi. This sort of data should once for all settle all SVO flow discussions, as it's done on the same bench, with the same injectors, by the same technician, hopefully with the same methodology. I love the smell of science in the morning!

Quick disclaimer is in order: I usually avoid any sort of endorsements on principle, as I feel commercialism ruins science, but I am going to make an exception here. I've talked in the past with David Deatsch and he's been very interested in what our little tuning community needs. So if you really want to get to the bottom of 'why my trims are off on one bank' sort of problems, give them a call.

Back to tuning...
So Daniel forwards me his flow sheets, I enter his data into Excel, and let's take a look at what we see:

or for people who like graphs:

So we have 8 injectors, they all flow a little differently. The red bars are the flow values tested at 3bar (43.5psi). The purple bars are the flow values tested at 4bar (58psi). The green values are a theoretical flow at 4bar calculated using the Bernoulli's formula.

As you can see, there's a discrepancy between the theoretical and the measured flow values at 4bar. The interesting part is not that they are different, but that they are different in a consistent manner. There's a whole area of mathematics that deals with this exact phenomenon, called 'Residual Analysis.' I've been told to cut it out with the math, so here's the super short version that's relevant to this post. Residual Analysis tells us that if there's a distinct pattern in our 'theory vs reality' then the underlying assumptions or models are wrong.

So there are few possible explanations here:
1. The injectors actually take on different flow characteristics at 4bar vs 3bar. Maybe they're more suitable to higher pressures, as they all flow more than they should.
2. There's a fairly consistent error in measuring pressure or flow.

So I decided to quickly explore option 2, as I wanted to see at what pressure the injectors would flow as much fuel as the flowed values would suggest.

So using some numerical trickery, I asked Excel "what fuel pressure would I have to apply to the injectors I have data for at 3bar, to get the flow seen on the 4bar flow sheet?"

And what Excel came up with was 411kPa, or 4.11bar, or 59.7psi. This is not just for one injectors, this is across all of them. Here's the results in graphical form:

As you can see, the theoretical and the real bars are much closer to each other this time. Some are over, some are under, but they're all close.

So this leaves us scratching our heads: is the flow bench indicating less pressure than there really was at the time of testing? Wouldn't that show up at the 3bar flowing too? Why doesn't the theory and the real results line up closer? What if it's the flow numbers that are skewed not the pressure? What other 'hidden variables' are we dealing with here?

Despite all this, I'd much rather use these flow numbers, than just assuming 42lb/hr @3bar converted to 4bar ignoring all the assumptions we've made in that process. Especially if you combined it with accounting for fuel pressures at given manifold vacuum, as I've demonstrated before.

And to come full circle to establishing the flowed pressure of SVO Greentops: they all flowed between 43.0 and 43.5 lb/hr at 3bar (42.5psi). Not 39.15psi, not 40psi, not whatever else people claim. Granted, that's also not perfectly aligned with the official 42lb/hr flow, but that probably can be attributed to freshly cleaned injectors. I wouldn't be surprised if the OEM's underrated their injector flows to make up for the average car user than never uses fuel injector cleaner.

Hope this helps,
--Marcin

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

From Airflow to Pulse Widths

2006-08-21T02:48:00.000-04:00

Ultimately, the function of the PCM is simple: measure airflow, and provide engine with enough fuel to match that airflow.

As just about anything in life, it's easier said than done. Airflow measurement is a notoriously tricky subject, and injecting fuel with a constant size injector against wildly varying pressures in the manifold isn't exactly easy either.
However, the principles of Physics always hold. Things like density, ideal gas law, proportions, and timing allow us to approximate the duration at which we want to hold the injector open. Putting all these things together, I was able to come up with a model that can approximate the pulse widths based on airflow fairly accurately. The concepts however weren't trivial, so I decided to make a full standalone application to demonstrate these concepts.

The real motivation behind this project were people, miserably failing at understanding the relationships between airflow, fuel, pressures, temperatures and all the other important. I am not the teacher type, and I do not take pleasure at explaining the same basics over and over, and have them doubt me. I remove doubt by introducing physics and quantification of entities involved.

So here it is, my first GUI application. I've always sucked as a coder, but the new VB express 2005 I must say made my life easier on this project.

During the development I tried to remember everything that annoys me about most applications, and keeping that in mind, I tried to avoid it. There is no annoying 'calculate' button, the whole application is 'live'--every time you change a value, all the results and prerequisite intermediate steps get updated. Another annoyance of Windows programs is the inability of looking at more than one instance of what I'm playing with at the same time, thus: the Clone button, which gives you another instance of the program, for your 'compare and contrast' pleasure. Also, there's no limits (beyond available memory) to how many you can look at simultaneously. Defaults make sense, I made it with SVO 30s and stock cube LS1's in mind, but of course all of this can be changed to any value you want. I checked it by trying values describing BPU'ed Supras and stockish S2000's and they all make sense too.

So the most basic mode of operation is to check if what my setup flows can be supplied with enough fuel at my operational AFR, temps, altitudes and RPM range. This is simple, merely adjust the numbers for your hardware, and you will get the pulse width needed to complete a full injection cycle. If it's bigger than the duration of the cycle, you're in trouble (one of fields will go red/yellow to alter that you're past the limits). If it's in the safe zone, you can start playing with it. Here's some questions it can answer:

How much higher can I rev with these injectors?
Is my fuel system big enough to handle heads and cam?
Why do Forced Induction setups eat so much more gas?
What if one of my injectors flows 10% off others, what kind of conditions are gonna be in that cylinder?
If I go racing to some good Density Altitude track, what kind of fuel consumption can I expect?
Why do I run lean when I went to more cubes?

and so on... This is a useful litttle utility, especially for educating yourself on what makes injectors work harder, what kind of hardware is really needed to race safely, and what conditions are desirable.

I'm planning on expanding this utilty to have a more precise Air Density calculations, helpers for injector sizing and cylinder displacement, etc.
Please comment, report bugs, give me ideas, etc.

The only problem with this software is that it requires Dot Net 2.0 on your computer. Most HPT users already have it on their computers, and if not, please download/update what you need.

DOWNLOAD HERE

enjoy, Marcin

Powerband Modeling

2006-07-01T21:05:00.000-04:00

I've been looking at various dyno graphs lately, and I realized they all got pretty much the same shape. In the meantime I've been reading about how LS6 and FAST intakes are the restrictions, and how they really shape the powerband. My curiosity was peaked how could one part have so much influence on what we get out of a system with so many other parts.
Another important reason behind this inquiery was trying to figure out if making huge peaky cams really makes any sense, can we take advantage of the extra power we get, since all the power seems to show up at the very upper end of the rpm spectrum.

Let's start with few assumptions:
LS6 intake--peak HP (from now on refered to as PH) occurs at 6200rpm, peak TQ (PT) at 4600rpm.
FAST intake--PH is at 6500rpm, PT is at 5200rpm

Let's run through the logic using the LS6 intake's properties.

From most dyno's I've seen, peak torque was about 430lb/ft @ 4600rpm, so let's start with that:
HP=TQ*RPM/5252 and TQ=5252*HP/RPM

HP(TQ=430, RPM=4600)=430*4600/5252=376.6 hp

So if 430@4600rpm is the peak torque value, let's say we design a cam that can hold it all the way to PH, we'd have a flat line, dictating the HP numbers through the RPM dependancy.
with that in mind, we know HP must peak at 6200rpm, so we have:
PH=HP(TQ=430, RPM=6200)=430*6200/5252=507.6 hp

That's the max hp we'll get with this setup. again, let's assume this setup (cam, heads, whatever else is necessary) can carry on that airflow all the way to 6800rpm (a realistic shiftpoint for most LS1's)

With HP curve now being flat to 6800rpm, your torque at redline (RT) will be:
RT=TQ(HP=507.6, RPM=6800)=5252*507.6/6800=392 lb/ft

So we have points for RPM={4600, 5252(freebie), 6200, 6800} which is quite perfect, as the spacing of the T56 usually keeps RPMs above 4600. If you go below that, you're really not utilizing your powerband, but that's a whole different story for another time, thus I will ignore such cases for the sake of this writeup.

Now let's take a look at the same thing, but with FAST intake. Of course, the logic would be the same, just with different peak points, so I did a quick spreadsheet and this is what it looks like side by side for comparison. I know that FAST usually puts out bit more power than LS6, but this is just for comparison's sake.

Notice that both cases make the same power until 6200rpm. It's past 6200, where FAST starts to shine. Just because it extended the full torque a bit longer (only 300rpm), it quickly translates into significant.

But these are just few points. what does it look like once put into a dyno-like graph?
I used my old powerband optimization spreadsheet to demonstrate the two cases.
I used the points from the tables above, and whatever values in between got filled out by Excel's very nice Edit->Fill->Series->Trend->Linear trick (just highlight the range with end values and empties in between first).

Here's what I got (I mangled the pictures a bit to make them smaller for ease of comparison):

On the left, we got the LS6 numbers highlighted, on the right, the FAST.
I also decided to go to 7000rpm instead of 6800rpm in previous part, just to see a bigger change from the power 'up top' power. And the results are...disappointing. FAST, even though by looking at the absolute numbers did pick up quite a bit of power, it did so on such a small portion of the powerband, that the average comes out nowhere near as impressive: 461 vs 467 hp average. that's 6 hp difference on a 460+ hp car. You'll probably get better gains by ignoring free donuts in the office for a week before the race ;)

So how do we make FAST worth the money? Shorter gears would help quite a bit, as we'd have less intervals total if we started at 5000 not 4600rpm, so we'd spend relatively speaking more time on the improved portion of the powerband.

Now, the real gains will be different of course, because FAST doesn't just extend the peak power, but also adds a decent amount throughout the whole powerband, and that's when the big gains would show up in black in white. However, this is a study of shape-shifting powerbands, not adding airflow/compression.

The real value of this little exercise is in quantifying gains that apply only to a portion of a powerband. The real problem lays with the numbers from 4600 to 6200rpm, the range between peak torque and peak horsepower. They're the ones that lower our average HP in the race powerband, and they're the ones to have much greater improvements than optimizing the seldom-visited 6200+rpm territory.

The short version: don't spend your money on mods that shift your power until later, until you already fixed everything else that adds power before peak HP.

Boost Perspective

2006-06-25T02:02:00.000-04:00

After looking at some tunes and logs of turbo systems, I realized that people don't adjust their NA tune to the new reality of forced induction. I mean, they know to adjust their target AFR and go easy on timing, but what I'm talking about is not knowing _when_ to switch over to the boosted settings.

In a normal NA setup you usually trigger PE with >60%TPS@ and 15kPa MAP, which is very tame, but sensible.

Boost doesn't happen purely as a function of throttle input and rpm, it is really a side effect of increased load and airflow, which are results of throttle and rpm. With these few indirections involved, you should not rely on just TPS/RPM triggers.

First you must figure out WHEN does the boost hit.
In a first attempt, I just looked at the common LTFT scan with all data loaded, and it looks like MAP, which is the closest thing we got to a boost measurement in this log, maxes out very early.

I wanted to see in context what happens before, during and after MAP maxing out, thus I just played the log in the charts window, concentrating on TPS, RPM, MAP, DynAir, and DynCylAir.

In the chart above we see that even at 84% TPS and 2700RPM we've already maxed out the MAP! this is great news as it means a quick and easy spoolup of the turbo. It also means that whatever data we'll get from this log qualifies as ballparkish at best, as we will not know the true MAP reading, which is taken into consideration for each Airflow estimate. (this log is done in Speed Density)

Another boost situation, and a similar result:

Very similar numbers (74%TPS and 2650RPM), yet we're already getting 0.80g/cyl of compression, which is a great PEAK result for most cammed NA cars, while we're getting it partial throttle and <2700rpm!!!

Airflow readings hit a flatline at about 58lb/min and stay there until redline. What the real readings are, we won't know until everything is calibrated correctly with a 2barSD setup.
The amazing part about this graph is the torque/compression: 1.24g/cyl!!! I have not seen a NA stock cube motor do that ever. Another great part about it, is that it peaks late (5300rpm) and doesn't drop off much at the redline, suggesting a fantastic powerband.
Again, due to the fact we're looking at maxed out readings, this is all pure ballpark, no specific numbers.

So now that we know that we the car is healthy, the boost hits early, hits hard (for a basic non-intercooled 5psi kit) and carries way more power that we can currently harness all the way to 6200rpm.

Remember at the beginning of this article we were talking about triggers? They were optimized for little torque (0.80g/cyl is a nice number for a small cam, 0.90 for bigger cam, and 1.0+ for a nice head/cam setup), and hitting that torque late on the powerband (LS6 intake usually forces it to be between 4400-4800RPM).
Now, we have a whole different paradigm on our hands. This setup maxes out at 1.26g/cyl at 5300rpm, with going into boost at a very early 2650RPM already pushing 0.80g/cyl.
Let's try to pinpoint where the triggers should be:

This histogram shows how much compression/torque/air in cylinder we get at different RPM intervals. Looks like somewhere around 2100rpm we can already hit 0.80g/cyl (note this histogram shows max values) which normally is amount of torque we'd be prepared (as in triggered PE mode) at 4400-4800RPM.

Based on this information, we set Delay RPM to 2100RPM.

Now let's look at how much throttle input does it take to cause a full 1 bar absolute pressure (101.3kPa) which is 1bar MAP's max value:

Somewhere at mid 30s %TPS we can already achieve boost, thus:
Set PE Enable MAP at 35%

Now the only table left is the PE Enable TPS table. We already know that we need only 35% to make things dangerous, now we need to tell the PCM how soon on the powerband that can occur, thus we graph MAP vs RPM:

We see at 2000RPM we already generate 90kPa MAP pressure, thus:
Set the PE Enable TPS table to 35% starting at 2000rpm, and for safety's sake, let's pick 20% all the way at the redline, and blend between them for a sensible curve.

Hopefully this demonstrates how you have to watch out for the new conditions created by your new modifications. Also, I posted a lot of configurations of custom histograms, which while not precise with the data gathered, it provides plenty of trending information to make it a worthwhile exploration.
Another thing I know I haven't explained yet, is my liberal use of horsepower/airflow/DynAir and compression/torque/DynCylAir. It's another writeup in the making, but for now you just have to take it for granted, so go ahead, push the 'I Believe' button and enjoy your new safer ride.

If you have any boost logs taken with a well tuned, well set up (2/3bar MAP sensor, 2/3bar SD mode/CustomOS) please send it to me, as I'd love to have a followup article to this one.
If you use the information in this article and you notice that things work better/worse, please let me know, I'd like to know how it works out in a day-to-day operation, as I don't have access to the Camaro with the STS setup anymore.

Roadracing logs analysis

2006-06-22T05:24:00.000-04:00

So Dennis went racing to Summit Point and brought me some logs. For the underinformed crowd, this is a full fledged, although home made Camaro race car. Less than 2900lbs with fuel and driver, probably upwards of 420rwhp, huge wheels with roadracing slicks, aero, the works, you get the idea. He said that last time he was out, only one car was able to pass him, out of 50 or so at the track. NICE!

We've been tuning this thing for a while using EFILive and the blackbox logging capability and it's been coming along nicely. Dennis is happy with the power because he has no traction in 2nd gear if he floors it, even with the big slicks on. But on the roadcourse, 2nd is rarely used, so all this power should come in very useful.

So this is my newbie attempt at hacking the data into somewhat readable and hopefully educational graphs.

First I wanted to see if the car is healthy, and if it does what it supposed to do, so I checked injectors: pulse width never went past 12 and duty cycle never went past 60%, so I'm going to skip these boring graphs.
Next is Air Fuel Ratio when going partial throttle and full blast.

It looks reasonable, car goes into PE mode as MAP/RPM values increase, as these are the PE triggers.

What made me a bit curious though is why was the spread of AFR at WOT so large:

I thought to myself, maybe I'm looking at the wrong thing, throttle is just the input, intake manifold pressure (MAP) is the effective dictator of what amount of air is going to get pushed in, as well as it's used in Speed Density airflow calculations. So I graphed it another way to see if there is a difference:

I dont see any frankly. we still get 0.7 to 1.0 point spread in AFR final values. I started to wonder what could be the culprit behind it. From experience, I know that a lot of information is to be extracted from plotting raw MAF signals and look at the noise levels, as an indicator of trouble. Here's what I came up with:

Damn it Dennis, clean your air filter! :)
The areas circled are noise, the signal has a very strong signature and range, but this is more than usual amount of noise. So if you ever see anything like this, go shake off dust, chunks of rubber from tires of cars in front of you, dead birds, whatever you got in there. Here we're gonna let him get away, as this log was the last one of all the sessions so stuff probably accumulated over the course of 2 days.

I did notice one more thing: maximum pressure in the intake dropped as the RPMs increased. Does this mean that we cannot feed air into the engine fast enough? Is this a sign of a bottleneck? Is it the intake manifold? Or is a just the overlap of the cam letting some air in and out fast enough that it shows up as never quite reaching the peak pressure values? Take a look:

Ok, so with all the checkups of the stuff that might make the car blow up (there's another boring graph or timing but that's really dead on the money), we started talking about more unscientific, but definitely tangible aspects of tuning. This track has a long straight, on which you could really scream through 4th (3.42 gear M6) up to 6500rpm, or try to shift a bit early to a not so dramatic 4400 rpm in 5th. But apparently, at 4400rpm in 5th, combination of greatly increased air resistance and falling off the powerband(cammed LS1 are the VTEC of pushrod V8's, they're very rev-dependent) leaves so little horsepower left that the acceleration is dismal. So of course, another debate of longer gears and 3-4 or shorter gears and using 3-4-5 at the track. This dispute is to be solved numerically, as quickly as I get done with chores and errands and finish rewriting my shiftpoint/gearing optimizing spreadsheet in C++ with increased precision, added air resistance and more gears.
For now we just get to look at what it looks like in terms of air consumed at various speeds:

You can clearly see that after shifting to 5th, you only get 30lb/min of airflow, out of ~45 possible at higher revs. while normally this would be only a slight annoyance, at greater speeds it becomes absolutely detrimental.
Let's do a simple example: if at greater speed it takes you 150hp to just fight off the air resistance, and you have 450hp max, then you have 300hp left for actual acceleration. If you shift early and you're left making 300hp and still using 150hp to just cut through air, then you have 150hp left for acceleration. Combine that with taller gearing of 5th gear versus 4th, and you are effectively stuck with 1/3 of accelration you'd get in 4th!

And here's the biggest discovery of this datalog: I was watching Formula 1 the British Grand Prix from Silverstone, where with smaller engines these guys spend over 70% of the track going WOT!!! I never thought of measuring that, but now that I have the data, why not, right?
But of course, I tried to run this idea through some people, and they brought up a good point: how do you define the proportions? is it measured as:

"wot acceleration"/"total number of samples"

"wot acceleration"/"acceleration but not wot"

"wot acceleration"/"number of samples in which car was not-braking"

I went with simple version and went with the first choice, as it provided me with what I think describes the issue best: how often around the track do we get to actually utilze the car's power to full potential?

I had few logs, and the results varied from about 19% to 22%.

Now this is LOW! And this is a very well suspensioned, well driven, light car on a lot of rubber! I expected a lot more, afterall this is a track with a pretty hefty straight (150mph+ max).

Some time ago on www.frrax.com (<--- awesome site, btw, if you haven't been there yet, go visit!) I did a quick calculations of how much does having extra 10hp on a 280average hp car help in actually decreasing times, and It came back with something suprisingly, yet laughably small, like 0.1 sec if we get to use that 10hp for 10 secs! So not only we dont get to use the extra power very often, but even when we do, it doesn't have that much influence.

So does adding power to amateur roadrace cars mostly increase chances of blowing up, and does next to nothing when it comes to actually reducing lap times?

IFR tweaking Jihad

2006-04-09T02:47:00.000-04:00

A lot of people lately been asking me about IFR tweaking. I couldn't believe that after all these years of using VE with great results people still used the old hacks.

So these are two things I've written up to people about it. The first one is short and purposefully silly visual, the other one is more technical. I hope this will once for all put the end to all stupid IFR tweaking.

Take one:
So let's say you're mixing cement... ;)

Your shovel can move 1 pound of cement per second to the mixer (or whatever that's called) in which you supposed to mix cement and water in 1/13 ratio. You have a hose going to the mixer that you believe delivers 13lb/sec of water. however, the hose is clogged, and you don't know about it. All you know is that your mixture despite your best effort is a bit off. So instinctively, instead of checking what's wrong with the hose, you decide to grab a bigger or smaller shovel depending if your mixture is too watery or too solid to compensate for the change in amount of water.
In the end, did you get the right mixture? yes.
Did you get the right amount of it? No!

This is exactly what IFR tweaking does to your engine. Instead of looking at the source of the problem, you just try to make up for it somewhere else.

Take Two:
All the mods you do, all they do is increase the Volumetric Efficiency
(aka. be able to cram more air in, increase airflow). However,
the idiot tuners, they keep the Volumetric Efficiency table (which
exists exactly for this purpose) unaltered! So with more airflow and
same amount of fuel, you're basically making your car run leaner, first to the point where it makes more power, but eventually it goes well into the dangerous territory.

Here's a scenario to demonstrate this in numbers:
To keep the AFR sane, you gotta tell the computer to dump more fuel.
You can't do it directly, as most of this stuff is calculated dynamically or proportionally, so you just lie about the size of the injectors. This way every fueling operation is proportioned to the new 'size.'

So let's say you had 39lb/min of air coming in, and you're trying to
keep a 13.0 AFR (easy numbers example)
All the injectors have to deliever 39/13=3lb/min of fuel. there's
8 of them, so they flow 3/8 lb/min (0.375). Injectors are usually
rated in lb/hr so this is 0.375lb/min*60 min/hr=22.5lb/hr of fuel.
You don't want to operate your injectors at 100% as they will simply
overheat at one moment and stop sending fuel at all, exploding your motor.
80-85% duty cycle is the safe range in which most injectors can operate
without deminished reliability. So you want 22.5/0.80=28lb/hr
injectors. Oh, what do you know, that's a typical airflow and a
typical injector size in a stockish but tuned LS1! See, all these
numbers come from somewhere, and if you have enough equations for it,
you can see it how got there.

But to get back to IFR bullshiting...
Now let's say you put some swanky exhaust/lid/intake on your car, and
it flows 44lb/min of air, not 39. But if you don't touch VE table,
now you're gonna get 44/39 *13=14.666AFR!!! That's very dangerously
lean! So far we've been dumping up to 39lb/min relatively worth
of fuel. If we say we have injectors smaller by the ratio of 44/39,
it will automatically try to make the injector work harder, by
commanding more pulse width. The trick the 'IFR tweakers' rely on
is that the injecotrs didn't really get smaller, so now we're
commanding bigger pulse width on the same injector as before, effectly
spraying more fuel!
So it does what we wanted, right? Wrong! Pulse widths don't
scale linearly, so you're not really aiming for the right amount of
more fuel, you just know you're spraying more than before. This of it
as a sharp shooting competition but you're blindfolded and have a
helper that can only tell you 'up/down' or 'left/right' while what you
need is '30mm to the right and 3mm down.' You can see why the results
of such tunes are so crappy.

Then you toss in a cam with a naturally steepy VE (inefficient at lower
pressures, and very efficient under high pressure), and the whole IFR
tweaking scheme falls apart.
IFR has only one dependent variable(MAP), VE has two (MAP,
RPM). This means IFR can describe what VE could, except that it has
to consider RPM to be constant. Thus when tuning with IFR, you will
command the same amount of fuel whether you're at 1000rpm or 7000rpm.
big cams have VERY different flow characteristics at such broad rpm range,
and therefore IFR will never be able to reflect the precision
necessary to reflect such changes.

Another numeric exercise to demonstrate this:
A stock cam has about 50% VE at idle, and about 90% at WOT.
A nice big cam has 30% VE at idle, and up to 120% at WOT.
So to make a big cam idle nicely with an unmolested VE you're gonna have to
seriously bullshit about the size of your injector sizes, as you're needing only 30/50(60%) of fuel you used to need.
On the other end of the spectrum, you will need 120/90(133%) more fuel than before. So you lie some more about the injectors, making your IFR table look very sharp and jagged, what in reality is a nice smooth progression.
The real problem is that the IFR table has only one axis (pressure at the fuel rail) and only 17 values. VE table has 380 cells on two axis. If the natural VE dictated by the characteristics of the cam shaft is very sensitive to RPM (and most aftermarket ones are very sensitive) you will not be able to have the computer dump appopriate amount of fuel in all possible situations. So you have to simply your tune (that's why people do it), and tune it either for decent drivability (and have it horribly lean up top) or optimize it for power, and have it stall 5 times every time you try to get in/out of the pitlane.

IFR tuning to VE tuning is what carbs have become to electronic fuel
injection. They both get the job done, just one is way more flexible
than the other.

Injector Sizing Spreadsheet

2006-02-18T01:57:00.000-05:00

Here's a little spreadsheet that will let you estimate what size injectors you will need for your application. Works for NA, Super- and Turbo-charged cars, any number of cylinders.
All you need to know is Displacement, Max RPM, Max Boost (0 for NA), Maximum Volumetric Efficiency, and target Air Fuel Ratio.
Also includes a little calculator for quick Cubic Inch to Liters.

DOWNLOAD

As 'ballparkish' as this is, it's suprisingly precise, put in 6000rpm, 80% VE, 5.7L 8 cyl and you'll end up with a 26.4lb/hr injector needed for the application. Just like the stock injectors for LS1. Go figure!

Hope this will put end to all the 'What injectors do I need for my setup?' questions.

Enjoy,
Marcin

Why flow matched injectors are mandatory and not optional

2006-02-04T20:12:00.000-05:00

So the other night a friend of mine asked me why do I try to talk all the people I tune to talk into buying flow matched injectors. I tried to explain that imprecision, combined with different conditions per cylinder (the famous #7 cyl explosion for LS1, I think the modular Fords have both 7 and 8 'pre-screwed by nature' as well) can be deadly, especially in environments extra sensitive to variances in AFR (nitrous, forced induction).
He got the point, but I don't think he was convinced that it's truly worth the extra $100-$120 that it usually costs to have them flowmatched.

So I decided to quantify some of these generalizations, for the sake of making my argument stronger.
First I wanted to see how much 'off' is my Air-Fuel Ratio going to be, with normal injectors, vs. flow-matched injectors. So I made a simple table of what ratio of air to fuel would be theoretically, vs practically, as a result of injectors just being cheap and 'good enough' for normal applications.
11units of air to 0.95units of fuel(i was aiming to the dangerous side of AFR to demonstrate my point in a more dramatic manner) and 11.0 target AFR yielded 11.58AFR. that's almost 0.6AFR of precision and unpredictability that we just gave up on cheaper injectors, and that's with perfect air measurment!
That got me thinking: If this is the acceptable, normal scenario, how much worse can it be? Injectors say +/-5%. what if we get two injectors in the set that are on the very ends of their imprecision margin? That'd be 10% difference in flow, how bad would this be, especially if they ended up on cylinders that are naturally richer/leaner? Airflow is also a bitch to measure, what if we don't get that precisely on the money? What if the 'lean' cylinder will get a 'weak' injector, and we're not measuring air precisely enough on top of that?
So I started explanding my tiny spreadsheet, and I came up with a bunch of scenarios demonstrating various situations that can occur as a result of imprecise air and/or fuel delivery:

So the scary scenario is the last table, when you combine 10% imprecisions of air and fuel. instead of a target 11.0AFR, you end up with 13.44AFR.
Scary enough for you?
That not only proves that these extra $100 on flow matched injectors are truly an insurance, but also makes a very strong case for having your VE/MAF calibrations done perfect, as apparently being within 5% is not good enough, if you intend to have a truly reliable, predictable setup.

Hope this puts the whole 'why tune and retune' argument in a much better perspective.

new VE tuning spreadsheet

2006-02-03T20:20:00.000-05:00

New VE adjustment helper.

Features:
2bar ready
FULL and HALF resolution output from the same data
HALF resolution calculated as a result of neighboring FULL res table
automatic filtering out output of values in the target range (if not broken, don't fix it)

Instructions:
input LTFTs
input STFTs
take the results and multiply them on top of your existing VE table

DOWNLOAD

Top 17 Tuning Tips for every car

2005-12-23T02:38:00.000-05:00

It's almost Xmas, so I decided to have a put a small gift under every tuner's tree, with a short list of tricks that people found useful at various times.
First, you want to make sure you do things in the correct order, as you want to make sure that you don't spend time doing something that will need to be redone at a later time due to related tables being modified.

Read your stock computer file and save it, preferably in multiple places, and on various types of media so you aren’t stranded without a known, functional tune. Email, USB thumb drives, multiple computers are all excellent ideas.
BEFORE you start changing anything, put it in accessory power mode and hit scan. You will get initial settings without the whole system under pressure. This is your base. Take notes, it might (and usually will) come in handy later.
Start up your engine, and start to log your idle. If you have an automatic transmission you might want to do it again the next day but in D not in P/N.
Check your Diagnostic Trouble Codes (DTC’s). You might find some problems with your car you didn’t know about before. Remember that tuning a car with mechanical problem merely band-aids the real problem. Don’t waste your time doing this, and don’t waste other’s time by asking questions about it on the forums.
Time to take a ride. You can take a normal drive through a neighborhood, but a mix of city and highway driving would be perfect. Log the car's behavior in these various situations. This time what you're looking for is older/lazy/faulty oxygen sensors, signs of knock, shifting patterns of an automatic transmission, rpm dipping/holding at coming to stoplights, and any other irregularities that you've been ignoring and living with for too long. Make sure you drive it long enough (a 15 minute drive usually does it) to bring the whole car up to temperature, not just the Engine Coolant Temperature.
Once you review your logs and decide there's nothing too scary or blatantly wrong, find a stretch of empty road and do a nice long Wide Open Throttle run. It's an excellent source of information as it provides you with some vital data (more on this later) as the whole system is under full stress, pressure, temperature, and load.
Organize your data! I cannot stress this enough. After just few weeks of tuning, you will be drowning in logs, settings, notes, and spreadsheets. Save yourself the pain and just make yourself a following structure:
\HPTLOGS\NAME\DATEinYYMMDDformat\DescriptiveNameWithASerialNumber
Why the funny date format? Because it goes from most significant to least, just like normal numbers, so it's easy to look at in series.
The name of the file can be tricky, as you want to put info in it, but not too much, as it's going to make the name of the file awefully long and unmanagable. Usually what I look for in a name was the goal (VEtuning) and the mode (SD) and you want to know the order of things it all happened, so you want a serial number in here.
So the example of the full thing would be:
\HPTLOGS\Marcin\20050630\08_VEtuning_SD_smoothed.hpl
This provides me with all the info I need. If I have few other attempts of tuning VE I know exactly in which order they happened, I know I'm also tuning in Speed Density, and I know I smoothed it. For more detailed information I'll have to dive into the file itself, but usually it's enough to just glance at the list of the files and you know which one it is that you want to investigate.
Check your hardware and see if your car computer is aware of it. If you changed displacement, you must change the "Cylinder Vol" field. If the EGR stealing gnomes did their deed, you have to disable it (EGR-Disabled) and then turn off codes in the DTC section.
One hardware setting is so important that I am making a separarate point of it: the Injector Flow Rate, popularly referred to as the IFR. Use a fuel pressure gauge to measure the idle fuel pressure and look up the flow ratings of your injection. With this data, use the spreadsheet I have in the "Idle tuning writeup" to create your new IFR table. Most fuel pumps will increase the pressure, Fuel Pressure Regulators might deregulate it in many creative ways, so you have to make sure you get it right. Boost-a-pump and vacuum-referenced setup are a bit tricky and beyond a scope of this post.
Undo the GM marketing department's lame attempts to keep the LS1 from a F-body lower output than the Corvette. Setting the Power Enrichment table universally to 1.15 results in a much more sane (than the overprotective stock) 12.7:1 air-fuel ratio.
Another day another dollar, only this time its relating to the timing tables. 01-02 cars are _notorious_ for this. They run about 19 degrees of timing at WOT, while 98-00 cars do 29. If you have no problems (read: knock) with the tables from the earlier cars, please flash your tables with them. If you do have problems with knock, or your car just doesn't benefit from the increased timing, go with a stock Z06 timing table. It should gain some power, but at the same time its not wild enough to induce knock.
If you have a cam but don't know how to tune the idle, the easiest way to make it easier is to raise the idle. Don't be shy, big cams need a big idle, and 1100rpm will make anything idle very smoothly.
Under Fuel_Control->Open_&_Closed_Loop there's a little section called LTFT Boundries. The RPM button has 3 settings, which cut up the RPM/MAP histogram used for VE tuning into logical clusters called the Fuel Trim Cells. On some cars, the GM settings are so asinine that they put the second and third value completely beyond the rev limit, making them useless. I like to use them to put the FTC's into logical pieces/clusters: idle, light cruise, passing, WOT. So if your idle is let's say 900rpm, you tool around town under 2500rpm , then i set them to 1200/2500/4000. This way the computer is using a very logically laid out FTC, facilitating quicker and more precise learning. This will make the car behave better in general.
Take a tape measure and measure the height from the floor to the center of your wheel. Double that, and use it as the height of your wheel for speedo calibration, NOT the advertised height. This is where Reality meets its arch-rival Marketing in a final battle ;) My tires are officially 17x315/35, which is 25.7" height, but practically it's more like 24.9" That's almost an inch off, a significant factor in calibration, and might be a difference between a ticket and a warning.
Get a lower temp thermostat and adjust your fan enable/disable temperatures for it. A car that runs cooler knocks less, making it easier to find the real levels of engine's comfort without random knock occurring too often. If you have aftermarket fans, make sure they are wired to work as advertised (pull or push) and that both of them do the same thing. It's very hard to diagnose cooling problems and they're potentially very destructive.
Monitor Dynamic Airflow and MAF(SAE) signals. It's best to just graph them on the same graph, same scale, but with two different colors so you can see how close they are. If you see discrepancies, you most likely need a VE or at least a MAF readjustment.
Now we're going to start looking at the data we've gathered earlier to help identify some potential problems.
Shade tree mechanics often suffer from lack of patience, precision, and power tool happiness, resulting in leaks. The most popular leaks are by the throttle body (smooth bellows not completely going on the TB on the bottom), intake manifolds (FAST is supposedly very hard to seal properly), and of course the entire exhaust system (primarily headers, collector, and the Y-Pipe).

The bellows leak is characterized by having a lower than average airflow. If you know your car used to flow 40lb/min and suddenly you can barely see it crack 32lb/min, you can bet the air is getting out by the bottom of the TB.
Intake leaks can be spotted by low MAP pressures during WOT runs. This is where it pays off to know what the pressure would be with the engine off. If you know it was a 100kPa day and you can't go past 85kPa then there are some bad gaskets underneath that need to be replaced.
Headers are notorious for leaking because they are metal expands and contracts in relation to heat, thus expanding and collapsing in size. The general consensus is to go over the header bolts after a week of driving after you installed them to them on as tight as possible. Its easy to pick out a header leak by using a scanning program, as you're going to see a repeatable pattern of one side's O2 reading consistantly leaner than the other.
For those who are not afraid of Excel, dump the data from a few WOT runs into a spreadsheet and run Tools->DataAnalysis->DescriptiveStatistics on the O2 readings. Even if it's been a while since your last statistics course and you don't remember what specific values mean, just look and see if both of the banks have a similar descriptive parameters, or if one of them is significantly different from the other. If it is, re-torque the header bolts and check again.
In the scanner, collector leak looks similar to a header leak, but both banks are off instead of one. Of course there's a possibility of a regular header leak, just with both sides leaking. Either way, start re-torquing.

Here's an example of an interesting header leak, you can see both O2's go crazy, but one much more than the other:

The real story here turned out to be a TWO overposed leaks. One was a traditional 'need to retorque one side' leak, but the other was a small collector leak.

That's all for now, I'll try to make some pictures demonstrating some of these things.
As always, feel free to add, comment, correct and point out anything you think can use an improvment.
Happy Holidays!

New Injectors spreadsheet, EFILive friendly

2005-11-01T19:20:00.000-05:00

TAquickness was kind enough to contribute to the injectors spreadsheet, he added a column friendly layout for EFILive users.

go DOWNLOAD

Critical RAF spreadsheet update

2005-10-15T19:00:00.000-04:00

It's a critical bug, please rerun your configs to get it right this time.

Sorry for the bug, I'm amazed that it took so long to spot it, you people need to be more critical! ;)

DOWNLOAD

Idle Tuning

2005-08-23T16:16:00.000-04:00

Idle tuning is a rather touchy topic, as you can never be really 'right' just by looking at tables and values. Daily drivabilty is what's at stake here, and that's a very subjective manner. Lots of people want that big cammin' sound, I don't know why... Anyway, you gotta start with hardware configuration.

THROTTLE BODY
If you have a bigger throttle body (FAST 90, or Nick Williams) you want to multiply your Effective Airflow Area by 48%. (put in 1.48, select the whole row, hit 'multiply')

CYLINDER DISPLACEMENT
If your engine displacement has changed (bored, stroked, etc) you need to do some math. HPT wants cylinder displacement in liters, so might as well do everything in metric to start with.

Example 1, stock LS1:
bore= 3.898", stroke= 3.622" so in metric, according to www.onlineconversion.com (great site btw)
bore= 99.0092mm, stroke= 91.9988mm
Cylinder is just that, a 'tube' so to speak, so the volume of it is:
V=Pi*r^2*h or in our case,
V= Pi*(99.0092mm/2)^2*91.9988mm=708309.6306mm^3
=0.708309Liters. And what do you know, that's the value that's stock in HPT for the 5.7L/346ci motor.

Example 2, 402ci motor:
bore=4.000", stroke= 4.000" thus
bore=101.6mm, stroke= 101.6mm
V= Pi*(101.6mm/2)^2*101.6mm=823703.678mm^3
=0.823703678L
Go put that value (in liters) into HPT under Engine->General->Cylinder Volume.

INJECTORS
Another super important thing to get right when you're setting it up: injectors. Big myth here is scaling from what you used to have. Forget it, just put in new values for the new injectors and you're done. These are the popular sizes of injectors in default HPT units (lb/hr) stock 99-00 injectors (26.4lb/hr)

26.41431 26.60033 26.78634 26.91036 27.09637 27.28239 27.40640 27.59241 27.71643 27.90244 28.02645 28.21247 28.33648 28.52250 28.64651 28.83252 28.95653

stock 01-02/z06 vette injctors (28.8lb/hr)

28.70852 28.89454 29.08055 29.26657 29.45258 29.57660 29.76261 29.94863 30.13464 30.25866 30.44467 30.63069 30.81670 30.94072 31.12673 31.31275 31.43676

svo 30's at stock GM fuel pressure (34.6lb/hr)

34.64162706 34.85752419 35.07209232 35.2853557 35.49733784 35.70806157 35.91754903 36.12582173 36.33290055 36.5388058 36.74355721 36.94717396 37.14967471 37.3510776 37.55140031 37.75066003 37.9488735

svo 42's at stock GM fuel pressure (48.5lb/hr)

48.49827788 48.80053386 49.10092925 49.39949798 49.69627298 49.9912862 50.28456864 50.57615042 50.86606077 51.15432813 51.4409801 51.72604355 52.00954459 52.29150865 52.57196044 52.85092404 53.12842289

This is all at stock fuel pressure, if you changed that, you gotta adjust accordingly, please use this spreadsheet: DOWNLOAD
Take a Stock VE table (remember to do it on the Primary VE for 01-02 cars and Secondary VE for 98-01), and have the first column (400rpm) go 25-60, second column (800rpm) from 25 to 70, and third column (1200rpm) to 35-70. These are ballpark values, they will differ with your setup, but i find them generally a good starting point, an usually within 15% of what they will end up in once tuned.

These are two tables of idle regions, one is a Futral 228/.575 112+4 Mac Mids M6 car, the other is MTI 236/.588 112+4 SLP LTs A4 car.

Spark in Idle regions:
First you gotta let it idle and see where it idles rpm- and airflow-wise.
Then go to Engine->Spark Control->Spark Advance->Idle Spark Advance->{In Drive, In Park} and you want to set it to about 20-22degs in the idle regions for Park, and 26-28degs for Drive table.
This is an example of such a thing:

Another great helper in getting your setup to idle is to set your TargetIdleRPM.
go to Engine->Idle->IdleRPM->Target Idle RPM table, and this is a good start for any bigger cam):

Of course, bigger cams need more rpms, smaller cams can get away with less, so for example stock/Z06 cam can go as low as 550rpm, while G5X2 wants to be at least at 1050rpm for a truly smooth operation.

Scan, Ready, Go!
Now that we're finally done with preparations, it's almost time to fire it up!
You want to scan for the usual things: rpms, spark advance, MAF, MAP, but also you want LTIT(gear), LTIT(park)(automatics only), Idle Adapt (STIT), IAC count, IAC desired, TPS%, TPS voltage.
Put the car in Accessory Power mode (lights on dashboard on, but not cranking yet), and star scanning with the table I listed above. First, check if your TPS% is at 0% if you're not touching the gas pedal, and 100% when you floor it. You might want to reset your IAC motor, but you'll probably want to do it later once you bring the car up to temperature and start messing with IAC counts, but more on this later.

Assuming that the car is cold, start it up, and start scanning immediately. You also want AC off, and use the live controls to turn off both fans (the increased airflow from the fans will throw off STIT) It might take it a first 20 seconds to figure out what's going on with all the changes we've made, so it might be a bit rough and stumbling around, but it should quickly stabilize and stop hunting. If it doesn't, go back to the settings, and try to up the Target RPMs, that's the easiest fix. In the meantime, watch your STITs gone crazy. Most cammed cars will have the Running Airflow (RAF from now on) tables way off, and STIT will try to adjust for what it should be. You can pretty much eyeball the new values, as long as you know the ECT intervals (notice they're different for 98-00 and 01-02 again!), and just keep track of what values STIT holds at, as the engine warms up and ECTs go up. Or you can be dead on if you just use these spreadsheets:
DOWNLOAD NEW VERSION!!
This contains a config file and two spreadsheets for the different years. The instructions are within the files, so please read them BEFORE you aim/email me. Read them completely, so you know what units to log all the airflow in.

So let's say your car warmed up and it's idling decently. Save your log, turn off your car, put the data in the spreadsheet, alter your RAF tables with the new results, and flash your PCM with your new configuration.

Note: Automatics will want to do the whole 'cold startup' procedure twice, once in park, once in drive (either go drive with a lot of stop'n'go traffic, or just sit in your driveway in Drive and your foot on the brake). Then use the data from the right result table and paste it into your config.

Another note: if you do this config in the middle of the summer where your starting ECT is ~80F, don't expect it to work well on a cold startup in the middle of winter when ECT is closer to 4F. You might wanna do it again then and complement your new table with some values for few more intervals.

IAC
Once the car is warmed up, start it up again, and watch your IAC counts. You want them to be less than 70, and if you can, less than 50.
Idle settings are pretty much done. Now just tune your VE in the idle range (running around the block few times is perfect for it), and your idle should keep getting better and better.

If you see STITs still posting significant numbers (more than 1g/sec), you might want to redo your RAF configuration. Since you're dealing with rather peaceful data (no crazy swings or transitory conditions), you should be able to get it near perfect in 2-3 rides/cold startups (depending which RAF you're tuning) even on the most radical of setups. I was able to keep my STITs under 0.2g/sec.

If that doesn't help it, raise that Target Idle RPM another 100rpm, and redo your RAF again.

If the spark advance hunts around a lot, it means your Over/Under Speed timing tables (Engine->Spark Control->Spark Advance->Idle Adaptive Spark Control) need to be adjusted to slightly less radical numbers. The way I like to do it, I use the live controls in the scanner to find a RPM that allows the RPM to vary <>

Knowing is half the battle, and now you know, but keep in mind all this might as well be a big pile of horsepoop ;)

Road racing an automatic

2005-08-15T15:30:00.000-04:00

Road racing an automatic is historically speaking a big no-no. No engine braking, no blips, uncontrolled shifts, not being able to hold at certain rpm for arbitrary periods of time, they're all good reasons to declare an automatic an ill choice.

But this is 21st century, and even GM's crappy transmissions are a subject of being electronically controlled. There are tables controlling when to up- or down-shift, depending on Throttle Position Sensor (TPS) and speed. There are also separate tables for cruise and overheating conditions, which are are a nice touch, albait useless for the purspose of road racing. Now though, with the help from HPTuners or EFILive packages, we can adjust it any way we want. Let's take a look at what we can do with them.

Normally they look something like this:
1->2 10 10 11 12 13 15 17 19 21 24 27 29 32 33 35 37 37
2->3 20 21 23 25 27 29 31 34 37 41 45 51 59 66 74 75 75
3->4 37 37 37 37 44 52 69 83 99 108 112 117 117 117 117 117 117
2->1 9 9 9 11 12 14 16 18 20 22 24 27 29 31 32 34 34
3->2 17 18 19 21 23 25 27 30 32 35 39 44 51 59 67 72 72
4->3 32 32 34 36 37 45 61 75 89 99 106 110 111 111 112 112 112

This is what I figured out by simple trial and error at the track:
1->2 15 15 15 15....
2->3 67 67 67 67....
3->4 115 115 115 115....
2->1 15 15 15 15....
3->2 65 65 65 65....
4->3 115 115 115 115....

What we basically did, we eliminated partial throttle! If you think about it for a second, at the track, we want to very rarely shift early, you want to shift when you 'run out of revs.' This simulates it, as we set WOT shifts to partial shifts. The important part of it is the first column, which is for 0% TPS. That means, that even if I take my foot of the gas completely, the transmission will not suprise me with an upshift.

Another interesting things you might notice, that while the stock table ends with a 75mph shift, the racing table ends with a 65mph. Why is that? Because at the track, the trans fluid gets so overheated (yes, even with B&M 24000GVM trans cooler!) that it turns into 'water.' It seems to lose so much viscosity, that the shifts that were normally intended to initialize at 6000rpm, now would start at 6200-6300 and would not complete sometimes until my revlimiter at 6600rpm. Thus, I lowered the speed/rpms at which I wanted it to start shifting, and everything was fine again. It was suprising however how much this can change at the track, and never on the street.

So what was the result of all these experiments and strange changes? It worked great! I went to the Autobahn Country Club in Joliet, IL for a track day on the 'North Loop', and the car was more fun than ever. Granted, the long automatic gears aren't the greatest for roadracing, but it would feel good. There is a sequence of T3-T4-T5 which by the end of the second session I figured out how to take without any braking whatsoever. All these corners are about 50-60mph, and with the transmission in 'track only' mode, I'd plow through all of them holding ~5000rpm, letting off throttle completely in some moments, and feathering it in others. Laying into it completely coming out of T5 and setting up for T6 was extra fun, as I'd rocket out of there at the top of second gear which feels very powerful in my car (right about peak hp and before torque starts to drop off).

The gear spaceing was actually not bad considering how the track was laid out. Most turns were 50-60mph turns, with T1 being about 75mph (I tried it out at 80mph few times, but brakes just weren't up for it going into T2 and I'd overshoot the turn in point) and T2 being ~40mph. If fit the car well coming out of these corners hard, charging up the top of second gear. The 3 straights were fun two, two of them topping out about 85-90mph, and the main one was about 105-110mph (depending how chickenshit I'd go through 'the kink' T1. So I'd come out on power, and utilize the powerband fully. I wish I had another gear between 2 and 3, something like Supra gears were (60-90-125mph) as that would put me at the peak power at all times. But, I still claim it's the most fun thing you can do with your pants on.

Dyno day

2005-06-11T09:30:00.000-04:00

My car's been tuned, retuned, tweaked and retweaked that I thought it would be time to see if it's healthy. Not having a wideband, I decided to go to a dyno. My mechanic put in a nice Mustang Dyno earlier this year, so I decided to see how it's going to do.

The car's been in Speed Density more often than not, as it always allowed me to look at VE's without MAF screwing it up. Since I was going to the track the day after, I decided to reenable MAF, as the weather report for the weekend predicted everything from sunny 60F to thunderstorms and mid 80F.

So the night before going to the dyno I do a last run and check my LTFTs and everything is perfect. To save time (and money) at the dyno, I prepared a bunch of different setups, differing mostly on AFR, as timing was supposed to be changable using the live controls in HPTuners scanner.

I put in one of the MAF setups in, and drive over the next morning for some dyno time. It's hot, it's humid, and my LTFTs are going absolutely nuts, about 10-20 points on the lean side. At this point I say screw it, put Speed Density tune on, as it seemed to be less nuts, and go on the dyno. Of course, all the prepared setups I had were useless, as they were in MAF mode.

First run:
We run it to 5252rpm, just to see how badly off I am. Turns out that my SD tune I quickly put together didn't have High and Low Octane tables equated, so I got only about 18 degrees of timing, still resulting in right under 350rwhp and still climbing! Suprised but happy, I make spark adjustments, and run it to 6500rpm to see the true powerband, at a fairly low, safe 22degrees of timing. Power peaks at 353rwhp@6000rpm and it starts to drop off after that.
My AFR at that point to set up to do 13.0-12.6-12.2 as the rpm's rise. While I can see the general trend of AFR having 3 separate areas, every run has a different value for each section.
Question 1: timing adjustments--can they alter the resulting AFR?

So I start to screw around with different AFR/timing combinations, slowly working my way up to more stressful settings of 13.0AFR and 29degrees of timing. That run was my last one, resulting in 364rwhp, strangly enough resulting in AFR bouncing back and forth between 12.2 and 12.7, which is exactly what I wanted. Knock did not occur anywhere, so I figured the car is healthy.

For the day after, the trackday, I decided to start with my last tune, just go back to one of my other tunes with AFR at 12.6 timing at 25degrees, which netted 359rwhp. I'm not sure what the AFR really ended up being, as my PE mode didn't seem to have a clear correspondence to the real world results.

All and all, a good experience, albeit an expensive one. I did 13 pulls, but because of the last minute changes to Speed Density modes and not having any setups ready, I spent a lot of time poking around in bins changing AFR and timing, wasting time.

Few observations:
1. go to a dyno on a day with normal temperature/dyno, otherwise you have no idea what you're really measuring.
2. have your setups ready for loading. don't waste time and money on making changes on the fly, unless there's a real reason for it.
3. setup a log, or better yet a spreadsheet in which you note all your settings, results, observations. note time and order, otherwise you'll have a problem matching them with the dyno results.
4. dynos are not the most precise devices. don't use it as some sort of ultimate result. I have not seen as much airflow as on the street, the temperatures were off, the MAP pressure was off too. you can't really simulate the real thing, unless you get out there and do it.

I'll post some graphs later, right now my dyno guy has a problem with his software, all his datalogs got cut off at 5777rpm for some reason :(

visualization of gearing/shiftpoints

2005-05-25T18:47:00.000-04:00

NEW DOWNLOAD, version 2.3, now with graphing! :)

So while my spreadsheet is cool, not enough people have precise numbers and dynos in different gears and such to really take full advantage of its capabilities.

Thus, I'm gonna combat the stupid myth of 'if you peak at 6k then just shift there' that you hear so often on LS1tech on a realistic example.

Pictures are worth a thousand words, so I grabbed some data from Trackbird's stockish 2002 camaro, as he's the only guy I know that has dynos in different gears. Oh, it's good to be a crewchief ;) I used 3rd gear data for 1st and 2nd, as 3rd and 4th were the only data I had.

I graphed 4 curves, picturing the relationship between horsepower at different speeds, in different gears. Some of them overlap of course, as gears do.
The blue dots represent the horsepower curves for the entire range in each gear. Pink dots are the HP which would be used to accelerate, with given parameters (shift points, gearing, tire size).

Now for the cool part:
T56 is a good trans, well spaced for LS1 powerband. 4L60E however is a different story. I used my old setup (3.23 final gear, 4L60E trans, 315-35/17 tires) with Trackbird's dyno graphs (since it's stockish enough) for the purpose of this demonstration.

Look at the 1-2 shift: 6000rpms drops to 3100rpm, which brings it down from 290hp to only about 180hp. That's sad, becuase it kills the whole myth of big american V8's with a lot of down low grunt. Sorry guys, but it's just not there anymore. 180hp while your car weighs 3500lbs will yield a lousy acceleration.

2-3 shift is not that much better. This time we're going from 6000rpm to 3700rpm which yields us a drop of about 70hp. So this time not only you end up with lousy 220hp, but you're already in 3rd gear, which is 1:1 (3.23 effective) ratio.

Now let's look at the modded scenario (3.73s, 6400/6300/6200rpm shifts):

1-2: 6400rpm drops to 3400rpm 'landing' on lousy 195hp again. It's better than before, but still lousy. The good part is that for that few miles an hour, it wasn't going from 180 to 195hp, it was dropping from 280hp to 270hp. That's the trick about shifting past the peak power. You might be losing power, but you're not losing it nowwhere near (almost 100hp difference!) as badly as if you were to shift to a higher gear earlier. So the gain is twofold, you don't lose lower gear, and you gain on the higher gear--nice!
2-3: 6300rpm drops to 3900rpm 'landing' on much more pleasant 225hp. The logic is the same as with 1-2 shift: you don't lose in 2nd anywhere near as much as you'd lose by shifting to 3rd earlier. Then as a added bonus, you start off in 3rd on more power.

So how can we quantify this?

I set up a scenario where we'd use 1-2-3-4 gears on both auto and manual transmissions. 30-140mph run, should demonstrate how higher shiftpoints combined with shorter final gear, yield a better acceleration.

I added up all the hp cells 'participating' in this simulation and added them up. Also, I counted how many of them there were, giving us all we need to see the average horsepower rating throughout the whole accelerating process.

case 1 (6000rpm shift, 3.23s): 263.89HP
case 2 (6400/6300/6200, 3.73s): 270.65HP
That's a 2.5% increase, but more importantly it's throughout the whole range! Not only that, but it's also rearwheel horsepower rating, this is exactly what causes acceleration (well, if we ignore the air resistance, but it's not like you can cheat out of this one). So practically speaking, it's power for free, but in that effective sort of way, not some theoretical instantenous peak rating that marketing guys love so much.

Also, this is on a stockish aplication. In cases where power does not drop off 'till much higher rpms, proper shifting will reward you even more.

If you're stuck with the A4 transmission, you can learn where it hurts the most, so you can spray there. Right after the shift in 2nd would be NICE, but remember that a to make about 400hp (let's say ~200shot) at 3100rpm means you're making 677lb/ft of torque, so while it will help tremendously, it might not be the best thing to do as far as reliability is concerned.

I hope that demonstrates a bunch of points:
1. Various applications: where to spray for drag racers/where to shift for road racers/what speed would be the best to start off with for a highway race
2. Common sense sucks as far as numerical integration is concerned. Some things you just gotta calculate for yourself, you can't just rely on myths and popular opinions to.
3. Peaky powerbands (yes, that's you, LS1 people!) do need properly matched transmissions to go alongside with them. There are reasons why little Hondas with peaky VTEC powerbands rev beyond 8000rpm and come with 4.3+ final gears. While they don't have the sheer stupid power, they always stay on it, and in combination with lower weight (which ultimately is the other part of the acceleration equation) they yield similar results as far as acceleration is concerned.

So in conclusion: don't just concern yourself with making power. Learn to configure your setup so you actually get to use it.

gears, powerbands and shift points

2005-05-19T21:51:00.000-04:00

Long time ago, I read THIS.
It really made me think, especially that Andi is a _really_ smart dude.
For the longest time I've been pondering how do I write a program that would take gearing, tires size, shiftpoints and come up with the most optimal configuration. In video games (like the Gran Turismo series) you always end up with a 'magic' trans with which you can set up just about any combo you'd like. I spent hours (yes, I know, it's sad, shut up) tweaking it so the top speed on the track would match the redline in last gear available. Then I discovered that depending on the track first gear would have to be long enough that it wouldn't be useless (aka permanent spinning) or short enough that I could just ignore it and don't use it for anything but standing starts.
In real world, we have slightly different problems. We can't change internal gearing of the trans (well, we can, but that's pretty much left for real racing teams and people who really don't have a budget), we can only pick from a limited selection of final gears, and we also we have to watch out for things like not using overdrive for racing situations as it's too stressful. (Doesn't Porsche 911 turbo have like 3 overdrive gears though? Well, I guess that trans can take it, you get what you pay for). So in my case, I got the GM 4speed automatic with lovely 3.06,1.62,1.0,0.7 gearing. These are HUGE drops in between gears. With stock gearing it would shift 6000->3200, then 6000->3700 which totally made it fall off the happy range. First thing was to bump up the rev limiter to 6600rpm and set up shifts for 6200rpm, which depending on temperature and how much I've been beating on it would do it between 6200-6400rpm.
that was slightly nicer, after a shift I'd end up 200-300rpm higher than before. That's not enough however, so I had to go out and get a 3.73 gear :) With that, and the raised shiftpoints, it would shift 6300->3500 (1-2) and 6300->4000 (2-3). That made it much snappier, 2nd gear would shift out at 72, not at 90, 3rd wouldn't go past 140, it would hit 6500rpm at 125mph. It's a much more track oriented setup now, makes for a good daily driver too.

But of course, me being me, I didn't wanna go by seat of pants, I wanted some numerical backup of what it does and by how much.
So all these things combined, lead me to create a spreadsheet that takes into consideration different power curves, gearing, tire size, and shiftpoints and then counts exactly how much work was done in each of the intervals. The problem was to figure out that I had multiple gears with multiple power figures for each rpm and each gear, and I also wanted separate shiftpoints, as you saw at Andi's writeup, it can vary quite a bit.

So here it is: DOWNLOAD

Put in your data and take a look at the average hp rating. Start playing with it. Put in shorter gears, up your shiftpoints, watch the numbers change. I'm gonna post some useful scenarios for which this spreadsheet is useful later.

If you wanna know what's behind the scenes, I've basically taken the HP numbers relative to the gear they're in (yes, you can have separate maps for different gears, all you turbo people should be happier!) and added them up as long as fall fall within rpm range (bigger than the 'landing point' from the previous gear, and smaller than the shiftpoint). These are the points highlight in orange. Under columns tagged W you got a sum and a count of the 'valid' cells for each gear. Then on the right you got it all summed up.

That's where 'interpretation' problems start. Because depending on gear one 100rpm cell can cover more mph, once you end up counting them up you might end up with a different number of cells counted, even though the speed range through which you went was unchanged. Change gears from 2.73 to 4.11 and I can just about guarantee you're gonna see it happen. So what's the problem? Well, you if you add up more cells, you're probably gonna end up with a higher sum, making the comparison moot. So there's two ways of going about this:
1. somehow 'normalize' the hp values according to rpm/mph factor of each gear (there's already some values for doing this, on top of Range colums)
2. go by the average hp per cell values. That's in red on the right. Seems to work fairly well, but I'd rather do it with the first method.
Let me know what you think.

Injector Duty Cycle and Volumetric Efficiency

2005-05-05T12:21:00.000-04:00

In few previous posts I was playing a lot with injector sizing, and figuring out duty cycles, to gauge what kind of injectors do you need for your application.

Few days ago I came across this . Basically it outlines how we can convert injector duty cycles and air fuel ratios into a fairly close approximation of volumetric efficiency.

First you start out with converting injector pulse width into duty cycle. That I covered few posts ago. Once you know how much fuel gets injected, you calculate a total fuel flow. That takes the duty cycle, number of injectors and fuel pressure into consideration.
Airflow is not that far off, since you know your AFR (if you have a wideband; if you don't, you just go by the target/commandered AFR from PE tables). The problem with this one is units. You got lbs/hr and you somehow have to end up with cubic feet per minute. That's just math though, and not a complicated one, you just have to watch it.
The actual calculation of VE is a division of airflow vs displacement, as that's theoretically the maximum of what you're supposed to be able to flow though it. Of course forced induction and big cam/NA applications can go over 100% VE.

So DOWNLOAD spreadsheet. All you really need is RPM and Injector Pulse Width. If you have a wideband, then you can also go off that for your AFR muliplier. This spreadsheet is set up with 12.2AFR in mind, so if you have a different goal, please change it.

In the spreadsheet you downloaded, you'll see two tabs with two different sets of data. One is for stock '99 F-body 26.4lbs/hr injectors during a high speed run with 'good air' where the Injector duty went over 100%. The other graph is for SVO 30lb/hr injectors with a much more healthy Injector Duty Cycle. The weird part is that the VE changes from one sheet to the other quite a bit. Both FuelFlow and AirFlow are actually higher on the smaller injectors. So what makes the big difference? Is it:
1. weather conditions--the 'good air' day was really spectacular, car ran like mad. Just before I swapped the injectors I did some runs just so I know where I was on Duty Cycle that day, and it showed 96% max, while on the good day I've seen it as high as 109%.
2. Old injectors were being pushed beyond their limits as far as flow was concerned, and the flow might have been actually misreported, so that whole set of data as far as VE is concerned is just plain wrong.
3. different day, different injectors, injectors going static, too many variables, stop worrying, you can't compare the two?

The new injectors and O2 sensors are IN!

2005-05-02T18:31:00.000-04:00

Last week I did something very strange: I wrenched on my own car! As strange as that sounds, I am severly 'mechanically challenged' and usually all my alterations/modfications/new parts are done by my mechanic. But even with most of the parts being bought not at retail prices (forums, ebay, friends, etc) it gets expensive quickly. So some simpler things, I've wanted to do myself.

So last thursday, right after work (5pm) I put my car up on ramps and jack it up on a side, and slide myself underneath, looking for the front oxygen sensors. Not only I was able to find them, but I ended up exchanging them almost entirely by myself! Granted, due to them being there for almost 80k miles everything was quite fused together with heat (they're up there, right after header flanges and before catalytic converters) so it took multiple takes of PB Blaster and some other rusty bolt removing spray thingy (can't think of the name right now) to get them to budge. That combined with the fact that I only had an adjustable wrench, and not a real 7/8 open end one, made this a long affair. What I was told was a 15 minute swap, took me 4hrs. But it fired up on first try, and after they warmed up, started oscillating quickly, which I could actually verify by looking at the HPTuners scanner. I was very happy, and proceeded to go get drunk in celebration with my neighbours and a friend that have been my peanut gallery laughing at my grease monkey skills (or rather the lack thereof).

Saturday was injectors day. As per previous posts, on a day with 'good air' I hit 109% duty cycle on stock 26.4 lb/hr injectors, which made me rather scared. I've picked up some Ford SVO 30lb/hr injectors, as I figured that at one point I will need them. And what do you know, that moment finally came.

So a guy I've known for a long time told me to come over and we'll do them. We started at 2pm, and took out the LGMotorsports 3point strut tower brace (which is a bitch, unless you have the suspension completely unloaded) as it was completely in the way. Bunch of other stuff was in the way too, throttle line, all the cabling going to IAT/MAF sensors, and a bunch of things I don't even know what they're called. Once everything was out of the way, we let out the fuel rail pressure, took out the clips holding the injectors, and disconnected the electric harnesses. Few more bolts, and the entire fuel rail was loose, so we lifted it and flipped it around. Once on it's back, we took out the first injector and got sprayed with gas. Lovely, that's exactly why I don't like wrenching. There was a decent amount of gas still left in the rail and injectors, so we spent quite some time letting it leak out on some rags. Then we popped out all the injectors and o-rings left in the injector seats. Cleaning the new injectors was next, we checked to see if there aren't any visible clogs/damage on them. I wish I had the time to send them out for real flow test and a cleaning, but this whole 'out of injectors' situation sneaked up on me from nowhere, and I have a trackday to do in about a month, so I needed to get this stuff done ASAP.
Once the injectors were in, everything went in fairly smoothly, and we mounted it all up without major hassles.
The funny moment came of course once it was all done and ready for the first 'fire in the whole' test, as early on we decided to cool the engine down faster by turning on all the engine fans, but running it entirely off the battery. At one moment the fans just went out, and I though it was some automatic precaution of draining the battery. No such luck as 'timeout' for fans apparently, the battery was dead. So we fired it up from a gigantic charger, and it seemed to work ok, but the idle was surging and hunting, as we didn't flash the PCM with the new IFR tables yet, as we just wanted to see if it works (and waited a bit for the battery to charge up, as we didn't want it to die half way through flashing the PCM). Then the new calibration went in, and the car idled perfect right away. We took it for a spin, and top of second gear at 6300rpm yielded somewhere around 75% duty cycle, while on stock injectors earlier that day it would be closer to 96% (the air wasn't as good as the 109% day). So I can now finally start safely proceed with more tuning and not be afraid of going lean because of injectors not being up to a task.

The amazing part happened on the way back home. I was in MAF mode, logging for all my usual stuff, and the car ran perfect, with ZERO other alterations. That's what happens when it's all calibrated right folks. None of that old school 'lets calibrate AFR with IFR multiplications and MAF shifting' crap pseudo-science.

The only thing right now that's a bit off that I just noticed going through logs are the values of oxygen sensors at WOT. They consistanly average between 820-830mV for Bank1 and 835-855mV for Bank2. I should be at 12.2AFR, so shouldn't that be closer to 900-910mV?
Something's off about PE, but now that I have the hardware in place, I can finally go play with PE/WOT/Open loop mode.

That's probably gonna be another story though...

Logging for MAF calibration made easy

2005-05-02T17:22:00.000-04:00

Apparently if you just want to adjust your MAF calibration you do not need to get into Speed Density mode! A guy named Drew approached me on the HPTuners board, asking why we need to go to SD for MAF calibration. I never really questioned this procedure, as usually I do both at the same time (as new MAF will need a new VE) so I must have it in Speed Density anyway.

So I told Drew to do a little experiement, do few logs in SD and then another few in MAF. We compared the results, and they were nearly identical, any differences were mostly based on not having enough samples. The more samples for given calibration point we had, the closer the two calibrations got.

The good part of this is that you can grab any number of data you got, any mode too, and just keep using the historical compounding function of my spreadsheet to get large numbers of samples, creating a truly universal calibration.

This little fact gets rid of the most annoying fact: you never seem to have enough data for the higher frequencies, as it's hard to get on the gas that long without getting into some hairy situations. But over a course of few days or weeks of more casual data gathering, with an occasional WOT run here and there, you will eventually get enough data. How much is enough? I'm satisfied with my data once I go over 100 samples for each interval. 100 samples at higher frequencies especially, create some very little discrepancies as far as the calibration is concerned. At lower frequencies, I guess since there is more 'leeway' for the air to move in, they still differ, but you end up with so much data for these (because you get it just sitting at stoplights and getting groceries), that the calibrations come out within just few percent of each other.

Hope that speeds up the process. I just spliced a bunch of data files I've had after my last volumetric efficiency altering modification (LS6 intake) and now I have thousands of samples for each calibration point, hopefully yielding a true calibration of my Granatelli MAF.

HPT Dyno spreadsheet

2005-04-18T00:59:00.000-04:00

This is an ugly one for now. It's very much an 'engineering sample' so tread with caution.

As about a week ago I was playing with MAP pressures, I had all this data in a spreadsheet, and it got me thinking: what if I had multiple columns and could somehow see the correlations between MAP, MAF, timing, etc on the actual acceleration. The problem is of course that I don't have any acceleration data. So I went after that first, thinking "if GTech can do it, why can't I?"

So I started with the assumption that samples are taken at 10Hz and then I go off the speed data gathered through speed sensors. Two problems:
1. I actually looked at the high-resolution timing and saw that the intervals weren't exactly 100ms
2. Speed data is given to us only with 0 decimal places

So you put the two together, and the precision of this system is bunk. often times you got two pieces of data that both show 73mph, while in reality is more like 73.1 and 73.9, but if you ask for delta of speed, you'll get a big fat zero. That's no good.

Back to drawing board, take 2:
1. Take the timing from the high-resolution timing ticker and use it to get 'composite' time in milliseconds, kinda like unix-style time. The problem with this is that Excel knows about hours, minutes and seconds, but apparently has no clue about milliseconds. Thus, we're doing this old school: parse the string for 4 parts, and calculate it all back together to make it into the composite millisecond time (who cares what it is, as I use it only for intervals anyway). Ugly, but fairly straightforward, too bad it takes a lot of screen real estate.
2. Velocity--to get this sucker in precise manner is a bit tricker. I decided to go off RPM, as I hope they got precise numbers as far as fireing a spark goes :)
So you take your RPM, tire size, gear, final gear and you get velocity. Great, but now you line them up with the velocities from the sensors and suddenly it doesn't agree. what's different? gears are pretty un-variable (is that even a word?), so probably the tire diameter is off, as it reacts to pressure, temperature, and of course it's rubber squished with 3500lbs of mass so it has good potential of changing. So of course I go by the go adage of "life gives you lemons make lemon vodka out of it" and use the discrepancy to find the more realistic tire size.

How do you do that, you might ask. Well children, you take your calculated velocity and you subtract that from the speed indicated by the speed sensors, and make a separate column for it. then you sum up this column. The idea is that to keep the sum zero, as an indicator that the variances were equal on both sides. Then you use Goal Seek from Excel, and you tell it to make that variance sum to be zero, by playing with the tire size. You'd be amazed how well this works!

Ok, so now that we have rpms, gears, and good tire size, time to get velocity with some precision, finally!
The next step is instantanious acceleration, as a function of dV/dt. Of course there must be some conversions, as your speed is in miles an hour, but your time is in milliseconds. Having an Eurotrash background, I of course pick the SI units for the middle ground, and end up with acceleration in m/s/s, which actually ends up with quite descriptive and easy to remember numbers.

As you look at most 'official' dynometer outputs, you will see 'smoothing' with a value attached to it. I always wondered why that was, until I actually threw some real data at my spreadsheet and saw how jerky the acceleration graph was! So in a general theme of copycating everything in sight (GTech, dynos) I decided to have smoothing of my own. All I did for that is to use bigger intervals, not the ~100ms that it normally gives you, but 'hop' over few cells of data, so you have speed variance over let's say ~500ms divided by ~500ms itself. So it's kinda a moving average I guess. I did it for 4 different smoothing levels, using 1,3,5,7 cells at the same time. Using the 5 cell spread is the most useful I think, seems to almost have the consistency of 7 cell spread, but without eating up too much data.

The best part about this spreadsheet is this:
you get to see how long (in miliseconds!) it takes you to go through a given interval of speeds! This is exactly what all car geeks always wanted: effective not theoretical, and 'area under a curve' not peak numbers! This is about as real as it gets, folks.

There are a few pitfalls/unautomated things:
1. I would like to pick an automatic range of speeds I'm interested in and get stats on that range specifically. (like time, for now I just look up speeds manually, copy the related values for time and do subtraction on them).
2. Automatically changing gear ratios for the calculations, probably based of acceleration dropping off.
3. Automatic recognition of what gear/tire/trans you're using based on rpm/speeds reported.
4. More statistics (so far I do min/max/avg/sum and calculate Injector Duty Cycle on the fly)

Well, it's allmost midnight, I'll put up pictures and such later, for now , this is just the link to the spreadsheet with some example data in it.

DOWNLOAD:
EXCEL (209k)

injector duty graphs

2005-04-16T13:31:00.000-04:00

just a quicky:
when i was logging my car on the road, all i saw was 'injector pulse width' wondering what duty cycle i'm at. after talking to HumpinSS again (thanks man!), he got me an equation:
duty(in %)=pulse*rpm/1200
so i made up a quick graph for it:



it's also useful to look at it a different way:


 
 so according to this, when i got to 21.5ms pulse @ 6100rpm, i was at about 109% duty cycle.  not good.  looks like i might put in the new injectors this weekend, so hopefully i will not have this problem anymore.
 we'll see.

out of injectors?

2005-04-14T17:29:00.000-04:00

I think i'm starting to get close to the limits of my injectors, which is cool, cause with proper AFR (and i'm pretty damn sure it's good) i am finally making some decent power!

Yesterday i was scanning some second gear runs, and for example:
6100rpm, 73mph (top of 2nd with my 3.73s and 315/35-11 rears)
i was getting 19.7ms injector pulse, that means i'm right under 100% duty cycle according to http://www.ecanfix.com/~mdhamilton/dutycycle1.html

And it makes sense too, i was logging torque delievered, and i converted that to hp, and the injector duty follows the shape of HP curve, which it is what it supposed to be. either my car kicks all ass, or the lookup table is overly pessimistic, because there are people with H/C making 440rwhp on 26.4 lb/hr injectors that I have.

I played around with BSFC calculator (http://www.rceng.com/technical.htm) and i'm either making 460 crank hp (with 0.50 BSFC and 95% duty cycle) or my BSFC is different. i did an experiment and it said that i'd be making about 420 crank hp at 0.55 BSFC and 95% duty cycle.

Where i SHOULD be at is about 390hp (0.50BSFC and 80% duty cycle) hmm...i better get to the track soon...

more on MAP pressure drops and Intake tract

2005-04-13T01:15:00.000-04:00

Yesterday night I went out with a friend of mine who is pretty much responsible for me getting into cars at all. As the matter of fact, my '99 Formula used to be his. This time around, he's got a '01 formula M6 with zero options, making it a very light (read: quick!) car. He has very basic mods, Lid, Fram air filter, and SLP Loudmouth. So I decided to see how healthy his car was (it was _very_ healthy, if 'comparative driving' is a measurement is worth anything ;) ).

Turned out his VE is a bit out of whack, as well as his MAF. With his crazy driving, we gathered enough data that in an hour we had both of them inline, along with a slightly better PE settings. We left timing alone for this time, as it was getting late and I had to get home.

But in the process of scoring lots of data, I managed to get his MAPvsRPM data, as per earlier post about intake restrictions.

So now i got 3 sets of data (my z06 cammed car, OtE's stock cam, and Camaroguy's TR224) they both have FRAM filters and stock MAF, while I got K&N and Granatelli MAF. I graphed out 2 scenarios for each car. One is a graph of MAPvsRPM for all data with 90%+ of throttle, and the other graph is 'top 400' samples of biggest MAP values.

OtE's stock cammed car peaked at 99kPa in 2800-4400rpm
The same car would also get 95-96kPa above 5500rpm.

Camaroguy's TR224-112 cam'ed car would do 97-98kPa in 2700-4400rpm
The same car would get only 90-95kPa above 5500rpm

My car (z06 cam+LS6 intake) peaked at 98-99kPa from 2000-4400rpm , (second graph)
This setup would get 94-97kPa above 5500rpm, (second graph)

The 3 cars push different amount of air (from the tiny 01cam through my z06 to 224/.563) they all have different MAF's, lids, filters, and mufflers.
My car seems to have the smallest drop in MAP at higher rpm (smallest bottleneck, I guess bigger MAF and smooth bellows do help a bit) or just the FRAM filters aren't as good as K&N.

There's enough variables here that I can't really make any conclusive comparisons, and there are few unexplained things (why does car with the smallest cam suck the most air?)

Tonight, I will hopefully have a chance to get another set of data for stock 01cam+Mac headers+LoudMouth, so I will probably put up more graphs.

any comments? anyone wants to send me more data?

Intake restrictions measurements

2005-04-09T12:53:00.000-04:00

So the other day I came across an interesting post on LS1Tech.com about MAP not holding steady as the rpms increase. Apparently that's an indicator that you have a bottleneck/restriction in the intake system. After talking to some people, it seems to be a rather reliable source of information about how well your intake is flowing.
So I dove into some logs of mine, to see how mine fairs, and heres few figures:

96-97kPa at 4500rpm-6100rpm and 80%+ throttle
98-99kPa at 2700-4300rpm and 75%+ throttle

So while it is not a huge drop, of course it would be better to not have any at all, especially that I'm mostly interested in the higher-rpm operation. I'm not sure what I can improve, as I have just about all the intake-side mods: SLP lid, Granatelli MAF, LS6 intake, K&N filter (probably dirty after winter, might be the culprit). Another thing to do would be to start porting and polishing everything in the path of air, namely MAF and Throttle Body.

A sidenote: why won't someone test all the various lids with this method? it's a quick bolton, and all you need to do is few 'in gear' runs from 2-6krpm and see how MAP behaves throughout the rev-range.

So I wanted to compare my 'drop' to someone else's 'drop' to see if mine's bad or just minor.
The past few days I've been helping this kid with a typical 'got new cam, I get mad knock now' story, so I looked at his logs how his car compares. This is a 2002 Camaro with SLP lid, Fram Filter, FTRA

He has a bigger intake restriction:
1800-3200rpm can get 98kPa in MAP, while
4600-6200rpm gets 92-96 (with 92 on the high rpm side and 96 on the lower).

I will post pictures demonstrating the dropoff later. If anyone has any good logs/screenshots of really bad (or not at all) dropoffs, please send it to me, I'd love to see more extreme cases and see the effects of them.

Improvments on AutoMAF spreadsheet, ver 2.5

2005-04-08T12:27:00.000-04:00

Car's still in the shop for some upgrades, so I haven't been doing much with it lately. I have however been sitting on a new version of my AutoMAF spreadsheet for a while now, I don't know why I didn't release it yet.

It's kinda cool, it basically keeps 'running totals' for number and sums of all samples, so you can keep on adding more and more data as you log throughout the year. The point is to gather the most data, so the results are truly representative of how your setup behaves in different conditions. Of course if you change airflow, then you gotta zero history out, and start from scratch.

http://allmod.net/hpt is the link as always.

Let me know if it works for you.

Timing, Java, and MAF notes

2005-03-20T15:47:00.000-05:00

Just a quick update:

I'm redoing my programs in Java. UGH, that is a major head-adjustment, as I haven't coded anything in Java since 1998. The good part is that I have some good friends to help me out, and this is gonna be platform independent. Some things I'm gonna release to public, others I'd rather keep to myself, so I'll do it as a server-side servlet or something of that sort.

I've been doing a lot of researching on spark timing, and all I can say is WOW, there's a lot of myths and misunderstanding about the relationship between air-fuel ratios, spark timing, dynamic compression, valve events, and probably a bunch of stuff I haven't heard of yet.
Here's a good link to videos that will get you thinking: http://www.innovatemotorsports.com/resources/lm101.php
and then there's more reading:
http://www.innovatemotorsports.com/resources/myths.php
I'm going to try to write up an more concise summary once I plow through all the reading.

One more quick note about MAF calibration. During finding info on timing, I found a company that does a piggyback computer for Subaru Impreza, and they show how to recalibrate their MAFs to account for changes in the intake path.
http://www.ecutek.com/tuning/induction/

Alright, back to reading on eliminating false knock...

Data cleanup and trendline madness

2005-03-17T23:23:00.000-05:00

Looking at the graph of raw MAF values it is obvious that some points contain wrong data:




So I decided to come up with an easy method of cleaning it up, as visually there is a very strong basic trend, and few clear outliers.
I created a bunch of different methods for it in Excel, but they all seemed to fall to the same problems:
1.  very manual and non-automatable
2.  don't work universally for the whole range, they'd work for either low or high range, but never for both
3.  too simple to self-scale for different samples, as some datasets are dirtier than others

Thus, instead of working on a wacky function with simple math, I figured bringing the function to a more manageable form first would allow to use simpler methods. Having seen how a lot of relationships in nature are better viewed on logarithmic scales, I started graphing first one, then both axis as LOG10(freq) and LOG10(flow).
here's the amazing result:



The datapoints build a line! so I quickly put in a linear trendline, and it's off, but it just seems to be thrown off by some values that are still clearly way out there. Thus I procede to throw out TWO datapoints with zero values, just to see what happens. Look at the trendline, it shifts significanly, R^2 indicates a MUCH better fit just by tossing 2 points out of over 22.7k of them! And I thought large data samples eliminated small mistakes...



The curisity settles in, and I create a VERY dirty hack of cleaning data, and set it up for +/- 20% error (everything more than that gets discarded), making the dataset come down from 22.7k to 20.7k data points. this is the result:



Less ouliers, better fit.
Then I shorten the leash of my 'clean' filter to just 10% +/- of each other, cutting the graph down to 18.9k points:



Observations and conclusions:

how does a logarithmic scale 'linearize' a 3rd order poly function?
ridiculous values produce ridiculous results
large samples of data aren't the automatic protection from dirt as we'd hope it would be.
data cleanup is apparently much more important than i ever thought

please comment, I'm befuddled. more to come once i figure it more out.

Direction of MAF spreadsheet

2005-03-15T14:39:00.000-05:00

So i'd like a general opinion here:
Guys, should we make it into an app, or should we keep it as a spreadsheet?
I am pushing Excel to its limits as far as pure excel functionality goes (as in no VB). I refuse to do VB in Excel, because then you are a victim to the limits of both. Also, I haven't touched Basic since 8bit ATARI Basic ;)

I'm thinking of a Perl app, but compiled into a standalone. This way we have the power of normal programming language, but ease of use of any other script. I don't want people to copy, paste, filter, etc because that's just error prone (people make mistakes, computers don't). I want to be able to feed a raw csv and get a calibration on the other end, with NO other interaction. I want to do things like composite/historical data, automatic data cleanup, and other more advanced stuff, which excel is just really not suited for.

Or should we have two separate things--the pretty Chad spreadsheet for quick'n'dirty stuff, and my more advanced standalone app? I talked with Chat extensively yesterday, and we are doing a lot of the same things, but we have very different approaches to it, so I'm not sure where we should take it. I personally don't care, I can use it all, but eventually it is for you, The Peoples of HPT, that will use it, without the need to dive into the nasty details.

Let me know, as I am stuck right now contemplating what to do, I can go any way you want me to, so hint me in the right direction. Let's hear it!

is PE/WOT tuning universal?

2005-03-11T18:00:00.000-05:00

PE tuning should be super-simple and really car-independent: if all VE tuning is done right, it air-fuel should stay close to 14.62.

Development of maximum hp/tq happens at specific AF ratios. Then there's reliability to be dealt with. My general PE tuning philosophy is to set AFR to 12.8 (max TQ) at lower rpms (you're less likely to predetonate at low load), usually until peak torque, then switch to 12.2, for max HP, as that's the direct cause of acceleration. These are also the safe settings, so for once it's a win-win situation, not the usual compromise between performance, budget, and reliability. ;)

I'm gonna attach 2 files to this PE settings for LS1 in F-body vs LS1 in a Vette and then another comparison of LS1 vs LS6 AFR's@WOT. The Vettes aren't completely retarded from the factory like the F-body tunes are. So basically take the LS6 values, and put them in for your PE, and you should be good to go. Yea, you can always get it a bit better with a wideband, but this should be pretty damn close to where you want to be with these numbers.
They even have a little extra 'safety bump' around 4-5krpm to ease up on cylinder pressures (max TQ is a direct result of max cylinder pressure).
I use PE values I developed on my own, and they happen to closely resemble the LS6 ones. This find was a nice boost of confidence, as it confirmed that my thinking is on the right track.

LS1(f-body) vs LS1(vette)

LS1 vs LS6