CALC.PID for simultaneous MAF & VE Calibration - need sanity check

[Gelf VXR]

I decided to create a calc pid that will let me calibrate MAF and VE table in one log using wide band, stft & ltfts. It must be more accurate to calibrate MAF and VE table from the same log data to get them to match, IMHO.

I need to get the math right in my head, here goes

Log all the usual pids asscociated with MAF, VE and trims.

Maps are MAP vs RPM as used in VE table, except for MAF cal.

Create map for BEN1 (GM.AIRPERSEC is PCM g/sec value) for refference

Create a pid for the map (BEN1 * GM.AIRPERSEC)/SAE.MAF gives BEN M correction for MAF.

Create a pid for the map (BEN1 * GM.AIRPERSEC)/GM.DYNAIR_LS2) gives BEN D correction for VE table.

How ever fuel trims have not been factored in...

Create a pid for the map (STFT1+LTFT1) = % TRIM

The math

For an example, (and we see that the GM.AIRPERSEC = GM.DYNAIR (The higher value of MAF & VE CALC, it could be vise versa))

BEN1 for GM.AIRPERSEC = 1.04

BEN M for SAE. MAF = 1.02 MAF is reading 2% lean

BEN D for GM.DYNAIR = 1.04 VE TABLE is reading 4% lean

How ever, for the example BEN D for VE table = 1.04, the combined fuel trims of STFT & LTFT is say 1%, this is where i need a sanity check with the calc.pid

The 1% fuel trims have been added and calculated for the BEN1 for GM.AIRPERSEC = 1.04, I need to still compensate for the 1% fuel trim, ie the BEN D should be 1.04 + 0.01 = 1.05 for the VE table calibration, and BEN M should be 1.02 + 0.01 = 1.03 for the MAF calibration.


My calc.pids

*CLC-00-900
cylair 0.0 1.5 .2 "{SAE.MAF.gps}*15/{SAE.RPM}"# ================================================== ============================
# File details
# ------------
#
# This section defines various details about the file format.

*FILE

#Parameter Value Description
#---------- ---------------- ---------------------------------------------------
VERSION 7.1.1 File version
DECSEP . Decimal separator used in this file



# ================================================== ============================
# Units
# -------------------
# See sae_generic.txt for more information on the *UNITS section

*UNITS

#Code System Abbr Description
#-------- ---------- -------- -------------------------------------------------------------

None None "" "No units"


# ================================================== ============================
# Add slot definitions here
# --------------------------------
# See sae_generic.txt for more information on "SLOT" formats
#
#Units Low High Fmt Expression
#------------ ------------- ------------- ---- --------------------------------------------------------------
*CLC-00-001
% -40 40 .2 "{SAE.SHRTFT1}+{SAE.LONGFT1}"
*CLC-00-002
% -40 40 .2 "{SAE.SHRTFT2}+{SAE.LONGFT2}"
*CLC-00-003
% -40 40 .2 "({SAE.SHRTFT1}+{SAE.LONGFT1}+{SAE.SHRTFT2}+{SAE.LO NGFT2})/2"
*CLC-00-004(
factor 0 2 .2 "(((({GM.AIRPERSEC}*{CALC.BEN1_B})/{SAE.MAF})*100)+{CALC.TRIMS1})/100"
*CLC-00-005
factor 0 2 .2 "(((({GM.AIRPERSEC}*{CALC.BEN1_B})/{GM.DYNAIR_LS2})*100)+{CALC.TRIMS1})/100"
# ================================================== ============================
*PRN - Parameter Reference Numbers
# --------------------------------
# See sae_generic.txt for more information on the *PRN section
#
#Code PRN SLOT Units System Description
#------------------------- ---- ------------ ---------------- ---------------- ------------------------------------------
CALC.TRIMS1 F001 CLC-00-001 % Tuning "ST1 & LTFT1 COMB"
CALC.TRIMS2 F002 CLC-00-002 % Tuning "ST2 & LTFT2 COMB"
CALC.ST_LT_AVE F003 CLC-00-003 % Tuning "ST1&2 & LTFT1&2 AVERAGE"
CALC.MAF_BEN1 F004 CLC-00-004 factor Tuning "MAF BEN1 FROM AIRPERSEC AND TRIMS1"
CALC.DYNAIR_BEN1 F005 CLC-00-005 factor Tuning "DYNAIR BEN1 FROM AIRPERSEC AND TRIMS1"

You can see from the attachments that I have applied this calc pid to, that the MAF BEN map why the PCM uses dynamic fueling at lower rpm’s, its way off..

[Gelf VXR]

additional screen shots

[swingtan]

The biggest problem you will have is knowing what is influencing the final airflow figure for fueling. When running both the MAF and the VE ( IE, below the High Speed Air Flow threshold - 4000 rpm ) I don't think anyone has a complete understanding of the roll that both the MAF and VE table play. The MAF is the primary measurement, but...

does the VE act as a correction factor or a plain sanity check?
How much difference does there need to be between the MAF and the VE before any "correction" is performed?


This will make using a single log difficult to tune both the MAF and the VE because it will be difficult to tell if the MAF or the VE needs the correction.

Here's the good news though...

What you would need to do is to alter the HSAF point to be below the normal running RPM, say 400rpm. This puts you in MAF only mode and bypasses the VE corrections. Then zero all LTFT and start logging all parameters.

If you log MAP, RPM, MAF ( FREQ and gm/Sec ), gm/Cyl then create a calc PID for gm/Sec ( taken from RPM and gm/Cyl ), you can create a BEN type MAP from the MAF gm/Sec and the Calculated gm/Sec. Then get the MAF dialed in accurately so you know it's "correct". Now, remember that the gm/Cyl PID is based from the VE table, so this will allow you to correct the VE while still running the MAF. Of course, to do this you will need to ensure the fueling with the MAF is pretty close to start with.

The thing is, that you will always need to reference any correction procedure, to get an accurate result. You can't correct 2 separate parameters with the same data if the variables between them change ( which in this case they do ).

Simon.

[Gelf VXR]

The biggest problem you will have is knowing what is influencing the final airflow figure for fueling. When running both the MAF and the VE ( IE, below the High Speed Air Flow threshold - 4000 rpm ) I don't think anyone has a complete understanding of the roll that both the MAF and VE table play. The MAF is the primary measurement, but...

does the VE act as a correction factor or a plain sanity check?
How much difference does there need to be between the MAF and the VE before any "correction" is performed?


This will make using a single log difficult to tune both the MAF and the VE because it will be difficult to tell if the MAF or the VE needs the correction.


Simon.


Hi Simon

I'm not sure that I need to know how the PCM calculated the final g/sec value as long as I know what the final value is, which I am pretty certain is the GM.AIRPERSEC pid.

My above calculations are incorrect, I need correct the AIRPERSEC pid by the combined ST&LT trims to arive at 14.7:1 RATIO when commanded AFR =14.7/1. If the fuel trim is -4%, the g/sec needs to be increased by 4% to correct.

(100+(-4))/100= 0.96

GM.AIRPERSEC/0.96 = Corrected AIRPERSEC

I want the DYNAIR and the MAF g/sec to agree with the PCM (AIRPERSEC) g/sec value, so

The corrected GM.AIRPERSEC divided by GM.DYNAIR to arrive at correction factor for VE table.

The corrected GM.AIRPERSEC divided by SAE.MAF to arrive at correction factor for the MAF table.

Ive just logged 2 and half MB of data and will apply the correction factors as described, re log and see if the GM.AIRPERSEC, GM.DYNAIR and SAE.MAF values come even closer together. I will post my findings.

All the above assumes that the injector flow rate is correct (GM LS7 values for GM 42lb/hr injectors), for which the g/sec pids are calibrated to.

[WeathermanShawn]

Hi Simon

I'm not sure that I need to know how the PCM calculated the final g/sec value as long as I know what the final value is, which I am pretty certain is the GM.AIRPERSEC pid.



Good luck if you can really compute each airflow contribution. You would get the tuning equivalent of the 'Nobel' Prize of scientific accomplishment.

The problem is in your assumptions. It could just be that in a MAF-enabled vehicle the airflow calculations for Trims my be all CYLAIR (my long-standing hypothesis). For example on a LS1, Spark appears to follow CYLAIR 100% (MAF-enabled). Airflow corrections from DYNCYLAIR do not seem to effect spark load. Perhaps closed-loop on MAF cars is also 100% CYLAIR.

I will be interested to see if your calculations can withstand scientific scrutiny. So, far my observations have been all anecdotal. My hypothesis has been that in a MAF-enabled vehicle, the MAF controls almost (if not 100%) of the closed-loop Trimming along with spark. The brief contribution of airflow correction from DYNCYLAIR last for about 1/2 second..then the airflow and fueling goes back to being controlled from the MAF. Thats not long enough to change the LTFT filter sequence..hence the MAF controls a whole lot more than given credit.

On my end I can't get it into a mathematical expression. If you do, it will be the first person to have ever done it. I would just question your assumptions. You might be using the end results thinking you are getting success, but how are you going to prove it. You might just be manipulating the end result to match your assumption. And how do you know if it is correct?

I respect your pursuit. I am just respectfully skeptical..:grin:

[Gelf VXR]

I know my assumptions my be wrong, but when performing autove, airpersec tracks dynair, the maf pid is still logged althought disabled. When performing maf cal, airpersec tracks maf pid, the dynair is still logged but ignored. When in cl, airpersec tracks the higher value of the two, so it stands to reason that airpersec is the g/sec value derived between the other two. Time and a few logs will tell :)

[Gelf VXR]

My pursuit is that all three pids are within a percent of each other

[WeathermanShawn]

When in cl, airpersec tracks the higher value of the two, so it stands to reason that airpersec is the g/cyl value derived between the other two. Time and a few logs will tell :)

Gelf..thats my main concern. Your making a very 'risky' assumption. It may not be derived at all between the two. How will you be able to make that legitimate interpretation?

Again, I appreciate you taking the effort. I am rooting that you can crack the equations, but don't you actually need to evaluate the computer code to know how the PCM then uses the airflow corrections? What if it ignores the first two airflow corrections, and then takes the third correction (as an average). How would logging reveal that?

Food for thought. This has been a long-standing pursuit. Again, good luck.

[Gelf VXR]

If I can get all three g/sec pids to agree with zero % trims, (positive on the lean bank) I will have achieved my objective. I'm not to worried about the internal calcs as long as the end result is as desired :)

I'll update on my progress..

[joecar]

You could try to correct the MAF just with a ben based on trims.

And you can calculate the per cylinder VE as follows and apply the same trim-based ben to it:
VE[g*K/kPa] = MAF[g/s] * DAT[K] * 120[s*rev/min] / RPM[rev/min] / MAP[kPa] / N[cyl]

where DAT = dynamic air temperature (blend of IAT and ECT)

