-
The correction multipliers would be:
MAF multiplier (corrects MAF table from VE table):
GM.DYNCYLAIR.DMA/GM.CYLAIR.DMA
VE multiplier (corrects VE from MAF table):
GM.CYLAIR.DMA/GM.DYNCYLAIR.DMA
i.e. you would be using one or the other, not both at the same time.
-
Joe, per previous conversation I think your concept of SD Vs MAF Airflow correction being similar to ASpark is probably correct..I.E. Scaler percentage.
My unproven theory is that it uses a percentage similar to the 'Charge Temperature Blending' formula. We know that by 4000 Rpms, the VE Table influence is 0%..we just don't know the values 'in-between'. See by the time you hit 150 g/s you are probably near or above 4000 Rpms..
The reason this is important and also pertinent to the thread, is that it would be inherently easier to correct a MAF/VE Table using Airflow Values than pure BENS or perhaps even the DYNAIRTMP.DMA Pid..
Something to think about..:grin:.
-
The calculated MAF pids look good, the non-corrected values are very close... with MAF disabled the corrected values would converge.
Interesting, look at MAF and DYNAIR :cheers:
Yes, we'll clean up and simplify the calc_pids.txt file.
-
Yea..I see that. It 'smooths MAF Airflow or is filtering/averaging?
So are you thinking we can just use DYNAIR?
The only deviation I see MAF vs DYNAIR is letting off throttle.
Frame 20097 (cursor)..MAF: 59.17 g/s
DYNAIR: 253.73 g/s
I assume we are not lagging by a frame (latest software build).
If valid, it is implying MAF Airflow is changing faster than MAP referenced Air???
-
We will have to filter out transients, but yes it looks like we can use DYNAIR... let's take a few more logs first.
I don't think the lag is due to the pid evaluation order... there are other transitions where there is no lag.
Is MAF changing ahead of MAP derived airflow...? IDK... may be yes and/or no.
-
There is enough data there to blow one's mind. Best advice I can give is to load up every possible calculated Pid, log it, and study it.
So far my analysis, is that if you are purely talking CALC.VET in reverse, its easiest to do the VE Lookup Table Value concept (your first calc_pids.txt).
Both the DYNAIR and DYNCYLAIR.DMA (g/s conversion) appear to average or 'lag' their calculation. Ironically, fueling (AFR/EQ) follows the Air Pids perfectly..:grin:.
I agree..More logs before reaching final conclusions..
-
Simon, there's two (significant) wrinkles to your scheme:
1. airflow is based on air charge temp, which depends on bias, which depends on airflow--the sort of relationship that gives psychotic calculus teachers a mental boner. The best way around it I found is to assume that the estimated airflow DMA is close enough, and that due to the nature of the underlying function behind bias, small imprecisions in the estimated airflow wont make that much of an impact on the resulting bias, and thus airflow. So I use that to calc bias, then use bias to do temp, and then airmass/airflow. It's not perfect, but it works very well, comparatively to the other errors involved (especially on the fuel side, without us having a full fuel mass model and the full data set that it requires).
2. If you can solve for temp, you could solve for bias, which would be hugely useful. However, if you're trying to solve for VE/GMVE, and BIAS at the same time, you end up with one equation and two unknowns. Not exactly pretty to solve, especially on the newer ECU's where you got speed in the mix to make BIAS is a 3d function, and then you go the lag filter table that works on some unknown time unit, making it a bloody nightmare. It is doable tho, just fugly.
One experiment I've been trying to get to for years but haven't yet, is using the airflow equations for MAF and SD as each other's constraints. Let me explain: MAF is a smooth 3rd order poly. GMVE is a (mostly) smooth quadratic surface. So I think you could solve for either's MAF's poly cooefficients using GMVE surface parameters as a constraint, or vice versa. Or maybe treat them as simultaneous equations, with airflow/airmass as the common term? Or maybe just set the two airmass models equal to each other, and do an optimization minimizing the sum of error square, using AFRwb and AFRcommanded as the terms to compare? So many (horribly time consuming) ideas, so little time....
If you really want to get insight into the dichotomy between MAF and SD, generate their airmass estimations, and plot them against each other. Then do a residual analysis, and try to pinpoint for which conditions for which the big residuals happen, and you will learn why the formula that weighs MAF/SD's inputs in the hybrid model is the way it is... ;)
-
For what it is worth..
Looks like a slight difference in DYNCYLAIR.DMA (g/s) vs DYNAIR (g/s) (MAFN3).
My assumption is that the DMA pid may have more sophisticated temperature corrections than DYNAIR alone???
-
different PIDs are going to use different smoothing of component PIDs, so expect slight discrepancies, especially on transients.
also, you really need to stop looking at it as time series, and look at them as populations in scatterplots--WAY more telling of what's going on.
-
As far as this technique (CALC.VET in Reverse or CALC.MAFT), for now I am sticking with Joecar's original suggestion to utilize the VE Table Look-Up and DYNAIRTMP.DMA Pid. It is essentially the CALC.VET formula in reverse and an user can simultaneously log Trims, and MAF Airflow in one log.
Page 1 of this thread has been updated: http://forum.efilive.com/showthread....l=1#post145857