There are a few great resources here about MAT fueling, but I'm having trouble following the logic. From this thread:
1. The ECM uses airflow in g/s to lookup a multiplier in the MAT Inverse Term Lookup table.
2. This multiplier is used to combine MAT and CTS values to get a new air temperature value (T).
3. T is used to lookup "counts" from the MAT Compensation table.

Now, from the fueling thread:
4. This T (still referred to as "MAT", confusingly) is used to calculate air density, which is a factor in a grams/cylinder calculation as below.Wait - this whole process started with a lookup value based on air density (airflow in g/s). How does the process of calculating air density begin with a value that is dependent on air density?

This previous thread is saying that the hack (and its logic described above) is wrong, and that the order is changed around:
1. The ECM uses MAT temp to get "counts" from the second table.
2. The ECM uses those counts as the lookup value in the first table to get a multiplier.
3. The ECM uses that multiplier to combine the MAT and CTS for airflow calcs.

This makes sense because the "counts" from the first table range from 0-128, the "airflow" lookup values of the second table are in that range. Moreover, multipliers at airflow of 128 and over are all the same. However, it doesn't make sense that the weighting between MAT and CTS would be based on the MAT temp. It makes far more sense that this multiplier would be airflow-dependent, as described in the first thread. If airflow is zero, cylinder temp is going to be entirely determined by CTS, and if airflow is high then CTS will have much less effect. Which is correct?

Edit: This link adds some good info corroborating the first theory. However, I still don't get where that first airflow value comes from.

 

Airflow (theoretical) is calculated based on displacement, RPM, MAP, etc. It is then modified based on the manifold and coolant temp.

GD

 

Thanks. So:

1. Ideal gas law is used with MAT to calculate airflow.
2. That airflow is used to lookup a weighting factor to combine MAT and CTS for a more accurate temperature.
3. The new temperature goes to a lookup table, and the factor from that table is used to calculate a more accurate airflow than what was calculated in step 1.

Approximate temp -> approximate airflow -> more accurate temp -> more accurate airflow

That right?

 

Yes pretty much. It's all just levels of refinement incorporating additional sensor inputs to refine the airflow calculation.

On newer standalone systems like the LINK that I run, they have what's called "modeled mode" where you input all the information and they model the engine in software..... I don't even use an IAT or MAT sensor as they are so prone to heat soak and wind chill and placement that it makes them a total pain in the neck with all the levels of weighting and so forth. Wideband closed loop lambda, fast processing that allows more complex modeling calculations, etc.... mine bases everything on CTS.

GD

 

Yes, it does form a type of circular calculation. But each pass through uses the airflow value from the previous pass. Since the MAT, CTS, and less so the airflow, doesn't change rapidly, it works. What is interesting is that the CTS/MAT compensation routine only runs 10 times a second. While the routine that calculates the airflow, mass of air per cylinder, and injector PW runs 80 times a second.

RBob.

 

That sounds super convenient. I'd love to run a standalone if it weren't for the cost and my compulsion to have all the stock functionality like the MPG display work.

Interesting - thanks! That makes sense that it would use the previous iteration's airflow value. How does that handle a rapid change in throttle position? Does accel enrichment/decel enleanment cover that?

In order to compensate for my engine needing over 100% VE at peak, I've lowered injector flowrate and my VE tables by 10% each. Now I realize this will skew the correction factor to get actual air temp from MAT and CTS. Is there a better solution, or do I just need to recalibrate my MAT tables to compensate?

 

That stuff could be made to work with a LINK. You can define any kind of output you like. PWM, Analog, whatever. It's just a matter of programming it with the built in logic functions. But yeah it's not cheap. You get what you pay for most of the time.

If your VE is over 100 then something isn't being modeled correctly. Displacement, injector flow rate, etc. Or you have mechanical issues that you are compensating for in the tune like low fuel pressure.

GD

 

That and the change in air mass due to CTS/MAT change is minor.

The VE isn't used, mostly MAP, RPM, and MAT/CTS. (and to add, cylinder volume) (and to change again, the VE is used).

RBob.

 

Hmm, maybe someday...

I've measured FP with a mechanical gauge, and it's right at 40psi with no vacuum. Cylinder volume is 784.2cc, which comes out to 382.8ci (so +- 1%).

It was my understanding that a modified NA engine could have over 100% VE at peak torque because of wave tuning effects, no? By "over 100%", I mean a few percentage points over in a cell or two.

 