[ i.e. in a similar manner to Shawn's LS1 calculated VE tutorial ]


I'm not too familiar with E40... on www.holdencrazy.com (http://www.holdencrazy.com) which year/models are E40 (are all the LS2's E40's)...?

I do not know what AIRPERSEC is derived from, when I think I might know then I see something that indicates otherwise.

[WeathermanShawn]

Somewhere ( I can't find the post) 5.7ute (Mick) had a premise to develop a Calculated Pid that showed just the Airflow Correction that was being applied.

You have CYLAIR, DYNCYLAIR and a great pid would be 'Airflow Correction'. I remember Mick attempted to use IBPW, airmass, and other pertinent terms. Of course the math would be challenging. But ultimately we probably could compute it by looking at how the IBPW changes as DYNCYLAIR and CYLAIR change.

Now how do you that? I guess I am still skeptical until I see the process played out. You can get a valid end result, but it won't stand up in testing unless you can spell out how you got there...:)

[Gelf VXR]

where DAT = dynamic air temperature (blend of IAT and ECT)

.

Hi Jo, ther is no charge blend pid for the e40, not that I have come across :(


E40 was around 2005 for pontiac gto and Holden/vauxhall monaro's

[joecar]

Hi Gelf,

Post your .tun file... it may be possible to make a calc pid using the lookup() function... (this is what is being done with the LS1A 1997/1998 PCM since they don't have that pid either).

[Gelf VXR]

E40 stock tune file attached.

[joecar]

I'm going to look at the E40 file more tonight... :)

[Gelf VXR]

I think I'm ready to declare sucess, well better results than I've personally seen from seperate autove and MAF calibration.

Short log attached, I have a long trip to the coast planned to log this weekend for making further refinement.

To clarify, I am calibrating VE table and MAF from the single log file, I am tuning VE and MAF to the richer of either bank for a given cell (one bank is lean at lower cells while the other is lean at higher cells.

I am correcting the GM.AIRPERSEC pid using a CALC pid (attached) that uses fuel trims and BEN from wide band, if the trims are adding 4% and BEN is 0.99, then 3% is the correction factor. I then the divide the seperate values for left and right bank by the DYNAIR and MAF pids to obtain the correction factor for those pids to align with the AIRPERSEC pid, I enter these results into a spread sheet that takes the lower values from the left or right bank to create a single correction tables for the VE and MAF calibrations. I have applied these at multiply by 50% in the tune tool, which means subsequent logs and applications should close further to the desired results.

The results although not perfect, are very encouraging close to zero trims on which ever happens to be the rich bank at the time and positive on the lean bank.

If you play bank my log, you can observe that all three g/sec pids have converged.

If you check the LTFT attachments you can flick between the two and see that one or the other is close to zero, or equal distant neg or pos from zero.

This is now my preffered and simple method for tuning :cool:

I have attached my filters i used to obtain the results.

Update: Forgot to mention I have enabled dynamic fueling to the red line.

[Gelf VXR]

Condensed graph of the log attached showing the three g/sec pids and combined ST & LT fuel trims

[WeathermanShawn]

Mmm. Still not sure I follow.

If you are MAF-Enabled, how do you know that all the work you have done could simply have been done directly through the MAF. I.E., MAF controls Closed-Loop Trims.

I guess I will keep an open mind. When I tested the CALC. VE Table for LS1's, the only way I could prove it was to fail the MAF and then apply the equations/Trims.

Have you done the same, or am I just missing the premise?

In any case, good work. We need more methods for other OS's.

[Gelf VXR]

Mmm. Still not sure I follow.

If you are MAF-Enabled, how do you know that all the work you have done could simply have been done directly through the MAF. I.E., MAF controls Closed-Loop Trims.

I guess I will keep an open mind. When I tested the CALC. VE Table for LS1's, the only way I could prove it was to fail the MAF and then apply the equations/Trims.

Have you done the same, or am I just missing the premise?

In any case, good work. We need more methods for other OS's.

The main objective was to have the MAF, VE and any other g/sec agree on the value, which they now closely do, the fuel trims then apply equally to all three pids.

When I performed seperate autove and maf, they never agreed entirely which left the unanswered question, which pid do the fuel trims apply to.

[WeathermanShawn]

Gelf:

You see thats the conundrum. It looks correct, but you have to see if it is correct for all circumstances.

I.E., what if a tuner's MAF fails on the road. Will it still be valid? In my case, I did 3 tests.

1. Add 15% to all VE Table values and log Trims & Airflow.
2. Subtract 15% to all VE Table values and log Trims & Airflow.
3. +/- 15% to the MAF Table. Log Trims and Airflow values.

For the LS1, Trims followed the MAF Calibration to the greatest degree. But, you have to have it work if the MAF fails. It does happen, and only then can you really be sure.

Still, good work. I am just saying it may not be as easy as the results show. Perhaps I am wrong though. I will keep an open mind..:)

[Gelf VXR]

Gelf:

You see thats the conundrum. It looks correct, but you have to see if it is correct for all circumstances.

I.E., what if a tuner's MAF fails on the road. Will it still be valid?

But thats exactly what I have done, the MAF and VE table were calibrated together and agree across the calibration, if the maf fails the ve table was spot on with the maf, so there should be no issue.

[WeathermanShawn]

But thats exactly what I have done, the MAF and VE table were calibrated together and agree across the calibration, if the maf fails the ve table was spot on with the maf, so there should be no issue.

Your making my point. The VE Table was done with the MAF. What it looks like when the MAF fails is the true test. What does the VE Table look like in terms of airflow and Trims without the MAF tuned simultaneously. If one MAF fails, what will there Trims look like.

I have the results for the LS1, and they are far different than one would imagine. Perhaps its different for your OS. And, its possible I am missing your point..or vice versa:)..

[joecar]

So, AIRPERSEC is s dynamic blend of MAF and VE...?

[Gelf VXR]

Yes :) that's what I have been saying all along, AIRPERSEC tracks the higher of either MAF or DYNAIR (not to be confused with the PCM internal dynamic air calculation). I am calibrating maf and ve to the trims and ben corrected PCM dynamic air calculation. Because the data is all from one log of the exact same road conditions, the maf and ve calibrations are much closer than they would be from calibrating from two seperate logs with differing road conditions.

If I were a proffesional tuner I'd use a chassis dyno to calibrate individually because I'd be calibrating in a controlled enviroment, I could recreate the same conditions time and time again. But I'm not, I need a method for calibrating on the road, ve and maf must be calibrated to the flow rate of the fuel infector flow rate calibration at the same time. The fuel injector flow rate is the only constant.

This is method for on the road tuning, not a replacement for a proffesional chassis dyno tune :)

[WeathermanShawn]

Maybe I just don't understand E40 enough to really comment.

If your peers agree that it can be readily duplicated, then I would work on helping others understand your process.

I still would like to see a log where the MAF is entirely failed and how it then influences the VE Table and Trims. If it works, it can be easily duplicated (science).

I take it E40 still involves transient/dynamic fueling. Thats why I keep saying to test it with the MAF failed. Does E40 use any charge temperature computation in its fueling?

Don't misunderstand. I would love to see more people get involved in tuning differing OS's. I am just curious what the rest of the E40 crowd thinks. Is there an airflow blend that is not being modeled correctly here, or does this have merit?

Respectfully..

[Gelf VXR]

Maybe I just don't understand E40 enough to really comment.

If your peers agree that it can be readily duplicated, then I would work on helping others understand your process.

I still would like to see a log where the MAF is entirely failed and how it then influences the VE Table and Trims. If it works, it can be easily duplicated (science).

I take it E40 still involves transient/dynamic fueling. Thats why I keep saying to test it with the MAF failed. Does E40 use any charge temperature computation in its fueling?

Don't misunderstand. I would love to see more people get involved in tuning differing OS's. I am just curious what the rest of the E40 crowd thinks. Is there an airflow blend that is not being modeled correctly here, or does this have merit?

Respectfully..

:) I enjoy constructive debate, to answer your question, yes the E40 does and I am tuning transient dynamic fueling, the gm ve table is calculated at absolute zero, calibrating it and maf to the calculated dynamic value negates the need to know the charge temp calculation.

I dont think that the E40 is a common PCM, I am quite happy for any one to send me a 3mb plus log with all the pids or equiverlant pids that I attached in my early post, along with their current tune file, to be returned and relogged, so I can try to validate the process in another OS,

[joecar]

E40 is a bit of a learning curve for me, the pids are different, and I don't have one that I can play with... I did have an x4 cam sprocket laying around tho... :hihi:

[Gelf VXR]

This evenings log after applying my updates to calibrations show LTFTs coming along very nicley:rockon:

8385
8386

Now that I feel I have ve & maf, and thus my afr's under control my thoughts now turning towards spark advance again, LTFTs are quite sensitive to changes, I tried prior to this log shifting all the hi octane values one cell to the right, LTFTs went noticably negative, in that I stoped after a few miles and reversed back to previous setting. However I read with interest this article, which the tuner commands 22 degrees at peak torque and 27 degrees at peak bhp. I'm seeing around 22 at peak torque but no where near 27 at peak bhp? My focus next I think will be a adjusting spark in the WOT cells above peak torque, up in small increments and note whether the trims go negative/posive (negative = reduce spark / positive = add spark), and look out for knock of course.

Source http://www.gmhightechperformance.com/tech/0702gm_2005_pontiac_gto/page_7.html

"Jim Moran will be handling the dyno tuning for our '05 GTO. "Unlike LS1s, LS2s seem to like a little more fuel on the top end," Jim explains. He starts out by increasing the idle speed, along with the startup and base airflow tables. The rev limiter is raised to 7,000 rpm, catalytic overtemp is disabled and the power enrichment eq. ratio is initially set at 1.18. Then Jim moves on to the main spark table and brings WOT timing to 22 degrees at peak torque, and 27 degrees at peak horsepower, blending into the surrounding cells. Timing at idle is also increased to the 24-27degree range. The PE spark advance correction table is zeroed out and the IAT spark advance correction table is adjusted to be less aggressive. Cat lightoff spark is also zeroed out. After that, torque management is reduced or removed along with skip shift, cooling fan duty cycle is increased and the car is ready to be started and brought up to temperature. Once it is in closed loop, Moran monitors the fuel trims and makes adjustments to bring them slightly negative. At that point the Goat is ready for a WOT pull, and the air/fuel ratio will be monitored/adjusted--so will the timing table if there are any areas that are getting knock retard. Once the tune is zeroed in (and if we had an auto), he would set the shift points on the dyno."

[ACCLR8N]

Well I decided to muddy up this old thread than start a new one:

In the Calc_pids file the very first line looks like a piece of a formula. I left this out. Then there is an undefined Calc.BEN_B variable. Is this a wideband factor? I replaced it with a new variable (CALC.WO2BEN) that is "{EXT.WO2LAM1}/{SAE.LAMBDA}" that I copied from my failed CALC.VET attempts.
Was that very first line supposed to do something?
Is CALC.BEN_B a wideband factor?

[joecar]

Well I decided to muddy up this old thread than start a new one:

In the Calc_pids file the very first line looks like a piece of a formula. I left this out. Then there is an undefined Calc.BEN_B variable. Is this a wideband factor? I replaced it with a new variable (CALC.WO2BEN) that is "{EXT.WO2LAM1}/{SAE.LAMBDA}" that I copied from my failed CALC.VET attempts.
Was that very first line supposed to do something?
Is CALC.BEN_B a wideband factor?
Yes, CALC.BEN_B is the wideband correction... BUT, we have long since refined the process and replaced that pid with CALC.WO2BEN

please see post #1 here: Calc-VET-correcting-MAF-and-calculating-VE-(in-single-log) (http://forum.efilive.com/showthread.php?15236-Calc-VET-correcting-MAF-and-calculating-VE-(in-single-log))

use that thread (and the calc_pids.txt from it) and modify for your ECM's pids (which seems to be what you're doing);

post your calc_pids.txt file so I can see what you got;

what year/model/vehicle/ECM...?


:cheers:

[ACCLR8N]

2005/Pontiac/GTO/E40

I tried the Calc.VET method. It gave me a good low VE MAF tune. When I got into boost and PE it was too lean. When I tested open loop SD I found my resulting Main VE table was way to lean. I decided to try this method as the only one specific to the E40 I've found. Attached are both calc_pids renamed accordingly.

