Friday, April 25, 2008

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:

NormalAVGview.png

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

ECT27c.png


warmer (43C):

ECT43c.png


warm (58C):

ECT58c.png


hot (72C):

ECT72c.png


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:

SurgingSummary.png


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:

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

Sunday, April 06, 2008

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

Saturday, April 05, 2008

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