Prediction Coefficients

[griffincox]

There are a few blurbs about this here and there around the forum. Not much detail, and surely nothing on the math behind it or the calibration of it.

Chris posted:

yes they only operate when MAF is used. They are used to predict the future airflow value from past airflow and TPS & MAP inputs.

They are found under: Engine>Airflow>Dynamic>Prediction Coefficients

There are 10 tables (in my cal).



Each of these tables has 30 (0-29) columns that correlate to the 30 zones of the VE coefficients.

This is the zone numbering scheme for the 30 zones:


This is an example of zone boundaries (found right above prediction coefficients):



I have looked at a number of Gen IV calibrations... Some have zeros, some have values, and those with values are wildly different.

Even more difficult (visually on the fly) is correlating the location of the cells to what they actually mean.

I put together this spreadsheet to see if there is a correlation. This data is from a 2012 ZL-1. Good example of inconsistency, is that the CTS-V (Sigma II) with the same engine has all of these tables zero'd...

And looking below, you will see values much smaller than 1/-1 and some as large or small as 300/-300 (some even right next to each other!).




Anyone want to share their experience and knowledge of these tables? I assume they are functioning and help MAF predictions, so they seem important.

Prediction Coefficients.xlsx

[LSxpwrdZ]

Bump....

I've been up for the last 5 hours on the dyno playing with these settings and mapping them out trying to figure out what they do. Trying to get the blended SD/MAF to act right under load. Seems these prediction coefficients are the cause of some of it....

[SultanHassanMasTuning]

^why not populate a VE run custom OS and do a blend that way

[seven ends]

Interesting, my 2010 E38 truck tables are all zero'd out except for base, current, and corrected.

[LSxpwrdZ]

Zeroing all the prediction coefficients will achieve desired fueling when in blended state. I am running a custom OS on this particular car but with the prediction coefficients left stock (populated with data other than zeros) commanded fueling is off in boost when the blended state is still active (under dynamic airflow disable rpm). As soon as it switches over to Hi-speed mode (MAF Only) it obviously clears up.

I was moreso trying to figure out what these tables do. 99% of the time zeroing these tables out when you have an issue with commanded vs actual lambda will cure this problem.

[GrannySShifting]

Are you saying you had tuned VVE tables in SD mode purely, then enabled MAF got trims right, but when it was using blended version of both at certain times it was out in left field James?

[barum]

From what I've been able to gather the formula could be something like:

DynamicAirflow[n] = DynamicAirflowBaseGain x DynamicAirflow[n-1] + DynamicAirflowCurrentGain x MassAirflow[n] + DynamicAirflowOldGain x MassAirflow[n-1] + DynamicAirflowCorrectedGain x MAPTPSCorrection[n]

MAPTPSCorrection[n] = DynamicAirflowMAPCurrentGain x MAP[n] + DynamicAirflowMAPOldGain x MAP[n-1] + DynamicAirflowMAPOld2Gain x MAP[n-2] + DynamicAirflowTPSCurrentGain x TPS[n] + DynamicAirflowTPSOldGain x TPS[n-1] + DynamicAirflowTPSOld2Gain x TPS[n-2]

In above the sum of
- MAP gains seems always be zero or nearly zero
- TPS gains seems always be zero or nearly zero
- BaseGain, CurrentGain and OldGain must always be 1 IF MAPTPSCorrection function has been zeroed out => you can play with differently weighted average of the two most recent MAF readings and previous DynamicAirflow