In this thread, TRAXION gives the following equation for air mass calculation.Is a different equation used to calculate airflow here? I would have thought they'd multiply that by RPM/60 to get g/s. I can't picture how they'd get airflow without considering VE.

 

A few points isn't a concern really. Might be normal for your engine. And yes it is possible.

GD

 

This is common with the GM ECMs. Many of the TBI ECMs that use two VE tables that are added together, add up to over 100% VE. Doesn't add fuel beyond that, but it is interesting.

I believe that the main reason for going above 100% VE is that the VE is based on the manifold pressure, not barometric/atmospheric pressure. This makes the induction side of the fueling immune to changes in barometric pressure. Due mostly to changes in elevation.

To compensate barometric pressure on the exhaust side, there is a table for that. It increases the VE value as the pressure drops. Less back pressure on the exhaust means higher engine VE.

RBob.

 

You are correct, VE is used in the mass of air per cylinder calculation. I'll change my post...

Note that the equation you posted should also include the volume of a cylinder:

GMS of Air / CYL = ((MAP - EGR) * INV MAT) * CYL VOL * VE

RBob.

 

RBob, thanks as always. Had to step away from this for a bit due to work and vacation, but I'm back to figuring this out. That's very interesting that barometric pressure affects VE - I never would have considered that!

I'm making a Python script to correct the two MAT tables based on datalog data. In the inverse term lookup table, I notice that airflow goes up to 256 g/s. Doing some quick math:

• Assume a standard air density of 1.225 g/L (a generous value since it's at sea level and 15 °C)
• Assume upper-end numbers of 6000 RPM and 100% VE on a 5.7L V8.
• Airflow = (density) 1.225 g/L * (displacement per cylinder) 5.7L * 1/8 L/cyl * (VE) 100% * (cycles per second) 6000 rev/min / * 1 min/60s / 2 = 43.6 g/s (divide by 2 because it's a 4-stroke)

This is 1/6 of the maximum table value, which makes me suspect my assumptions are off. Using the entire engine's airflow instead of just one cylinder would get me to ~320 g/s, but I'm not confident that this is the problem/my only problem. Am I on the right track?

Edit: Plugging the same values into my script, which recursively calculates g/s, and I'm way lower than either of the above numbers. I have:

mass_flow = MAP * inv_MAT * VE * RPM/60 * 1/2 * displacement

where

MAP = (MAP_kPa * 65,536/694 + 2,647)/256 ≈ 0.369 * MAP_kPa + 10.34 = 36.9 + 10.34 = 47.2

and (very conservatively assuming comp counts = 0)

inv_MAT = 1/((MAT_comp_counts + 233) * 128) = 1/233/128 = 3.4e-5somass_flow = MAP * inv_MAT * 100 * 6000/60 * 1/2 * 5.7 = 47.2 * 3.4e-5 * 100 * 6000/60 * 1/2 * 5.7 = 45.7 g/s

And that's using the full displacement of the engine! Now I'm definitely missing something. I noticed this value is on par with my previous per-cylinder calculation, but I think that's a coincidence since it's comparing apples to oranges (per-cylinder vs full displacement). On further review, I found here that the ECM multiplies by the raw VE (0-255) divided by 256, so inputting VE=100 to the above equation is incorrect. It should be VE=1 (or I guess 255/256 = 0.996?). Fixing that goes down two OOM to 0.457 g/s, which is a good 3 orders of magnitude off my prior calculation.

It takes roughly 1.5 cfm to make a horsepower, which is about 0.7 L/s. Estimating my engine at 300hp gives 210 L/s. At 15 °C, that's 257 g/s, or at 80 °C it's 210 g/s. I'm racking my brain trying to figure out how to get the airflow number in this ballpark. Going back to the original formula, the following play into the mass flow calc:

• MAP: Perhaps the equation wants Pa instead of kPa? That would get me about three orders of magnitude, but it doesn't make sense to me that there would be that offset of 2647/256 in the MAP equation then.
• inv_MAT: Assuming zero counts makes this as large as possible - nothing to gain here. It's possible this could be wrong in combination with other factors, though.
• VE: Already know this is correct unless the info in the above link is off
• RPM: Seems pretty cut-and-dried, right? I guess there's the question of whether this is scaled by two to account for four-stroke cycle.
• Displacement: Maybe it wants displacement in cc? This seems most logical yet. However, if I'm reading the hac right this is converted to liters. However, it's stored as a value from 0-255, which is converted to liters by dividing by 223.157.
• I could just be missing something small, like how the MAP value isn't actually MAP but a value calculated from MAP.

Slightly unrelated, but the ANHT hac says the inv MAT term is cyl_vol/((MAT^.5)+233)*128. That won't fix my current problem, but is it supposed to be the square root of the MAT comp counts in the inv MAT equation?

 

What "problem" are you trying to solve exactly?

MAT and IAT are troublesome. In a perfect world they would reflect actual air temp - unfortunately there's this thing called heat soak and if the hot engine sits in a hot parking lot for 20 minutes that MAT sensor is going to read REALLY high for quite some time on startup till you get the under-hood temps back down to steady state conditions.

Also they don't change instantly - so when then engine revs up, the MAT sensor has a certain amount of latency to it. It's not an open-element sensor on the TPI cars - it's just like the coolant sensor and is a closed element brass sensor and mostly reflects the temp of the manifold itself, rather than the actual air temp. The manifold is going to impart some amount of heat to the air - based on it's temp and the airflow across it. But without an accurate IAT there's not really a starting point to know if you are starting with 35 degree air flowing across a 140 degree manifold, or 120 degree air flowing across a 140 degree manifold..... so it's a huge approximation that IS GOING TO BE WRONG in the vast majority of scenarios, but will get trimmed on the back end by the feedback loop.

In practice, what you measure carefully and derive today - will likely be wrong again tomorrow. It's just an approximation and you can only do so much to make it perfect. Applying all the math, while a fun exercise, is not going to account for all conditions.

This the WHY behind most OEM's using MAF systems. Speed density has it's limitations and part of those limitations is due to sensor and testing accuracy in a very dynamic environment.

GD

 

One easy thing to do is simply relocate the sensor out from the manifold plenum, get an actual IAT from a LT1 4th gen and put it in the intake tube in front of the throttle body.

Then simply disable the Inv MAT table in the calibration. You've just decoupled the intake air temp from the coolant temperature.

This is what I did (was actually forced to with the Miniram). Any IAT tuning is done only via the MAT compensation counts table.

 

I notice that AFRs are not consistent between WOT pulls, and I am sure this is because of an outdated MAT calibration. Good to know about the heat soak issue - maybe that's why I've noticed it running EXTREMELY lean on hot starts. I'm not hoping to get it perfect, but I think I can improve it. We'll see. I just need to nail down the ECM's math so I can figure out what my airflow is at each row of my datalog.

I've seen that mentioned. Do you have any issues, or does it work well? I'd think that still using the inv MAT table would be better (in theory), but if it works it works.

 

Actually it works extremely well for me. Also, why would you ever want to be mixing coolant temp into to the air temp calculations anyway?

The car and system should have been designed to keep them mutually exclusive in the first place IMO.

Devils advocate though... my Miniram runners are extremely short. So it could be that the long TPI runners require knowing the actual manifold temperature (via coolant temp) due to the amount of time the air has to pick up heat.

 

I think you got it - there's always going to be some finite amount of heating between the IAT sensor and the cylinder itself. This may be negligible, or it may not. In theory, it would be more accurate to tune and use the weighted combo of CTS and IAT, but it looks like you and others have experienced that it's perfectly workable without.


I just need help deciphering the ECM's math, and then I can share my calibration script with the community. I've just finished it based on my hacky, assumed math, and I'm fairly happy with the results. The data are of course noisy, and they are polluted by VE changes from log to log, but it appears there's a general trend of running lean as CTS - MAT increases. It seems to lean out after the inv MAT multiplier plateaus at (96 g/s, 0.125), but I understand you have to patch the code to change the values after the plateau.

Based on the vertical trend, it's giving too much weight to CTS. Leaning out at higher CTS means it's underestimating density, so overestimating temperature. Temp is estimated as MAT + (CTS-MAT) * mult / 128, so to bring the estimated temp down I need to reduce that multiplier. I'm still thinking through the implications of this.

This first plot just uses my datalogs from the past week to try to minimize VE changes, and the second uses all 32 datalogs over the past month since I started datalogging my wideband. I expect the first plot is more reliable at higher airflows and the second at lower airflows. In both, there are very many possible sources of skew/bias, such as higher airflows being more likely VE and lower temp differences being more likely open loop after startup. Oh, this is also ignoring data below 1600 RPM to keep within the upper VE table.

 

I had a similar hot restart lean issue. Fought with it for a long time both on stock ECM's as well as running the EBL system. I ended up doing what GM did and just throwing a lot of fuel at it on a hot restart. There should be some startup enrichments and a hot restart enrichment that you can use to bridge the gap between startup and closed loop where the fuel trims can take over and fix the problem while the temps stabilize. I moved the IAT - first to right before the throttle body, then later to the air filter itself, I even added fuel rail temperature to my standalone to eliminate fuel rail heat soak as part of the problem. Didn't make any difference. If you move the IAT (MAT) out of the engine bay then you get wind chill and the air temp in the plenum is not accurate, if you leave it in the engine bay then you get heat soak and again the air temp is not accurate. You basically can't win since the IAT sensors don't respond fast enough. That's been the major problem for OEM's as well - BMW seems to have a very fast response IAT sensor that a lot of people use in the standalone community. Won't work with a factory GM computer though.

This is THE REASON that GM and every other OEM pretty much abandoned speed density. They made it work with some hacked together code with a bunch of fudge factor and relying on closed loop but ultimately it wasn't accurate enough for emissions, etc. So they went back to MAF. All the LS's and even the Vortec use MAF. And I assure you it isn't because the MAF is cheaper than a MAP and IAT - it most certainly isn't.

Interestingly, my Vortec with FIRST manifold doesn't seem to have the same level of issue with lean out on hot restart. But the new ECU I'm running may take that into account. I don't use any form of intake or air temp. It works just fine using coolant temp only. And it's common to tune many different makes and models this way on the system I use. IAT is really only used for forced induction where we need the temp coming out of the intercooler, etc.

GD

 

Take a look at the attached under:
Simulation B - Effect of MAT and Coolant Temperature on BPW
and
How Flag 0x018 b4 Affects BPW
I believe they will address the issues you are concerned with.

HTH, Elky

 

Interesting results RE: Simulation B.

Essentially agrees with my experience. Pick your poison. Both methods (MAT and IAT) suck in different ways. But such is the variable nature of speed density tuning and why it is inherently less accurate. I tried several locations for the IAT but there's always some amount of heat soak or wind chill.... even if it's "outside" of the engine bay. The temperature fluctuations from morning to afternoon in the summer play havok with it. Which is likely why GM didn't choose to do that themselves. But as you pointed out the MAT sensor basically tracks the coolant temp very closely.... which begs the question - why not just use coolant temp and forget about the MAT sensor altogether.

Don't get me wrong - I run SD myself. But with closed loop WB (without converter dithering, though my system can do that also if I wish to enable it) turned on after tuning in open loop..... my fuel trims are typically hover around negative 5 percent or less with the open loop fueling slightly on the rich side. I would rather have closed loop pulling out some fuel than having to add it. My fueling is based entirely on coolant temp, and I will run an IAT in my intercooler piping when I go to a procharger, etc. Compensation is important for forced induction. But for NA.... I haven't seen a compelling reason to bother.

GD

 

And let us not forget the frictional heating of the air as it squeezes past the intake valve...

RBob.

 

Had a feeling this was something that you were working on from your very first post, and not any particular issue that you were tuning yourself through. Especially when you brought up Tim's old post (Traxion), could immediately tell you had some unfinished business you wanted to complete for the DIY community... and that is always a good thing. As always though, these posts go the wrong way and embellish personal opinion for particular systems without any visual fact, eg; videos of street runs, track runs, legitimate datalogs showing the discrepancy. It's always all subjective. I was ready to chime in to explain why Speed Density is in fact better than Mass Air Flow, whether through EBL, SD2 or XFI, but you clearly are asking for the original algorithm's GM was using when coming to their own final air/fuel conclusions, correct...?

- Rob

 

Elky,
Thank you! That's an incredible document. Took a bit of digging and troubleshooting, but I think I figured it out. I had been scaling the value from 0x80E (MAT/CTS delta mult table) twice - my XDF already divides it by 128, and I was repeating that in my code. With that corrected, my calculated airflows correlate closely with your PWs listed in Simulation B Table #1 within 1% error. Mind, this is all based on ratios (I don't have the math to calculate BPW from airflow), so my mass flows could be off by some fixed multiple.

In fact, your study assumptions (Appendix B) list an airflow of 32 gm/s at the listed parameters. In that cell of my results, I have 34.2 gm/s. Most of my uncertainties were factors of two or greater, so I'm not sure how I'd be off by just ~10%. Some of these assumptions appear to be values you fed your simulation (MAP, RPM, TPS, etc.), but I don't understand how you could have input others, including airflow.

Is this airflow of 32 g/s an exact, hardcoded value, or is it an estimate based on your other parameters?

MAT generally follows CTS, but it's far from a perfect fit. Maybe it's just the engineer in me, but I see the value in considering both. If anything, I'd think you'd want to just use the MAT and ditch the CTS - while the MAT is partially driven by coolant temps, it's still more driven by air temp than the CTS is. If you want accurate fueling, you somehow need to consider both the ambient temperature and the heating it experiences as it makes its way into the cylinder.

That said, I agree that an open element IAT/CTS combo seems like it would be better (although if you could sufficiently insulate the IAT from the manifold, I think it would be better to mount it in the MAT location), and I can't argue with not wanting to spend time "fixing" something that already works. In my case, my WOT AFR fluctuations are unacceptable.





One interesting thing I noticed that I thought I'd point out - "MAT compensation counts" is just a temperature term. If you look at how it factors into the airflow calculation, it's 1/(comp_count + 233). You'll also notice that compensation counts varies 1:1 with °C, and if you interpolate it's 40 at 0°C. That would make the scaling term 1/(40+273) = 1/273 at 0°C. It's no coincidence that 0°C converts to 273 K in absolute temperature, which is what you need for the ideal gas law.

So all this logic basically boils down to estimating temp of air in the cylinders (0x80E) and converting that temperature from Celsius to Kelvin (0x7FD). I'm not sure why they needed a whole table and that confusing math to add 273 to the temperature, but I assume it must be faster somehow.

This supports the statement I've seen that you shouldn't mess with compensation counts. If you're just using CTS, you have to, but otherwise you're just corrupting the conversion from °C to K. I tried dialing in AFRs with the comp count table before I understood this, and I did not have good results.

 

Ah, of course! As I understand the math as detailed in my previous post, this is not directly accounted for in $8D's logic, correct? Since frictional heating is (mostly) based on velocity and is (mostly) independent of MAT/CTS, I would think this factor is indirectly handled by the VE tables.

It's a little of both it started out as an issue I had, and as it has snowballed I figured I might as well share it. It seems there are arguments on both sides of SD vs MAF - seems like the gist is that SD is better for race applications, whereas MAF is a cleaner solution for driveability.

Yep, that's exactly what I'm looking for! I think my current understanding is good enough to get through it, but I'd like to tie up the loose ends verifying my results.

 

As you know, air flow in SD is calculated using the ideal gas law. It's not really known as it is for a MAF engine. So in the code simulations, I just plugged 32 gm/sec as if it were known. It could be any value, but 32 gm/sec accorded closely with other values in the referenced simulation based on other information I had obtained.

Another thing that's important is making calculations that seem intuitive is that they cannot always be done with base 10 math because they will provide results inconsistent with those of the hex math the code uses. Hard to explain, but have to trace the code in hex to understand (carry bit add back, bit multiplication: 8x8, 8x16, 16x16, etc.)

 

Thanks - that gives me a little more confidence in my results, and good to know about the roundoff errors from hex math.

The agreement between our results show that it apparently has little effect on PWs, but RBob said that airflow calcs are recursive. Replicating this would be quite complicated, so I just called my MF calculation on a recursive loop until its change was below some threshold. IIRC, it only changed a few percent the first recursion and little after that, so it doesn't particularly matter.

 

I don't quite understand RBob's statement about airflow calcs being recursive. Perhaps he's referring to the fact that L006D=BPW Temperature Scaling Factor is computed 10 times a second, whereas BPW which uses L006D is computed 80 times as second. L006D is very important to BPW calc because it's derived from airflow, coolant, MAT, and cylinder volume.

If you can provide all the input parameters you want to simulate (RPM, MAP, your cyl vol, etc.), I can run them through my $8d code simulator to provide L006D, calculated airflow, BPW, etc.. The output will not be approximation but exactly what the code provides.
Elky

PS ---
Regarding: The agreement between our results show that it apparently has little effect on PWs. It the "it" you're referring to is temp, I believe it has a major effect until MAT and coolant approach equilibrium

Also, it interested with regard to your calculations, the attachment includes my programming notes on L006D.

 

I believe Rbob stated that the calculation uses the airflow results from the previous calculation. Which is "iterative", not "recursive". From a software engineers point of view anyway. I doubt the ECU has the memory or processing power to do any actual recursion.

GD