Thanks for having a look.

[joecar]

Did you use CALC.VET.% or CALC.VET.VE(g*K/kPa)...?

[ACCLR8N]

My VE tables are in g*K/kPa and I was overwriting with the values from my CALC.VET variable. Those were % corrections? My MAP parameter says "(0) Calculated VE, BEN corrected (g*K/kPa)". Are you seeing what I did wrong?

[joecar]

Overwriting (as you did) is correct

CALC.VET.% is not a correction factor, it is an absolute value in units of % (wrt to 100% cylinder fill).

I don't see yet what is going wrong...


Can you post your tune file and log file (and calc_pids.txt again).

[ACCLR8N]

I would love to have you look at my tune file. From when I was trying to get the other Calc.VET to work correct? I know what's wrong: it's the keyboard steering wheel interface.

Attached is a log from my _0041 tune, the _0042 tune and a log from it. I reattached my saved copy of the calc_pid I used for these runs. This tune I didn't do any smoothing as you will see.

The next couple of tunes I was adding MAF back in above 7000Hz 115% at a time. Then I failed the MAF to check VE and the car was so lean it would hardly run. I gave up and started looking at the method in this thread.

Appreciate your help and any suggestions.

[ACCLR8N]

B0104 I was searching some other threads and I was reminded that the cylinder volume appears to be set low from the factory 708cc. Shouldn't it be 745cc for the 6.0L (5964cc) V8? I have reviewed several others and they all have the same 708cc setting. Could this be throwing off the math?

Why can't I find the DYNAIR_LS2 pid on my V2 for BBX logging? (edit: Found it. MAFSD in V8)

I have the black box logging configured now and tested out the formulas are returning sane values. I'll get a good log tomorrow on the way to work and try out GELF's method.

[Gelf VXR]

B0104 I was searching some other threads and I was reminded that the cylinder volume appears to be set low from the factory 708cc. Shouldn't it be 745cc for the 6.0L (5964cc) V8? I have reviewed several others and they all have the same 708cc setting. Could this be throwing off the math?

Why can't I find the DYNAIR_LS2 pid on my V2 for BBX logging? (edit: Found it. MAFSD in V8)

I have the black box logging configured now and tested out the formulas are returning sane values. I'll get a good log tomorrow on the way to work and try out GELF's method.

How did you get on?

Interesting, I never knew the cylinder volume was incorrect?

[joecar]

Cylinder volume seem to be used when you edit/view the VE table in units other than g*K/kPa...

when you strictly use g*K/kPa then cylinder volume seems to have no effect.

( from what I saw )

[ACCLR8N]

I didn't get on very well I'm afraid. The MAF calibration worked with similar results to the CALC.VET method. Up until boost PE anyway, then it leaned out. After 10 cycles of pasting in error correction 50%, I failed the MAF sensor to see how the VE table was coming along. The result was LTFTs of +25% and STFTs exceeding 50%.

Every example LS2 E40 tune I found had the same 708cc setting in cylinder volume so I left it alone.

I still haven't found a satisfactory E40 method. I've taken to eyeballing the LTFTs and extensive hand smoothing.

[joecar]

Should be able to nail it in 2-3 iterations... something has obviously gone wrong...

post screenshots of your maps.

[Gelf VXR]

I didn't get on very well I'm afraid.

Hi

Did you enable dynamic fueling across the full rpm range, default is MAF only above 3600rpm IIRC?

My assumptions are that AIRPERSEC is the internal calc for the PCM using the VE and MAF for reference, it worked for me.

What are you logging and what filters are you using on the log data?

[Gelf VXR]

Cylinder volume seem to be used when you edit/view the VE table in units other than g*K/kPa...

when you strictly use g*K/kPa then cylinder volume seems to have no effect.

( from what I saw )

Hi Joe

Thanks for clarifying, I only use g*K/kPa, but will correct it anyway.

[ACCLR8N]

Should be able to nail it in 2-3 iterations... something has obviously gone wrong...

post screenshots of your maps.

Decided for trouble shooting to focus on one of my favorite cells. Very high count, lots of steady state cruising. What I see now is with the MAF faulted off, the BEN number makes sense. My average trim was about -8% and the BEN number was 0.92. The next map is with the MAF re-enabled and the resulting BEN factor dropped to 0.77.

[ACCLR8N]

Hi

Did you enable dynamic fueling across the full rpm range, default is MAF only above 3600rpm IIRC?

My assumptions are that AIRPERSEC is the internal calc for the PCM using the VE and MAF for reference, it worked for me.

What are you logging and what filters are you using on the log data?

Howdy,
Yes, I enabled it down to 400 RPM (though at the moment I can't remember where that is).

PIDS:
SAE.TP
SAE.MAF
GM.DYNAIR_LS2
SAE.LAMBDA
GM.AIRPERSEC
SAE.ECT
SAE.RPM
SAE.MAP
SAE.LONGFT1
SAE.LONGFT2
SAE.SHRTFT1
SAE.SHRTFT2
SAE.O2S11
SAE.O2S21
GM.MAFFREQ2
SAE.VSS
EXT.WO2LAM1
EX.WO2EQR1
EXT.WO2AFR1
CALC.WO2BEN
CALC.DYNAIR_BEN1
CALC.DYNAIR_BEN2
CALC.MAF_BEN1
CALC.MAF_BEN2
CALC.TRIMS1
CALC.TRIMS2
CALC.ST_LT_AVE

[Gelf VXR]

Hi,

For the dynamic fueling you need to to disable at 6600rpm and enable at 6500rpm for it to be active across the RPM range. Photo attached

Ive attached my screen shot for my pids (21 of 24) and updated/simplified calc pids file for the calc pids referenced in it.

I also attached screen shot of my filters, from my experience these filters provide satisfactory results, you can still add ECT and for for throttle transitions ETCTP.

The AFR filter out any deceleration that the sensor state did not filter
The wide band sensor state filters out errors from the LC-1's
The FTC filters out OL and odd idle / deceleration cells
The Commanded Fuel filters out PE

If you remove the FTC and Commanded fuel filter, it should still work for when PE is enabled when in the higher MAP areas of your MAF and VE tables, the BEN calc pid references the commanded AFR, positive LTFT are referenced and STFT = 0.

In PE negative LTFT are ignored, which may throw out the correction data?


When I log my data for left and right banks I use the attached spread sheet to obtain the highest values from the two sets of data and use that for my correction to my VE & MAF calibrations. Highlighted blue areas are input, green is the output.

Once Ive applied the corrections I subtract 1% across the calibration, I aim for 0 or positive LTFT, that way when in PE you add fuel to obtain the commanded PE, if your running richer with negative LTFT, there's no correction and you wont command your PE.

Hope this helps :)

[ACCLR8N]

Thank you. I will make the changes this evening and try it tomorrow.

On my single turbo, my bank1 sensor is in the downpipe. I have been tuning based on bank2 as I feel it is a more accurate reading. Any thoughts?

[Gelf VXR]

If it was me I would install WB on both banks in the same location, mine are in the headers just before the cats, previously they where closer to the heads and suffered over heating issues.

[joecar]

Hi,

For the dynamic fueling you need to to disable at 6600rpm and enable at 6500rpm for it to be active across the RPM range. Photo attached

...Would this enable dynamic VE+MAF upto 6600, and MAF only above 6600...?

Of course, the transient filter would remove any VE contribution.

[Gelf VXR]

Would this enable dynamic VE+MAF upto 6600, and MAF only above 6600...?

Of course, the transient filter would remove any VE contribution.

Hi joe, yes

[ACCLR8N]

This going to take a while. I don't have my V7 to V8 PID decoder ring. And I can't access my search button on the V8 BBX since the April upgrade.

[joecar]

This going to take a while. I don't have my V7 to V8 PID decoder ring. And I can't access my search button on the V8 BBX since the April upgrade.In V7 scantool, on PIDs tab, highlight the pids you want, then go Edit->Copy For Export to V8, then in V8 S&T, on BBx window, in Selected PIDs subwindow (for your controller) do Paste.

[ACCLR8N]

When I right click and paste, nothing happens. Does the PID have to be validated in V7 first? I'm stuck on GELF'S BEN1_B. I think I will make my own.

[Gelf VXR]

When I right click and paste, nothing happens. Does the PID have to be validated in V7 first? I'm stuck on GELF'S BEN1_B. I think I will make my own.

I think you will find user configured calc pids can not be copied to or selected in the V8 BB logging, you need select them when reviewing the log in V7.

[joecar]

Yes, correct, only the pre-defined pids, not the calc pids.

[ACCLR8N]

This explains a couple things. I didn't know you could select them after the fact in reviewing the log. There is a field in the V8 BBX (V7 button) where they are listed and pre-selected so they show up when opening the log file. They must be defined in the calc_pids file and your COR_DYNAIR_BEN2 name is too long for this field. I edited the calc_pids to shorten them and made my own WO2BEN for the list.

Additionaly, on the topic of editing, in your filter example you don't have limits for the high and low MAF and VE tables. I created four filters with boundary limits for low MAP, high MAP, low MAF and high MAF. On my maps, if I don't do this, all the values of my high MAF table would be averaged into the value for the last cell in my low MAF table.

[Gelf VXR]

That's good to know regard the pre selecting calc pids for opening in V7 :)

I'm not sure of your boundary limits for MAP, but for logging MAF frequency i created one map with rows for Hz from 1000 to 12200, i copied the relative correction factors to the HI & LO MAF calibrations in the tune where 5800 is common to both?

[joecar]

Yes, correct, the V2 BBx V7 compatibility button allows you to specify calc pids to be pre-selected when you eventually view the resulting log.

--------

You should have two MAF maps (to match your two MAF tables), like Gelf/VXR said.

Then you should have two filters, each filter excludes Hz which is outside of the Hz range of its map, like ACCLR8N said.

BTW: to easily populate a map's row and col axes, in the tunetool goto the table and do copy-with-labels, then in the scantool goto the map's properties and on each of the ROw and Col tabs click Paste Labels.

[ACCLR8N]

I just finished reviewing my log from this mornings ride to work. It still seems to be off by a factor of 2. If I study a single VE cell, my AFR is rich 0,993%, -1.7% avg SHTFT2 and a -5.2% LTFT2. So my expectation is to see a BEN of about 0.93. Instead it is 0.857. I went ahead and pasted error correction w/labels 50%. I'm curious if I will see a neutral result on the way home.

GELF: My CALC.WO2BEN is "({EXT.WO2AFR1}/{GM.AFR_B})" Do I have that backwards for your formula?

I combined my high and low MAF maps since it is a manual paste anyway. Got rid of a filter.

[Gelf VXR]

I just finished reviewing my log from this mornings ride to work. It still seems to be off by a factor of 2. If I study a single VE cell, my AFR is rich 0,993%, -1.7% avg SHTFT2 and a -5.2% LTFT2. So my expectation is to see a BEN of about 0.93. Instead it is 0.857. I went ahead and pasted error correction w/labels 50%. I'm curious if I will see a neutral result on the way home.

GELF: My CALC.WO2BEN is "({EXT.WO2AFR1}/{GM.AFR_B})" Do I have that backwards for your formula?

I combined my high and low MAF maps since it is a manual paste anyway. Got rid of a filter.

I think formula is correct, if AFR result is rich for example 14:1, then 14/14.7=0.95 which the correction factor would reduce VE or MAF table values, less air less fuel, which is correct.

I now paste correction factors 100% and without smoothing, I observe on the V8 AIRPERSEC, MAF and MAFSD they should follow each other very closely, and LTFT.