Edit 9/24/2015: I found an old post by Bill (http://www.hptuners.com/forum/showth...l=1#post112050) where DynamicAirflowCorrectedGain is shown to relate on transient correction. In the above I had assumed MAP + TPS terms would be the transient correction. Anyway, it would be interesting to know if Bill had gotten this information by looking at disassembly (I miss the ability to modify the program code directly as I am able to do with older Saab stuff)

I tried values from LS9 and ended up having Dynamic Airflow at permanently higher level than MAF reading, hence the above "rule".
I'll have to check whether the car was in hybrid mode (MAF + VE) during that (accidental) test, but earlier when in pure MAF mode it didn't seem to respond to these changes at all.

However depending on the application, there are quite a few differences between them
- there are areas in LS7 where MAP + TPS gains has been zeroed (cells 2 & 3 which activate when leaving from idle)
- LS9 seems to disable all MAP + TPS gains BUT values of BaseGain, CurrentGain, OldGain don't sum up to 1, also CorrectedGain is set differently (the function at the top this post might be different or not correct at all)
- LS2 (E40) seems to disable either MAP + TPS or only MAP on some cells
- LS3 seems to use only BaseGain and CurrentGain, OldGain is zeroed out as are MAP and TPS gains

Actual log + calculated Airflow w/ LS7 coefficients (MAP + TPS zeroed out). As can be seen, calculation corresponds to logged DynAir quite nicely even though MAP + TPS correction was left out.



Same log but airflow calculated w/ LS3 coefficients (MAP + TPS zeroed out), almost no change at all to previous.



Again same log but airflow calculated with 3-average (MAP + TPS zeroed out)



as is here but with 50% weight on current MAF, 20% weight on previous MAF and 30% weight on previous Dynamic Airflow reading



More testing is needed to see how they work (or do they work at all) in practice.
According my experiences the "raw" MAF seems to be much smoother than DynAir especially when engine is showing bucking or "misfire like" tendencies using OEM coefficients with moderate (18 deg overlap @ 0.05" lift) cams.

[Bluecat]

Are you saying you had tuned VVE tables in SD mode purely, then enabled MAF got trims right, but when it was using blended version of both at certain times it was out in left field James?

Yes, what James is saying both SD and MAF are tuned according and operate properly independently. But when both are being utilized and its running the normal blended dynamic airflow mode, it goes stupid sometimes. The most common issues I've experienced is what James was pointing out about on boosted cars. Below the dynamic threshold before hi speed mode gets forced, the stock prediction coefficients are problematic. Most commonly I have seen it basically cut the air flow in half in boost at low rpm, which causes the car to go way lean and won't run. The quick solution is to lower the hi speed force rpm low enough to avoid the problem.

I made some posts about this stuff back in like 09-10, but no one wanted to acknowledge the problem or discuss it back then. I was doing lost of maggies in those days when the 5th gens first cam out. With boost at low rpm and trying to keep the SD functional with a high rpm disable in the 2-3k range it just wouldn't work. I tried playing with the numbers with little success. Tried numbers from a ls9 tune which obviously didn't exhibit the problem. Nothing worked for me short of setting the disable rpm to like 1K. I assumed it was a os bug or like always due to tables we couldn't see or get too. I later came up with a set a coefficients that I use, but still occasionally have issues and have to drop the disable rpm lower than I'd like.

Would love to see this cracked and us know what the real math behind it is. Many times Id like for the SD to play a heavier weighting in the blending or would like to filter the maf signal more heavily due to a dirty signal.

[Bluecat]

From what I've been able to gather the formula could be something like:

DynamicAirflow[n] = DynamicAirflowBaseGain x DynamicAirflow[n-1] + DynamicAirflowCurrentGain x MassAirflow[n] + DynamicAirflowOldGain x MassAirflow[n-1] + DynamicAirflowCorrectedGain x MAPTPSCorrection[n]

MAPTPSCorrection[n] = DynamicAirflowMAPCurrentGain x MAP[n] + DynamicAirflowMAPOldGain x MAP[n-1] + DynamicAirflowMAPOld2Gain x MAP[n-2] + DynamicAirflowTPSCurrentGain x TPS[n] + DynamicAirflowTPSOldGain x TPS[n-1] + DynamicAirflowTPSOld2Gain x TPS[n-2]

In above the sum of
- MAP gains seems always be zero or nearly zero
- TPS gains seems always be zero or nearly zero
- BaseGain, CurrentGain and OldGain must always be 1 IF MAPTPSCorrection function has been zeroed out => you can play with differently weighted average of the two most recent MAF readings and previous DynamicAirflow

I tried values from LS9 and ended up having Dynamic Airflow at permanently higher level than MAF reading, hence the above "rule".
I'll have to check whether the car was in hybrid mode (MAF + VE) during that (accidental) test, but earlier when in pure MAF mode it didn't seem to respond to these changes at all.

However depending on the application, there are quite a few differences between them
- there are areas in LS7 where MAP + TPS gains has been zeroed (cells 2 & 3 which activate when leaving from idle)
- LS9 seems to disable all MAP + TPS gains BUT values of BaseGain, CurrentGain, OldGain don't sum up to 1, also CorrectedGain is set differently (the function at the top this post might be different or not correct at all)
- LS2 (E40) seems to disable either MAP + TPS or only MAP on some cells
- LS3 seems to use only BaseGain and CurrentGain, OldGain is zeroed out as are MAP and TPS gains

More testing is needed to see how they work (or do they work at all) in practice.
According my experiences the "raw" MAF seems to be much smoother than DynAir especially when engine is showing bucking or "misfire like" tendencies using OEM coefficients with moderate (18 deg overlap @ 0.05" lift) cams.

I agree on the premise of the sum of main tables should be equal to 1. That just makes sense on how you'd think it should work and most stock calibrations follow that logic. But with my testing of when they don't work right, there is more to it somewhere or one hell of an os bug. My settings I use on everything is Base:0.9 / Current:0.1 / Old:0.0. That seems to be the tried and tru in most stock cals and the most reliable for me. The muddy water for me is the Corrected table. Most stock cal that follow the above numbers have it set to 0.5. I have found that high numbers make the problems I see in boost less pronounced but not necessarily cured. But also seem to have an effect on how the MAF is filtered, even after the high rpm disable. So my base tables I start with have cells for high load / low rpm with number like 0.9 and tapper back to 0.5 by higher rpms. But I always feel like I'm plugging in the dark when trying to quantify results. I hate not knowing how something so crucial works. It is #2 on my cringe list right next to the GenIV ecm hot reflash injector offset issue.

[barum]

Yes, the Corrected table is truly muddy waters and like you, I too have begin to suspect we're not seeing all tables/parameters that are part of this prediction algorithm.

Regarding the "hot reflash" issue, is it the same as "rich after flash" issue? Maybe a stupid question, but since terminology is less formal here...

If so 2006 E38 seems to behave bit differently than what most describe. After reflash it seems CL activates regardless of the ECT setting and activation only seems to follow the delay table.
As a result commanded AFR is following OL tables, but according to CL status bit and WBo2 it definitely is in CL. The difference shows in STFT until LTFT enable ECT has been reached resulting in normal state.
It doesn't take 10 minutes, just that that LTFT learn is enabled meaning it can go over very quickly depending on the ECT.

Anyway, due to SD behaving a bit better with reversion seen on ~stage 3 and above cams it would be nice to enable MAF/hydrid mode after certain rpm or airmass and use only VE table below that point.

I even tried some FFT analysis to find out if there's correlation between rpm fluctuations, CL oscillation, ignition advance changes, injector PW, TPS position or MAP reading. Yes, with 50 ms logging interval you can theoretically get up to 10 Hz without aliasing but maybe 5..6 Hz is more realistic limit. Some (inconclusive) results below.

0.5 and/or 1 Hz missing/slight bucking can be felt, these are signals which had the highest correlation (some naturally so).
Yes, it can be 1 Hz is just a multiple of 0.5 Hz.



Here's the correlation of ignition advance and calculated AFR to rpm

[GHuggins]

So, would one be better off to zero these out with a bigger engine build or just increase them up into the .9 ranges as bluecat does? I've currently got one going lean getting into boost because of this and was just wondering. AND if you do zero them out, is there anything else that has to be changed to keep things from going screwy? I think these were talked about in another thread not that long ago and someone mentioned (DStek maybe) that something else had to be changed?

[seven ends]

So, would one be better off to zero these out with a bigger engine build or just increase them up into the .9 ranges as bluecat does? I've currently got one going lean getting into boost because of this and was just wondering. AND if you do zero them out, is there anything else that has to be changed to keep things from going screwy? I think these were talked about in another thread not that long ago and someone mentioned (DStek maybe) that something else had to be changed?

I think you are referencing the prediction coefficients and burst knock table relationship that was brought up in the previous thread. I zero'd out both mine based on that thread.

[barum]

Results from the test run, 2006 E38 custom OS in hybrid mode (VE-table in use up to 4000 rpm).

Coefficients set as follows across the tables:
DynamicAirflowBaseGain = 0.30
DynamicAirflowCurrentGain = 0.50
DynamicAirflowOldGain = 0.20
DynamicAirflowCorrectedGain = 0.0
MAP + TPS gains zeroed out

MAF + DynAir as logged, calculated DynAir with above coefficients:



MAF + DynAir as logged, calculated DynAir with default 2006 LS7 coefficients:



Conclusion: Change of coefficients had no effect on DynAir calculation => are there duplicate tables not shown in the editor or how else can this be explaned?

If anyone wants to try, just log MAF + DynAir, post log + used & oem coefficients here. I can make the above comparison and post results here.
Note that
- LS3 (and LS9) coefficients have very small effect compared to LS7 coefficients => can hardly be seen even in the theoretical calculation
- MAF needs to be in operation

[redhardsupra]

@Barum, which value are you using for TPS? There's a lot of them to choose from on ETC cars (which is just about anything these days). This would definitely contribute to the imprecisions if you're feeding it wrong series of data.

Also, one thing that always bugged me with all the time-based estimators, is that when we see somevalue[t-1] we can only take the previous LOGGED value, not the value that actually was there on the last fueling calculation. So we are effectively using wrong data, and the only time when we can get away with it is when the values don't change much ('cuz then values for [t-10] and [t-2] might be close enough). However, for situations like this, when we're chasing after engine data during transitions, then this becomes an obvious problem. I'm imagine this is gonna get ever worse when you got [t-1] and [t-2]...

If you want to see it for yourself, run the same scan/calculations with different amount of PIDs logging, just enough that the logger will record data with different frequency. I spent months chasing my tail with this when I was playing with the Manifold Temp estimator, as the bias tables take 'previous' input into consideration. I never quite found a way around this, short of mathematically ignoring the 'old' values with weights of 0. Maybe the newer ECUs with increased scan rates and some minimization efforts on the scan table to improve the scan frequency we can get closer to the real values, but even then, I doubt this is something that is solvable with the data we can gather.

PS. This thread is officially rated AWESOME

[barum]

Yes, I agree with everything you said.

I used the "Throttle position (SAE)" value for TPS. I haven't tested from which ETC related PIDs it is derived from, but to my understanding it represents the actual throttle blade position, naturally with some filtering.

It's more of a rule than an exception that you get samples at much lower (and at asynchronous) rate than the microcontroller/plc/cpu executes the main control loop. With this in mind, I tried to keep everything as simple as possible and started by ignoring the MAP and TPS parts of the algorithm. Since the most simple function seemed to correspond amazingly well (in various transitions) with the DynAir calculated by the ecm and my goal was only to achieve stronger filtering in order to be able to keep using hybrid mode with moderate cams, I didn't see a need to pursue it any further.

As a side note, Katech seems to have tuned their K501 cam to behave very well, at least judging by their youtube videos. I would love to take a peak to see what tricks they have come up with.

This "reverse engineering" we have to do is very time consuming given the fact that the editor shows only part of the parameters. It would be nice if HPT had a SETI type of an approach where they could give parts of the disassembly to be "cracked open" by volunteers or you could ask for a part of the code to dig deeper for the common good. Yeah, keep dreaming...

[redhardsupra]

I would test with the effective TB position, whatever the actual PID is actually called, not the raw inputs, but the post-modifiers/smoothers/filters. I think the regular TPS on a ETC car tops out at 88%, which is clearly not right. (unless Chris can chime in with the equation reflecting code in the ECU that tells us otherwise)

You can glean information by back-calculating estimators from raw inputs using 'this ought to work like this' equations, and see how they compare with the scannable version. I've reversed a lot of stuff this way, the only ones I couldn't were the ones that had the time-based inputs, for the aforementioned reasons.

I was going to suggest eliminating the time-based portions of the estimators, and see how it runs without them, but it sounds like you've already done that.
I would set up all the weights that influence MAPTPSCorrection so the result is 0. Sounds like you already did that too...
So the only thing that's left then is calibrationion for the weighs of the older DynAir.

One thing is missing though: where are the Speed Density derived airflow numbers coming in (besides being indirectly baked into the previous DynAir calcs)?

[LSxpwrdZ]

Are you saying you had tuned VVE tables in SD mode purely, then enabled MAF got trims right, but when it was using blended version of both at certain times it was out in left field James?

Yes. Zeroing the prediction coefficients solves this but I would still like to know or have an understanding of what these tables do.

[redhardsupra]

We know what they do, they weigh the different reaction of airflow to MAP and throttle changes, per VE zone. This estimate model establishes few things:
1. MAF is primary source of airflow
2. SD is a very useful backup source of airflow
3. sometimes we need both
4. sometimes both are kinda off, so we must ignore them, and go on recent airflow numbers
5. when they're both off, we can ballpark airflow based on a per-zone response surface built out of TPS, MAP, and their coeefs.

This is why people mentioned how going FI makes the hybrid airflow estimator flake out; when normally around 95+kPa MAP in NA car you dont get much more air than before, it's fairly easy to predict. Same scenario in a FI yields a huge increase in airflow, making all the unaltered, suitable-for-NA numbers produce garbage values. Plus if one of your inputs is MAP, and those 'outer' zones' were intended to really go to 103kPa, and now you're actually feeding it 180kPa, the response surface that was not intended for >103kPa, will most likely yield ridiculous values.

The math and the human observed behaviors make a lot of sense when put together.

[Higgs Boson]

For me these tables are getting 0'd or left stock, there's no chance of successfully altering with any processing power available in my brain....

which would you recommend for a boosted LT1?

[DSteck]

I zero them out, disable burst knock, and move on. Time isn't something I have to dedicate to figuring it out, and the GM documents I have don't mention how the prediction coefficients are determined.