Scanner Basics

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

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

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

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

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

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

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

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

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

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