I do notice my LTFT's don't settle down until the engine has really warmed up, not just after coolant temp reaches 80 C, maybe a good half hour later when the whole engine and bay has reached nominal temperature. So when i go for a drive I think F*@k it, there out again, but come back once properly warmed up :)

If i got unexpected results, I found I was still not filtering out some undesired data.

There are many variables, i don't think it will ever be perfect, but for me this method provided most satisfactory and closest results when compared to doing separate calibrations of VE and MAF tables. LTFTs are different on left and right banks, I know someone who says they had their injectors matched properly which reduced this difference to negligible, it all depends how far your prepared to go in the pursuit of perfection :)

How long are your logs and your journey to work?

[Gelf VXR]

With regard to my calc pid calculation for the VE or MAF correction factor from AIRPERSEC.

Example,

If AIRPERSEC = 40 g/sec, LTFT = -5.2, STFT = -1.7 and BEN = 0.857

Airflow correction for fuel trims

40 x ((-5.2 + -1.7 + 100)/100)
40 x 0.931 = 37.24 g/sec

Commanded AFR correction from BENS

37.24 x 0.857 = 31.91

If MAFSD = 30 g/sec and MAF = 40 g/sec, then MAFSD value is too low and MAF too high

For MAFSD

31.91 / 30 = 1.0637 correction factor, then 30 x 1.0637 = 31.91

For MAF

31.91 / 40 = 0.7977 correction factor, then 40 x 0.7977 = 31.91

Now all three corrected values are the same, 31.91 g/sec and should be very close in next log, I say should be lol :)

[ACCLR8N]

My ride to work is just over 40 minutes. Maybe I'm not getting it hot enough. My couple of runs had the car running leaner and leaner until it finally set P0171 & P0174 bank 1 & 2 too lean. Trims maxed out at 25% & 40%. At least the last log finally turned around to start enriching it back up but only a couple percent. The last run was after the drive home and then back into town for dinner. Warmer engine?

I'm thinking of going back to failing the MAF and getting the VE table closer before trying this again. Then some hour long runs.

[Gelf VXR]

My ride to work is just over 40 minutes. Maybe I'm not getting it hot enough. My couple of runs had the car running leaner and leaner until it finally set P0171 & P0174 bank 1 & 2 too lean. Trims maxed out at 25% & 40%. At least the last log finally turned around to start enriching it back up but only a couple percent. The last run was after the drive home and then back into town for dinner. Warmer engine?

I'm thinking of going back to failing the MAF and getting the VE table closer before trying this again. Then some hour long runs.

If your only pasting 50% corrections, it will take longer to correct.

I experienced something like this when doing AutoVE, my VE table kept getting lower and lower until i had idling issues and starting issues, it was down to my filters, if your not filtering out all of the off the throttle, deceleration and fuel cut off cells when LTFTs go extreme negative, they will offset your steady cruise and steady acceleration data.

[Gelf VXR]

deceleration and fuel cut off cells when LTFTs go extreme negative, they will offset your steady cruise and steady acceleration data.

Actually in AutoVE fuel cutoff is inactive as are LTFT's, but the extreme lean conditions still exist under deceleration as indicated by WB AFR.

[ACCLR8N]

I appreciate your time in helping me work this out. I do have DFCO disabled and usually see a rich condition coasting.

Focusing on the filters for a moment. I am adding in my min throttle position, no decreasing VSS and min coolant temp. One of them I copied is GM.AFR_B not equal to 14.7. Isn't this excluding all the time spent at stoic (the good hits) and only averaging the bad data points?

FWIW I was not going to drive to work today with the horribly lean tune from last night. I threw in my last SD tune which just has the MAF failed rationality test over 10Hz. With the same maps, filters and your formulas from yesterday the resulting correction factors are much more reasonable. I'm trying to understand the significance of having the car ignore the MAF readings but still using them in the calculations.

[Gelf VXR]

No problem with helping out, I'm working abroad and cant do anything with mine so helping someone else out is next best thing :)

Regarding filters, your filters are excluding, you are excluding data when AFR is not equal to 14.7:1, so you are keeping the 14.7:1 data.


Are you using an LC-1, did you filter the sensor error states, their are many, see the attached.

I exclude all states not equal to 1, (normal WB02 operation) this has a big impact on logged data

[ACCLR8N]

Are you using an LC-1, did you filter the sensor error states, their are many, see the attached.
I exclude all states not equal to 1, (normal WB02 operation) this has a big impact on logged data

Yes I am and I didn't know about any of that. It recalibrated on me again while the car was running. Do you have this problem?

[Gelf VXR]

Yes I am and I didn't know about any of that. It recalibrated on me again while the car was running. Do you have this problem?

They do sometimes go out of calibration, its a pain getting under the car to do a free air recal, but its got to be done if it re calibrated while the engine was running.

I attach a couple of screen shots, one with no filters around 50,000 frames, its shows my average AFRs in the mid 20's, my average airflow for all three VE, MAF, and dynamic air nicely matched, the other filterd 30,000 frames shows slightly richer than stoich average AFR and again airflow averages still nicely aligned.

The green numbers are the averages

[ACCLR8N]

When mine does a free air at start up it is useless. It is usually pegged at 25. This time it is bottomed out at 7 something. Little worried something different happened. I'm often at the point of wanting a break when it happens. I'll let the car sit for two days and air the exhaust out then recalibrate it in the car. I have been through this routine enough I know it works. Lord knows the wife is happy to have me focused on something else today.

I have better understanding now I think of the goal here. I have been fixated on LTFTs. Thanks for posting those screen shots. I wasn't tracking those before.

[Gelf VXR]

Your normal free air calibration should be between 24-25 IIRC, if its 7, its way out.

Ive had it read 7 too, best way to correct is remove the sensor from the exhaust.

[ACCLR8N]

Still having the issue with the MAF making it way too lean. I failed the MAF rationality test again. It is still being logged and adjusted, but the car is ignoring it. The process appears to work as the airflow values are converging. I'm still doing the 50% error correction as well to limit the overshooting as the values toggle from rich to lean. My hope is tomorrow to re-enable the MAF with the values closer to ideal and not have the lean out problem.

Results from heavily filtered logs first and fourth. Yellow is average value.

[Gelf VXR]

I found that the GM.AIRPERSEC would follow which ever had the higher value of SAE.MAF and GM.DYNAIR_LS2. Like you said when not enabled it can still be logged.

I’ve been looking at WeathermanShawns (RIP) “correcting MAF and calculating VE (in single log)” method which you tried, if I'm following correctly, this method applies the average LTFT's or BEN to g/sec calculated from CYLAIR DMA or VE DMA pids and corrects MAF values from those data.

You can see Shawn provided some constructive debate at the beginning of this original thread for a simultaneous MAF & VE calibration method, how could I prove that GM.AIRPERSEC was the final calculated figure for the trims to be applied, I could only show my logs, which showed close to zero LTFT'S for the majority of cells on the rich bank and very close g/sec values for MAF, MAFSD and AIRPERSEC.

The debate for the E40 PCM at least, is whether trims and or BENs are applied to AIRPERSEC or the DMA derived g/sec value?

I can observe that the CALC.VET method is not so dissimilar to mine, I can replace GM. AIRPERSEC in my calc pid with a new calc pid for g/sec from GM.APCYL_E40_DMA

*CLC-00-###
gps 0.0 400.0 .3 "{GM.APCYL_E40_DMA}*{SAE.RPM}/15"
CALC.GPS_APCYLDMA F### CLC-00-### gps Gelf_VXR "Calculate g/sec from GM.APCYL_E40_DMA"

And insert into

*CLC-00-###
factor 0 2 .3 "(({GPS_APCYLDMA}*((100+{SAE.SHRTFT1}+{SAE.LONGFT1} )/100))*
{CALC.BEN2_B})/{GM.DYNAIR_LS2 or SAE.MAF or GM.AIRPERSEC or CALC.GPS_VEDMA}"
CALC.#####_DMA# F### CLC-00-### factor Gelf_VXR "##### correction factor from corrected G/SEC DMA from STFT#, LTFT# and BEN#"

There is one fundamental difference between two methods, other than which source for g/sec value should be used for corrections, which is in the way trims and BEN is applied.

I combine STFT & LTFT correction factor with BEN correction factor (relative to each bank) and apply to chosen g/sec value, and correct VE and MAF from that data.

In CALC.VET, either combined LTFTs are used or BEN from WB/'s.

Personally I make corrections to one bank aiming for zero LTFT'S and let the LTFTS on the other correct the other side, positive or negative which ever your preference, mine being positive to ensure commanded EQ during PE, negative LTFTs do not subject during PE. If concerned about safety margin, why not add it to your commanded EQ?

Fortunately I always log E40.APCYL_DMA and could quickly make g/sec comparisons to the other 3 g/sec results, and the values from APCYL are lower than AIRPERSEC, so maybe AIRPERSEC is not correct for the trims and BEN correction? However i got good results from it, but not perfect. I attach pics of my dash board and LTFTs from my last log, actually I wasn’t working on my VE, just fitted new LC-1’s for UK smog test as I run pseudo NB, you can compare to logs for CALC.VET method on the other thread.

If I was at home I would go out and make new log and check g/sec from the VE and APCYL DMA's correspond to one and other to begin with, and then try applying trims and BEN's to the g/sec taken from the APCYL DMA and check the results, always looking for improvements :)

So I was wondering if you wouldn't mind doing some logging and letting me see your data using the following 24 no calc pids

Ive attached pic for the 24 pids

Also attached my latest calc.pid list, incorporating Shawns calc.pids, I like the Charge Temp Calc.

[ACCLR8N]

I find AIRPERSEC and DYNAIR_LS2 averages are always within 0.02g/sec of each other with MAF failed. My average MAF reading is +/- 10%. The closest I have ever gotten it was 2% average (but my average LTFTs were off 14% on that run).

What are your thoughts on removing the STFTs from the equations? As I drive these are very unstable and I'm thinking they are why I can't get this to settle down.

I will set this up at lunch (US Central). My car is a 2005 LS2 6-spd GTO with single front mount turbo on the LH manifold. My bank1 O2 is in the downpipe (combined gases from both sides after turbo) as is my single LC-1 WB. You will need to edit the calc_pids for this when reviewing the log. My Bank1 LTFT are always +5% than Bank2 and my WB typically indicates 1.5% richer than the car (14.5 WB=14.7 commanded). I also assume you want the MAF enabled for this log.

[Gelf VXR]

Great thanks, Ive got a 2005 Monaro LS2 with LS3 heads, intake and a mild cam.

Its strange the MAF has not come into line, ill attach my last few logs so that you can have a look?

For the STFT's, maybe its not necessary, they should cycle up and down and should average around zero for the LTFT offset, Id rather include all the available data.

[joecar]

Just a quick sanity check:

- if MAF is disabled, then you want to correct the VE and calculate a new MAF from that.
- if VE is disabled, then you want to correct the MAF and calculate a new VE from that.

you are both doing the second one, right...?


( i.e. which ever one is disabled, then you can't correct that one )

[Gelf VXR]

I log with nothing disabled, I correct MAF and MAFSD (VE) from 3rd g/sec pid, now I want to check against g/sec calc pid created from DMA for g/cyl or VE.

GM.AIRPERSEC follows the higher value of either when in dynamic mode, or either one of the other depending on which is enabled. If MAF is disabled, it is still logged but referenced.

[ACCLR8N]

Here we go with the really dumb questions: What is the difference between correcting and calculating? How is VE disabled? I was under the impression you always have VE, it is just whether you compare it to the MAF or not.

My VE table looks terrible at this point pasting in the correction values without smoothing. All set up for GELF's logs on the way home.

[joecar]

Correcting: multiply the table by the wideband/LTFT BEN (i.e. corrects the existing table values).

Calculating: use Ideal Gas Law (P.V=n.R.T) to calculate the other table from the corrected table (i.e. calculates new table values).


As you can see, you can not (should not) correct a table if it is disabled (not contributing to cylinder airmass), but you can calculate it from the other table (which is being corrected).

See post #29 here: Summary-Notes (http://forum.efilive.com/showthread.php?14188-Summary-Notes)

[joecar]

Disable VE: set MAF dynamic airflow threshold to below idle speed (causes pure MAF rather than steady-MAF/transient-VE).

Disable MAF: cause a MAF DTC to be immediately present.


Usually, if you don't disable VE, its contribution gets filtered out when you apply the transient filter (so you have to remember to apply it).

[joecar]

For LS1B:



PCM calculates airmass (i.e. cylinder airmass) from:
- above B0120: MAF,
- below B0120: MAF (steady throttle/airflow) and/or VE (transient throttle/airflow),
- in SD (MAF-less): VE.


There would also be a similar parameter B0120 in E40.

[ACCLR8N]

Thanks for the reading Joecar.

GELF, log file attached.

[Gelf VXR]

My bank1 O2 is in the downpipe (combined gases from both sides after turbo) as is my single LC-1 WB.

If your normal NBO2 and WB02 are sampling from gases from both banks, I would average LTFTs. You can ignore STFTs as in theory theu should average zero.

[Gelf VXR]

My VE table looks terrible at this point pasting in the correction values without smoothing. All set up for GELF's logs on the way home.

I wouldn't worry about the aesthetics of your tables, whats important is that they reference true airflow values. A smoothed table will have a much broader range of LTFT and BEN values, IMHO.

[ACCLR8N]

Is your car an automatic?

[Gelf VXR]

Correcting: multiply the table by the wideband/LTFT BEN (i.e. corrects the existing table values).

Calculating: use Ideal Gas Law (P.V=n.R.T) to calculate the other table from the corrected table (i.e. calculates new table values).


As you can see, you can not (should not) correct a table if it is disabled (not contributing to cylinder airmass), but you can calculate it from the other table (which is being corrected).

See post #29 here: Summary-Notes (http://forum.efilive.com/showthread.php?14188-Summary-Notes)

Sorry Joe, respectively I disagree with you here, if you know the PCM final calculated value for g/sec, which is then corrected for trims and BEN, and you know reference values for given reference points, Hz, RPM and MAP, it does not matter if the reference table were enabled or not, you can correct by correction factor or do simple back calculation to find the value for GMVE or copy and paste values, the end result is the same.

I can not see where Newtons Ideal Gas Law (P.V=n.R.T) formula was used to calculate the other table from the corrected table in "summary notes"? What I do see is a g/sec value derived from CYLAIR DMA for g/cyl for the LS1, which is no different to using the 3rd g/sec pid called AIRPERSEC available to the E40 PCM. Newtons gas law is most likely used inside the PCM internal calculations, but seeing as here we are referencing the PCM output data, i see no need to imply its use in the calc pids??

The math for the calculations is the same, the only debate for me is whether I should be using AIRPERSEC g/sec or APCYL DMA derived g/sec, which is what we are in the process of doing :)

[Gelf VXR]

Is your car an automatic?

Not auto, but taking a look at your log, somethings definitely wrong as AIRPERSEC is not corresponding to the highest of the two reference tables MAF and MAF SD?

If I could see you tune file that goes with the log, if you dont want it public you can PM me?

[ACCLR8N]

Here is the tune from the log. I'll delete it in the morning. I've rolled the car back for tomorrow.

[Gelf VXR]

Here is the tune from the log. I'll delete it in the morning. I've rolled the car back for tomorrow.

Somethings gone very wrong with your VE table, your MAF corrections are very close as per your last log, I'm trying to pin point whats going on with VE table.

Pic of my VE table attached

[Gelf VXR]

Up to 8800Hz your MAF g/sec (corrected up to from 2800 to 8400Hz from your last log) your MAF difference to stock is as follows, fairly close. After 8800Hz your numbers diverge much higher, should it? do you have a stock MAF?

In my logs I can get up to 11000Hz, your MAF is calibration is 30-40 g/sec higher at this point, worth investigating?

LABELS MAF Frequency Conversion (Low Flow) (Grams/Sec)
Hz {link: GM.MAFFREQ2} Value
1000 -0.054688
1150 -0.023438
1300 -0.015625
1450 -0.023438
1600 -0.015625
1750 -0.023438
1900 -0.023438
2050 -0.023438
2200 -0.015625
2350 -0.023438
2500 0.125
2650 0.523438
2800 0.984375
2950 1.335938
3100 1.859375
3250 2.359375
3400 3.273438
3550 2.734375
3700 3.921875
3850 3.929688
4000 4.03125
4150 4.007813
4300 3.703125
4450 3.5625
4600 3.984375
4750 4.03125
4900 3.601563
5050 3.945313
5200 4.53125
5350 5.195313
5500 5.507813
5650 5.289063
5800 4.679688
LABELS MAF Frequency Conversion (High Flow) (Grams/Sec)
Hz {link: GM.MAFFREQ2} Value
5800 5.554688
6000 6.453125
6200 6.664063
6400 6.960938
6600 8.679688
6800 8.601563
7000 1.6875
7200 8.929688
7400 7.359375
7600 7.78125
7800 4.1875
8000 13.070313
8200 14.226563
8400 6.53125
8600 7.234375
8800 14.554688
9000 18.3125
9200 24.625
9400 30.226563
9600 35.148438
9800 40.195313
10000 44.484375
10200 48.078125
10400 51.1875
10600 54.296875
10800 57.921875
11000 63.101563
11200 68.726563
11400 73.976563
11600 80.226563
11800 85.4375
12000 90.515625
12200 99.945313

[ACCLR8N]

MAF: Probably should not be that high. MAF is stock, but mounted in custom intake tubing. At some point I had a large step in the curve after correcting and I extrapolated an increase to the remainder of the curve. I have been diligently keeping the car out of boost until I get a handle on the normal driving calibrations. I have since concluded that when operating with the MAF active, the corrections continue to increase until my trims are maxed out negative. I will go back to stock settings today. EDIT: My original MAF settings were even higher: 492.93 g/sec @ 1220Hz

VE: I told you the results were ugly with #0076. I reverted back to my best seat of the pants running tune from last week #0073. My big change over the winter was converting to a return style fuel system and boost referenced regulator that I dialed back to get my Siemens Deka 60lb injectors within the hard limits of the E40 IFR table.

[joecar]

Sorry Joe, respectively I disagree with you here, if you know the PCM final calculated value for g/sec, which is then corrected for trims and BEN, and you know reference values for given reference points, Hz, RPM and MAP, it does not matter if the reference table were enabled or not, you can correct by correction factor or do simple back calculation to find the value for GMVE or copy and paste values, the end result is the same.Not the airmass reference table, but the airmass source table... i.e. the table that provides the airmass calculation... the words corrected/calculated are being used here as definitions of what the procedure is doing (correction by multiplying by BEN, or calculation using IGL)...

i.e. the perspective is the procedure that you are applying from the scantool.

If say the MAF table did not contribute to airmass, then correcting the MAF table (using BEN) will result in a new MAF which again provides no contribution which results in same correction factor, so you keep going circularly...

i.e. only an enabled source can be corrected.


I can not see where Newtons Ideal Gas Law (P.V=n.R.T) formula was used to calculate the other table from the corrected table in "summary notes"? What I do see is a g/sec value derived from CYLAIR DMA for g/cyl for the LS1, which is no different to using the 3rd g/sec pid called AIRPERSEC available to the E40 PCM. Newtons gas law is most likely used inside the PCM internal calculations, but seeing as here we are referencing the PCM output data, i see no need to imply its use in the calc pids??It's in the calc_pids.txt file, CALC.VET is calculated from the corrected MAF... the MAF sourced the airmass (with VE either disabled or filtered out) and was BEN corrected (resulting in a new MAF), and was then used to calculate VE using IGL.

The IGL is used to calculate a new VE table from the current corrected MAF values...

corrected is defined (by the procedure) to mean "multiply the contributing source table by BEN correction factor"

calculated is defined (by the procedure) to mean "use IGL to calculate a new table from the corrected other source table"


The math for the calculations is the same, the only debate for me is whether I should be using AIRPERSEC g/sec or APCYL DMA derived g/sec, which is what we are in the process of doing :)
For E40 I'm not sure where AIRPERSEC and APCYL source from...

AIRPERSEC is probably g/s calculated from VE; APCYL is g calculated from MAF... BUT I'm not sure with E40...

but either of those is not a source table (i.e. neither of those is the VE table or the MAF table), but they are computed derived from those tables...

this means that you can't correct AIRPERSEC or APCYL, which table would you be correcting...?

( notice I use "computed" as meaning "computed by PCM/ECM" )

:)

[joecar]

So for example, you would use MAF * BEN * IGL to calculate a new VE.

In LS1B, for some OS's, VETABLE is a pid which reads VE directly, you would use VETABLE * BEN / IGL to calculate a new MAF.

[Gelf VXR]

Not the airmass reference table, but the airmass source table... i.e. the table that provides the airmass calculation... the words corrected/calculated are being used here as definitions of what the procedure is doing (correction by multiplying by BEN, or calculation using IGL)...

i.e. the perspective is the procedure that you are applying from the scantool.

i.e. only an enabled source can be corrected.


I'm not getting a Eureka moment, maybe some clarification of definitions is needed?


Definition of a reference table

MAF = B0198 and B0199 for the E40, and B5001 for the LS1
VE = B0200 for the E40, and B0101 for the LS1

Either one or both can be enabled, "MAF" or "Speed Denisty" or "Dynamic"


Definition of a source (computed) table

I'm confused,

At the beginning of your post you are saying the reference tables is not the source table, source table is a calculated (computed) table.

"Not the airmass reference table, but the airmass source table... i.e. the table that provides the airmass calculation... the words corrected/calculated are being used here as definitions of what the procedure is doing (correction by multiplying by BEN, or calculation using IGL)..."

At the end of your post your are saying that the reference table is the source table, contradicting the above?

"but either of those is not a source table (i.e. neither of those is the VE table or the MAF table), but they are computed derived from those tables..."


Anyway, i apply trims and BEN corrections to the internally calculated (computed) value, and correct the reference tables from there.



Definition of a calculated table

An EfiLive map created in scan tool using PCM computed data from internal pids and user created calc.pids; MAP, RPM, g/sec, g/cyl, DMA's etc.



If say the MAF table did not contribute to airmass, then correcting the MAF table (using BEN) will result in a new MAF which again provides no contribution which results in same correction factor, so you keep going circularly...

Ahhh, this is where you have misunderstood as I'm not correcting MAF table using BEN? I,m correcting the PCM computed value with trims and BEN and correcting MAF and VE reference tables, which both or either one can be enabled, it does not matter because we know the PCM computed value.




It's in the calc_pids.txt file, CALC.VET is calculated from the corrected MAF... the MAF sourced the airmass (with VE either disabled or filtered out) and was BEN corrected (resulting in a new MAF), and was then used to calculate VE using IGL.

Ok, lets look at the calc pids

*CLC-00-300
% 0.0 100.0 .2 "{SAE.MAF.gps}*{CALC.DAT.K}/{SAE.MAP.kPa}/{SAE.RPM}*3445.2/displacement()"
VE 0.0 2.468 .4 "{SAE.MAF.gps}*{CALC.DAT.K}/{SAE.MAP.kPa}/{SAE.RPM}*15"

CALC.VEN F300 CLC-00-300 "%,VE" Tuning "Calculated VE, not corrected"

MAF g/sec is converted to g/cyl and GMVE calculated, following your method, what you have done is assume that the PCM is references MAF tables B0198 and B0199 for the E40, and B5001 for the LS1 and makes no further internal modifications to this reference value, ie smoothing and filtering? CALC.VET applies the correction factor.

Have you confirmed the g/sec or g/cyl for MAF agree with the PCM CYLAIR DMA data? Ive checked, they don't! You have more than one conflicting data values from the PCM.

I have looked at log posted #268 in

http://forum.efilive.com/showthread.php?15236-Calc-VET-correcting-MAF-and-calculating-VE-%28in-single-log%29/page27

If your refer the 1st attached screen shot of the data, the MAF g/sec isn't the same for the g/sec calculated from the CYLAIR DMA for g/cyl, or any of the other data shown.

Which is the same quandary that I have for AIRPERSEC and APCYL_DMA or E40.SCALEDCORVE_DMA, which should corrections be applied to?



For E40 I'm not sure where AIRPERSEC and APCYL source from...

AIRPERSEC is probably g/s calculated from VE; APCYL is g calculated from MAF... BUT I'm not sure with E40...

but either of those is not a source table (i.e. neither of those is the VE table or the MAF table), but they are computed derived from those tables...

this means that you can't correct AIRPERSEC or APCYL, which table would you be correcting...?

( notice I use "computed" as meaning "computed by PCM/ECM" )

:)


Agreed, AIRPERSEC is the PCM computed value (final g/sec value for fueling) attributed to the reference tables for MAF and VE, whether in MAF only, speed density or dynamic mode, I can and do correct it and achieve near to Zero trims on the corrected bank.

APCYL_DMA is not = to the g/cyl from MAF, but it also insn't = AIRPERSEC or DYNAIR either, as you can see in the attached 2nd screen shot for data.

Ive still to check the E40.SCALEDCORVE_DMA, I neglected to high light the pid it when I asked ACCLR8N to do some logging:doh2:



So for example, you would use MAF * BEN * IGL to calculate a new VE.

In LS1B, for some OS's, VETABLE is a pid which reads VE directly, you would use VETABLE * BEN / IGL to calculate a new MAF.

Yes VETABLE looks to be the equivalent to SCALEDCORVE.

I just reviewed the calc pids above, IGL is not in the formula?

What are the values for

PV=nRT\,

where P is the pressure of the gas, V is the volume of the gas, n is the amount of substance of gas (also known as number of moles), T is the temperature of the gas and R is the ideal, or universal, gas constant.

[Gelf VXR]

MAF: Probably should not be that high. MAF is stock, but mounted in custom intake tubing. At some point I had a large step in the curve after correcting and I extrapolated an increase to the remainder of the curve. I have been diligently keeping the car out of boost until I get a handle on the normal driving calibrations. I have since concluded that when operating with the MAF active, the corrections continue to increase until my trims are maxed out negative. I will go back to stock settings today. EDIT: My original MAF settings were even higher: 492.93 g/sec @ 1220Hz



VE: I told you the results were ugly with #0076. I reverted back to my best seat of the pants running tune from last week #0073. My big change over the winter was converting to a return style fuel system and boost referenced regulator that I dialed back to get my Siemens Deka 60lb injectors within the hard limits of the E40 IFR table.

I agree you should reset your stock MAF values, if you have repositioned your MAF and getting fluctuations, you might want to consider airflow straighter?

I'm looking at larger diameter intake with LS7 MAF using airflow straighteners from http://www.saxonpc.com/

[ACCLR8N]

Let me know what PID you want deleted in favor of E40.SCALEDCORVE_DMA.

[Gelf VXR]

Thanks :) Here's the pid list again

2 E40.SCALEDCORVE_DMA
2 GM.APCYL_E40_DMA
2 GM.DYNAIR_LS2
2 GM.AIRPERSEC
1 GM.FTC
2 GM.MAFFREQ2
1 GM.AFR_B
2 SAE.MAF
2 SAE.RPM
1 SAE.MAP
1 SAE.IAT
1 SAE.ECT
1 SAE.STFT1
1 SAE.STFT2
1 SAE.LONGFT1
1 SAE.LONGFT2
0 CALC.BEN1_B
0 EXT.WO2AFR1
0 EXT.WO2ST1

23 channels

[ACCLR8N]

Here is another log for you to dissect. I learned how to store two PID lists to the V2 unit from V8 last night. I was able to log my tune going out then re-flash your MAF settings to the PCM and log with you PIDS for the return trip.

[Gelf VXR]

Here is another log for you to dissect. I learned how to store two PID lists to the V2 unit from V8 last night. I was able to log my tune going out then re-flash your MAF settings to the PCM and log with you PIDS for the return trip.

For some reason the E40.SCALEDCORVE did not get logged?

[ACCLR8N]

Don't know why it didn't. The name was on the screen, but I can't say what the data was doing. This is what I selected in V8. I will try again tomorrow.

[Gelf VXR]

Don't know why it didn't. The name was on the screen, but I can't say what the data was doing. This is what I selected in V8. I will try again tomorrow.

Its strange, i went a checked i could select in V8 as well. OK thanks :)

[ACCLR8N]

Well I feel vindicated I didn't press the wrong button. The short log attached had the SCALCORVE_M logging on the screen of my V2 with what appeared to be appropriate VE table values. Still no joy opening the scan for review. If you don't have any ideas, I can post the issue in the BBX logging forum. The only thing different I've done is have two different PID lists configured. I demonstrated I could toggle back and forth between them while the engine was running.

[Gelf VXR]

I would post in the BBX forum, sounds like a technical issue for Blacky or GMPX, lets hope they can fix it👍

[Gelf VXR]

I think its to do with oid validation when the flash scan is connected to the vehicle..

[ACCLR8N]

So you think I need to have my laptop connected for logging?

Meanwhile I am reexamining my injector min pulse width and adders to see if that's the cause of the spike in the low VE cells.

[Gelf VXR]

Yes, well maybe you need to validate pids in V7 with laptop connected, then try open the log?

[joecar]

I would post in the BBX forum, sounds like a technical issue for Blacky or GMPX, lets hope they can fix itWhat is going wrong...?

Give me some more detail, and I'll send it to Paul.

[joecar]

Hi Gelf,

Then the reference tables and source tables would be the one and same...



. . .
MAF = B0198 and B0199 for the E40, and B5001 for the LS1
VE = B0200 for the E40, and B0101 for the LS1
...
The PCM would use both of those as sources for the airmass/airflow computation.

The PCM would then compare its computed airmass/airflow to the throttle/MAF/MAP sanity tables (in Engine Diagnostics in the tunetool), these would be reference tables.

Another example: HO/LO/base spark tables (source) vs Ideal Spark table (reference) [ Ideal Spark is not actually commanded, but used as a sanity check ]




...
Ahhh, this is where you have misunderstood as I'm not correcting MAF table using BEN? I,m correcting the PCM computed value with trims and BEN and correcting MAF and VE reference tables, which both or either one can be enabled, it does not matter because we know the PCM computed value.
...
Ah, I see, you're applying the correction to the computed value (g/s or g) and pasting this into the source table (ok, we established source = reference)... ok, so this is interesting and a little different :cheers:

Where does the E40 comute AIRPERSEC and APCYL_DMA from...?




...
MAF g/sec is converted to g/cyl and GMVE calculated, following your method, what you have done is assume that the PCM is references MAF tables B0198 and B0199 for the E40, and B5001 for the LS1 and makes no further internal modifications to this reference value, ie smoothing and filtering? CALC.VET applies the correction factor.

Have you confirmed the g/sec or g/cyl for MAF agree with the PCM CYLAIR DMA data? Ive checked, they don't! You have more than one conflicting data values from the PCM.
...
SAE.MAF is what the MAF reads with no alteration, this is how the SAE specified this pid.

CYLAIR_DMA may be different, but I'm hoping it's not... I have various logs where it is the same, let me double check.

edit: I sometimes use one of the DMA g/s pids to produce an initial MAF table which I then proceed to correct... hmmm, so you're combining that into a single step, clever :cheers:


...
*CLC-00-300
% 0.0 100.0 .2 "{SAE.MAF.gps}*{CALC.DAT.K}/{SAE.MAP.kPa}/{SAE.RPM}*3445.2/displacement()"
VE 0.0 2.468 .4 "{SAE.MAF.gps}*{CALC.DAT.K}/{SAE.MAP.kPa}/{SAE.RPM}*15"
...
...
I just reviewed the calc pids above, IGL is not in the formula?

What are the values for

PV=nRT,

where P is the pressure of the gas, V is the volume of the gas, n is the amount of substance of gas (also known as number of moles), T is the temperature of the gas and R is the ideal, or universal, gas constant.
For the [%] calculation, the IGL is in there... let me look thru my notes.

Interesting discussion... it's making me think about the DYNAIR/DYNCYLAIR/DMA pids.

[Gelf VXR]

Ive checked the log that was corrected by Blacky, as shown on the attachment we now have five data values from pids that we compare for gsec and gcyl.

[ScarabEpic22]

Interesting read fellas, Ive got an E40 coming in next week that Ill be working on. Just ported (as best I could) the LS1 Calc.VET to the E40 using B0115 as my Charge Temp factor for the DAT calculation, E40.SCALEDCORVE_DMA for GM.VETABLE_DMA (going to use the info in this thread to verify/modify), and GM.APCYL_E40_DMA for GM.DYNCYLAIR_DMA. The biggest unknown is what SCALEDCORVE_DMA returns (and is what you've been discussing in the last posts in this thread). I dont have STFTs in any of my calculations, as the Calc.VET doesnt use them. Going to think about this one.

Since I dont have the truck yet, all I can do is validate the PIDs in the Scan tool and look at the BBL PIDs plus the tune file. Once I actually get the truck and the wideband on it, then Ill be able to start contributing.

Ill attach my calc_pids work-in-progress right now. If anyone has some feedback, please let me know.

[joecar]

Ive checked the log that was corrected by Blacky, as shown on the attachment we now have five data values from pids that we compare for gsec and gcyl.The more, the merrier... Compare then in chart/graph form... post a pic of the chart dash.

[joecar]

Erik, interesting calc_pids.txt...

[ScarabEpic22]

The more, the merrier... Compare then in chart/graph form... post a pic of the chart dash.

Im going to look at it again tonight, might have to wait until tomorrow. But there's a lot of good info in this thread I need to process and sift through.


Erik, interesting calc_pids.txt...

Look through it and let me know what you think. Since the E40 doesnt validate EQRatio, I used 1/Lambda to try and keep everything else as similar to the LS1 Calc.VET method. I added the LS1 and E40 tags so it'll be easy to know what PIDs to use in the Scan tool. Once I have it sorted, Ill create another folder for LS1 and E40.

[ACCLR8N]

The E40 SAE.LAMBDA is the EQRatio

[joecar]

The E40 SAE.LAMBDA is the EQRatioSo, from various observations, it seems that SAE.LAMBDA behaves as follows:
- E40 = commanded EQRatio;
- E38 = commanded Lambda;

anyone please feel free to add/comment.

[ScarabEpic22]

So, from various observations, it seems that SAE.LAMBDA behaves as follows:
- E40 = commanded EQRatio;
- E38 = commanded Lambda;

anyone please feel free to add/comment.

Good to know, again Im just going off definitions as I wont have the truck here until next week. If it really is EQR for E40s, have to updated my calc_pids file.

[joecar]

Unfortunately the E40 is "discover as you play".

[Gelf VXR]

The more, the merrier... Compare then in chart/graph form... post a pic of the chart dash.

Will post later, the gcyl DMA follows similar graph to gcyl for AIRPERSEC, supporting my assumption, the gcyl/gsec for SCALEDCORVE DMA are some way off, however ACCLR8N has issues with his VE table and injector setting which may be skewing the data?

[ACCLR8N]

Unfortunately the E40 is "discover as you play". Grrrrrrr. The one year wonder computer.


however ACCLR8N has issues with his VE table and injector setting which may be skewing the data?
Yeah he does. I have most it sorted now except for an inexplicable long injector pulse at 3000RPM. Be back on track soon I hope.

Are you able to do the log name editing for the SCALCORVE_M?

[Gelf VXR]

Grrrrrrr. The one year wonder computer.


Yeah he does. I have most it sorted now except for an inexplicable long injector pulse at 3000RPM. Be back on track soon I hope.

Are you able to do the log name editing for the SCALCORVE_M?


Ive been looking online for a free hex editor.

[Gelf VXR]

E40.SCALEDCORVE_DMA

This VE pid values for gsec and gcyl are way off from others?? Average x 1.46 higher. I think the title of the pid needs closer scrutiny, what is scaling and what is correcting the VE?

What is its purpose?

In the sae_generic file there is a reference for the E38 VE to divide by 1000?


# E38 VE
# ========================
*CLC-00-959
factor 0.0 5.0 .4 "{E38.SCALEDCORVE_DMA}/1000"

[ScarabEpic22]

2 year wonder ECM for everything but the Vette, I really cant believe GM wasted the R&D to put it in 1 year of the Vette. Doesnt make sense, but then again a lot of stuff doesnt (especially with this ECM).

[ACCLR8N]

Maybe we should credit them for recognizing a mistake and quickly correcting it.

[rpmauto]

Glad I found this thread. I have been talking with Joecar for a while now about getting some iteration of the CALC.VET for the E40. There just isnt that much info out there on this pcm. I love the method on the ls1 pcm, and would love to have something like it for the e40. I have a 05 GTO that is bone stock, other than headers and cold air. I would be more that willing to be a guinia pig for some testing as the results should be fairly close to the factory calibration. I have never really been a fan of the Auto VE method. I am also by no means a computer wiz so figuring out the calc.pids on my own is a no go. Also I know that for calculation purposes I see that the e40 uses lambda. When using the CALC.VET Joecar was kind enough to make a set of pids for me (i assume that they are still posted in the calc.vet thread) for simply veiwing in AFR. I have been taught AFR in school, and use it on a daily basis. (auto repair shop owner, tech) I would like to use that again.

If somebody wants to send me a calc.pids text file I would be more than happy to do some logging and see what happens. I appears that most of the logs in this thread are on more modfied cars and maybe some of the airflow data is harder to interpit where it should be because of this.

Let me know if I can be of any help.

Len

[joecar]

Hey Len,

If we can find equivalent pids for the E40, we can make an E40 calc_pids.txt

at a minimum we would a pid that is equivalent GM.EQUIVRATIO (E38 used SAE.LAMBDA).


Can you take some logs using some various pids and post them here.

[ScarabEpic22]

I worked on this back in June when I tuned my first E40, got the VE/MAF dialed in pretty well but it needs a little more tweaking. As ACCLR8N/Gelf found out, there are 3 different Dyn/Calc/DMA VE PIDs that all spit out different values. I ended up using the PID list I setup to get the VE/MAF close, then I went back to the basic AutoVE to fine-tune it.

[ACCLR8N]

Len, you might find this convenient. 4 PID lists for E40 GTO to load into your V2. Copy it to your \EFILIVE\V8\tmp folder. From there you can launch V8 go to BBX and Open it. It is set up for a single serial WBO2. You may need to edit it for your wideband set up. Then save and program your V2.

Now in the car when you select PID list on the V2 during BBX logging, you will have four options:
The "VE" is the list to select in the car for GELF's calc_pid file and suggested filters.
The "OL" trades INJPW2 for FUELSYS and reorders PIDS
The "Boost" trades STFT1, FTC and VSS for KR, Spark Adv, and IAT
The "GELF" list has all the airflow PIDS for comparison

[joecar]

From that V2 BBL file, it looks like the E40 pid we want is GM.EQ_RAT

what does this translate to in V7 scantool...?

[ACCLR8N]

SAE.LAMBDA in V7 logs.

[joecar]

Does table B4901 exist in your tune file...?

[joecar]

SAE.LAMBDA in V7 logs.Can you post a log with this...?

or, can you see if SAE.LAMBDA is behaving like Lambda or EQR...?

[joecar]

Does table B4901 exist in your tune file...?Oh, in E40 it is called B0015... what is the step size of its axis...?

Can someone paste B0115 here (copy-wth-labels, paste).

Thx.

[ACCLR8N]

LABELS Charge Temperature Blending (Factor)
g/sec {link: SAE.MAF} Value
0.0 0.799805
9.5 0.419922
18.8 0.282715
28.1 0.243653
37.5 0.219727
46.9 0.202637
56.3 0.188477
65.7 0.175781
75.0 0.164551
84.4 0.153809
93.8 0.143555
103.1 0.134277
112.5 0.124512
121.9 0.115234
131.2 0.106445
140.6 0.089844
150.0 0.070007

SAE.LAMBDA behaves as EQR in the E40.

[joecar]

Does the E40 support the pid GM.VETABLE_DMA...?

If not then we can't do CALC.MAFT (we can just ignore it and correct the VE table anyway.


Regardless, we will still be able to do CALC.VET.

[ACCLR8N]

I think that is SCALCORVE_M VE Table Lookup.

[joecar]

I think that is SCALCORVE_M VE Table Lookup.Can you post some logs with this pid and any other VE pids...

[ACCLR8N]

Tomorrow I can.

[ACCLR8N]

Log of SCALCORVE

[joecar]

SCALEDCORVE_DMA looks like the VE table... this means CALC.MAFT may have a chance on E40... I'll edit calc_pids.txt for it.

[joecar]

E40 summary (notes to self):
- CALC.DAT requires lookup of B0115 ECT/IAT Blend Factor table,
- SAE.LAMBDA behaves like EQR (use it for CALC.CL and CALC.WO2BEN),
- E40.SCALEDCORVE_DMA looks like VE in g*K/kPa, use it for CALC.MAFT,
- E40.APCYL_E40_DMA looks like g/cyl.

[joecar]

Here is a calc_pids.txt for doing Calc.VET and Calc.MAFT on E40 (attached).


I don't know if Calc.MAFT will work yet... I need to see some images of your VE table.


edit: updated attachment based on post #141 below.

[joecar]

What pid would be the E40 equivalent of GM.DYNCYLAIR_DMA [g/cyl]...?

[joecar]

What pid would be the E40 equivalent of GM.DYNCYLAIR_DMA [g/cyl]...?Is it E40.APCYL_E40_DMA...?

[ACCLR8N]

probably

[ACCLR8N]

I don't know if Calc.MAFT will work yet... I need to see some images of your VE table.


Who's? Are you doing this for Len?

[ScarabEpic22]

Id be up to test this again, got another E40 coming in about 4 weeks. Have an ECM I can connect to and validate PIDs on the bench too if you need supported PIDs Joe.

[joecar]

Who's? Are you doing this for Len?Anyone who has an E40 (Len is one of many)...

I want to see as many E40 VE tables as I can.

( one thing I learnt is that LS1A/LS1B assumptions are usually wrong for E40 :) )

[joecar]

Id be up to test this again, got another E40 coming in about 4 weeks. Have an ECM I can connect to and validate PIDs on the bench too if you need supported PIDs Joe.Hey Erik, thanks, appreciated.

[joecar]

. . .

*CLC-00-430
VE 0.0 4.0 .4 "{E40.APCYL_E40_DMA}*{CALC.DAT.K}/{SAE.MAP.kPa}"

*CLC-00-435
gcyl 0.0 1.0 .4 "{E40.SCALEDCORVE_DMA.VE}/{CALC.DAT.K}*{SAE.MAP.kPa}"

. . .
I'm hoping that the pids APCYL_E40_DMA and SCALEDCORVE_DMA relate to each other properly according to those 2 equations...


i.e. I'm hoping the following turn out to besimulataneously true:

E40.SCALEDCORVE_DMA.VE = {E40.APCYL_E40_DMA.g}*{CALC.DAT.K}/{SAE.MAP.kPa}

E40.APCYL_E40_DMA.g = {E40.SCALEDCORVE_DMA.VE}/{CALC.DAT.K}*{SAE.MAP.kPa}

( where .VE is .g*K/kPa )


they will be simulataneously true if those two pids behave properly (are what we think).

[Gelf VXR]

I give up lol

I've been posting about the difference in the returned data for these pids for ages...

Post 92 in this thread

[Gelf VXR]

Glad to see someone else is taking a look thou :good:

[joecar]

I give up lol

I've been posting about the difference in the returned data for these pids for ages...

Post 92 in this threadHi Gelf,

I've been look at your files for a long time (before Calc.VET for the LS1), trying to understand the various pids and why the air pids returned seemingly inconsistent data...

the other day it dawned on me that it could be DAT was not being taken into account (i.e. some of the pids are with DAT factored in, some of them are without)

[ it doesn't help that I don't have an E40 vehicle to experiment on ]

[ACCLR8N]

Anyone who has an E40 (Len is one of many)...

I want to see as many E40 VE tables as I can.

I am all in to help the cause. I just didn't want to be using up my JOECAR help credits on something I didn't need right now. What format are you looking for? This is what my latest VE table looks like that I am pretty happy with. If I correct it with GELF's formulas and filters it seems to go too far. And that is what I have chased with all these methods.

One factor I know is throwing things off is my WBO2 averages 2.7% (1.027EQR) richer than the NBO2's (1.000EQR) report. But that doesn't account for the whole error. What methods do people use to reconcile a consistent O2 error?

[joecar]

I give up lol

I've been posting about the difference in the returned data for these pids for ages...

Post 92 in this thread
Hi Gelf,

We can't compare the g/cyl too closely because of what you said about the PCM computing them differently and with information that we/you/me are not privy to...

so, in trying to do Calc.VET and Calc.MAFT we can try to see if MAF (g/s) and VE (g*K/kPa) can be reconciled by CALC.DAT (i.e. we're trying to see if we can accurately calculate one from the other) without looking at the g/cyl pids (too closely)...

can you see where this is leading...?

If you can correct the MAF then you can calculate what the VE should look like from that corrected MAF...
If you can correct the VE then you can calculate what the MAF should look like form that corrected VE...
and when you run either of them, we're hoping, to get zero trims and unity wideband BEN...

and we're having to sidestep the g/cyl pids to do this (since we can't seem to get them to agree with each other)

[joecar]

I am all in to help the cause. I just didn't want to be using up my JOECAR help credits on something I didn't need right now. What format are you looking for? This is what my latest VE table looks like that I am pretty happy with. If I correct it with GELF's formulas and filters it seems to go too far. And that is what I have chased with all these methods.

One factor I know is throwing things off is my WBO2 averages 2.7% (1.027EQR) richer than the NBO2's (1.000EQR) report. But that doesn't account for the whole error. What methods do people use to reconcile a consistent O2 error?lol, no worries, you won't use them up...

Try the calc_pids.txt, see if all the pids validate and then take a log...

then from the log we'll see what a map of CALC.VET looks like (calculated from corrected MAF), we'll see how close it is to your VE table.

[joecar]

If you can disable LTFT and run only STFT, then for stoich you should see the wideband oscillate tightly... the center of this oscillation is where stoich really is.

Post a log of this if you can.

[ACCLR8N]

Both logs

[Gelf VXR]

Hi Gelf,

We can't compare the g/cyl too closely because of what you said about the PCM computing them differently and with information that we/you/me are not privy to...

so, in trying to do Calc.VET and Calc.MAFT we can try to see if MAF (g/s) and VE (g*K/kPa) can be reconciled by CALC.DAT (i.e. we're trying to see if we can accurately calculate one from the other) without looking at the g/cyl pids (too closely)...

can you see where this is leading...?

If you can correct the MAF then you can calculate what the VE should look like from that corrected MAF...
If you can correct the VE then you can calculate what the MAF should look like form that corrected VE...
and when you run either of them, we're hoping, to get zero trims and unity wideband BEN...

and we're having to sidestep the g/cyl pids to do this (since we can't seem to get them to agree with each other)

I understand the principle, but what if the PCM IS performing another function on the airflow value from SAE.MAF or GM.DYNAIR before reaching the final value, your applying trims or BEN corrections to the wrong data, my theory is that GM.AIRPERSEC is the final value (engine dynamic airflow), that is why I apply the fuel trim corrections and BEN adjustments to AIRPERSEC and then correct the MAF and VE tables simultaneously from there.

You can test this by running just the MAF or by running SD, in all cases log all three pids, SAE.MAF, GM.DYNAIR_LS2 and GM.AIRPERSEC


With MAF failed, AIRPERSEC aligns with GM.DYNAIR, but not precisely
With MAF only, AIRPERSEC aligns with SAE.MAF, but not precisely
With both enabled, AIRPERSEC aligns with the higher value of either SAE.MAF or GM.DYNAIR(dynamic)


This is the only method for which I got my LTFT close to zero and all three airflow pids in close alignment.

When I did AutoVE tune my LTFTs jumped from positive to negative.

Also I noticed GM.APCYL.DMA gcyl data is closest to AIRPERSEC gcyl data.

I'm interested to see results for your method.


My VE table attached (216/229 cam & ls3 heads), I tune for zero/positive trims so values are lower, peak around 2.95.

I notice ACCLR8N peak values are around 2.2, the stock peak value is around 2.53, there's something wrong there??

[ACCLR8N]

V8 APCYL_E40_M = V7 GM.DYNAIR_LS2? That got the calc_pids to work but the results don't make sense.



My VE table attached (216/229 cam & ls3 heads), I tune for zero/positive trims so values are lower, peak around 2.95.

I notice ACCLR8N peak values are around 2.2, the stock peak value is around 2.53, there's something wrong there??

I have introduced exhaust and intake restrictions on an otherwise stock motor. That and I measured my fuel pressure with 5 different gauges and got 5 different results. My IFR is certainly off a small amount as evidenced by MPG error.

[joecar]

I understand the principle, but what if the PCM IS performing another function on the airflow value from SAE.MAF or GM.DYNAIR before reaching the final value, your applying trims or BEN corrections to the wrong data, my theory is that GM.AIRPERSEC is the final value (engine dynamic airflow), that is why I apply the fuel trim corrections and BEN adjustments to AIRPERSEC and then correct the MAF and VE tables simultaneously from there.

You can test this by running just the MAF or by running SD, in all cases log all three pids, SAE.MAF, GM.DYNAIR_LS2 and GM.AIRPERSEC


With MAF failed, AIRPERSEC aligns with GM.DYNAIR, but not precisely
With MAF only, AIRPERSEC aligns with SAE.MAF, but not precisely
With both enabled, AIRPERSEC aligns with the higher value of either SAE.MAF or GM.DYNAIR(dynamic)


This is the only method for which I got my LTFT close to zero and all three airflow pids in close alignment.

When I did AutoVE tune my LTFTs jumped from positive to negative.

Also I noticed GM.APCYL.DMA gcyl data is closest to AIRPERSEC gcyl data.

I'm interested to see results for your method.


My VE table attached (216/229 cam & ls3 heads), I tune for zero/positive trims so values are lower, peak around 2.95.

I notice ACCLR8N peak values are around 2.2, the stock peak value is around 2.53, there's something wrong there??Point me to your calc_pids.txt file...

[joecar]

V8 APCYL_E40_M = V7 GM.DYNAIR_LS2? That got the calc_pids to work but the results don't make sense.I'll find out.

[joecar]

Oh...


V8 APCYL_E40_M == V7 E40.APCYL_E40_DMA

[Gelf VXR]

Point me to your calc_pids.txt file...

My latest calc pid text file

[ACCLR8N]

I logged APCYL_E40_M and E40.APCYL_E40_DMA will not validate in my log file. I have GM.DYNAIR_LS2 or GM.AIRPERSEC (which I assume is V8 AIRPERSEC) showing up in V7. Why can't these match???

[Gelf VXR]

Both logs

CALCVET log, airflow and cylinder fill min ave and max look tight including SCLAEDCORVE

[ACCLR8N]

That's good, right?

[Gelf VXR]

if all the airflow pids are in agreement, yes

[ACCLR8N]

Okay, I copied GM.APCYL_E40_DMA for export to V8 and it did paste in as APCYL_E40_M. Why won't it validate the other way in V7?

My V8 BBX PID file --deleted obsolete

[joecar]

Okay, I copied GM.APCYL_E40_DMA for export to V8 and it did paste in as APCYL_E40_M. Why won't it validate the other way in V7?

My V8 BBX PID fileThere's a bug that requires a hack to make it work... I'm looking for it.

[ACCLR8N]

There's a bug that requires a hack to make it work... I'm looking for it.

Okay, thanks.

[ACCLR8N]

Joecar the PID issue is fixed with the latest beta update. I'm still getting all zeroes from your calc_pid file for the % outputs. Where does the "displacement" come from in your formulas? Am I supposed to edit the file with my value? Is this per cylinder or engine?

Gelf, Would you mind posting a log file? I'm curious how much your MAF g/s dances around. Most everybody else has gone SD.

[joecar]

Displacement is set in the scantool at Edit->Log File Information->Vehicle Options

But, don't use [%]... use [g*K/kPa] instead (set your tunetool to display VE in [g*K/kPa].

[ACCLR8N]

I have run the same tune a few days now with and then without MAF. Filtering to my cruise cell of 2000 RPM at 31.9 kPa, LTFTs are running +3-4% in the hot humid afternoon heat without MAF. My tune: 1.5766 gK/kPa

GELF's DYNAIR calc wants to correct by 1.015 factor (plausible)

calc.VET spits out 1.727 gK/kPa (too high)
calc.VEDCA spits out 1.551 gK/kPa (wrong way)

[joecar]

GELF's DYNAIR calc looks the best.

[Gelf VXR]

I have run the same tune a few days now with and then without MAF. Filtering to my cruise cell of 2000 RPM at 31.9 kPa, LTFTs are running +3-4% in the hot humid afternoon heat without MAF. My tune: 1.5766 gK/kPa

GELF's DYNAIR calc wants to correct by 1.015 factor (plausible)

calc.VET spits out 1.727 gK/kPa (too high)
calc.VEDCA spits out 1.551 gK/kPa (wrong way)


How did you get on in the end, I was able to do some simultaneous calibration of VE and MAF of my idle over Christmas period.


I also did some experimentation with MAF and VE disabled.

With MAF disabled, I set MAF to 1g across the entire frequency range to be sure, MAF is still logged and returns value 1g, but not referenced by thePCM, like wise I set VE table to 0.5g*K/kPa for all cells, E40.SCALEDCORVE returned 0.5 for all and DYNAIR returned very low g/sec values accordingly, but is not referenced by the PCM.

I confirmed if MAF is disabled AIRPERSEC follows DYNAIR (not exactly, maybe some internal algorithm applied), if dynamic air mode is disabled AIRPERSEC follows MAF (again not exactly). With dynamic air mode enabled AIRPERSEC is combination of both, in all my observations and modifications to the tune calibration file, STFT&LTFT with BEN correction factor is applied with regard to AIRPERSEC.pid. My target was to achieve >0<1% trims on rich bank and +trims on the lean bank, I'm pretty close after 4 iterations, see attached pdf.


The E40.APCYL DMA g/cyl pid from what I observed always follows the minimum AIRPERSEC calculated g/cyl value which is referenced for spark look up table.


One thing was strange when I had made an error in the tune calibration for dynamic air mode to disable VE, I left B2002 re-enable so it was much higher than B2001, anyway DYNAIR returned g/sec values almost 3 times higher than expected, AIRPERSEC still followed the MAF, DYNAIR was not referenced by the PCM, Strange?

My logs attached, so for calibrating MAF and VE simultaneously set B2001 TO 500rpm and B2002 to 400rpm and apply STFT&LTFT&BEN to AIRPERSEC g/sec values and correct DYNAIR and MAF factors as an average or to rich or lean side which ever is your preference

[ACCLR8N]

Short answer: Great with your formulas. If you didn't mash the pedal and let the turbo sing, you would not know you were driving a modified vehicle. My MPG display is even accurate to 1%.

In the end I found the formulas quickly got me to a 6% fuel trim error. To get better than that involved disabling the MAF, nudging in on the VE table by correcting 50%, 25%, 15% and finally hand smoothing out any spikes. MAF fine tuning went very quick following the descending correction scaling and some more hand smoothing. The AIRPERSEC discrepancy you pointed out above may be more pronounced in my car.

I am looking forward to reviewing your logs when I get home tonight.

Oh, and I must say: Thank you very much!

[ACCLR8N]

Gelf, do you have a recent normal driving loop log? Preferably 30+ minutes? I've found the readings stabilize after 20 minutes of driving. Was probably you that pointed that out to me. I'm comparing average MAF to DYNAIR and LTFT's as a sanity check on my tune. I wish I would have logged my car before modifications.

You got me beat on the idle values. I'm going to blame my aftermarket 60lb injectors for at least part of my discrepancy.

[Gelf VXR]

Sorry I don't, I didn't have any insurance, that's why I spent so much time looking at idle

[ACCLR8N]

Well, I am curious to see how your tune lines up with and without MAF enabled. I definitely got different results when I tuned separately vs simultaneous. That final sub-2% variation in the airflow inputs and fuel trims escapes me as my bench mark for the elusive "perfect tune". My MPG is better than stock and I have no driveability issues so last fall I gave up and pulled my wideband.

[Gelf VXR]

I always got unsatisfactory results when I did VE and MAF independently correcting DYNAIR and MAF, because I should have corrected to AIRPERSEC and applied to DYNAIR and MAF


I did some analysis on the logs for VE/MAF/Trims enabled/disabled.

[joecar]

Gelf,

I have been thinking... what car do you have, and what intake manifold does it have...?

[Gelf VXR]

Its a Monaro 6.0 VXR, LS2 with E40 PCM, its been modified with stock LS3 heads and stock L76 intake, plus cam

[joecar]

So you do not have the LS2 intake (which is said to suffer from internal leaks)...

[Gelf VXR]

So you do not have the LS2 intake (which is said to suffer from internal leaks)...

Correct, I have a L76 intake. A leaky intake would explain higher MAP or less vacuum than normal / stock.