Calc.MAFT: correcting VE and calculating MAF (in single log) --> reverse of Calc.VET

[WeathermanShawn]

In-Memory-of-Shawn-Sankey (http://forum.efilive.com/showthread.php?16849-In-Memory-of-Shawn-Sankey)

This is the reverse of Calc.VET (https://forum.efilive.com/showthread.php?15236-Calc-VET-correcting-MAF-and-calculating-VE-(in-single-log))

This requires the OS to support the pid GM.VETABLE_DMA (unless you're SD/MAF-less in which case you're only correcting the VE).


AIMS:

Tune MAF/VE tables from idle to redline RPM in a single log session:

1. Tune both CL and PE/WOT,
2. Correct VE,
3. Calculated new MAF from corrected VE,
4. Eliminate Trims.


PROCEDURE:

1. Disable MAF: CALC MAFT can be performed Open or Closed-Loop

A. C2901: MAF High Frequency Fail 1: Change to 1 Hz
B. C2903: MAF High Frequency Fail Limit: Change to 1
C. Copy B5913 High-Octane Spark to B5914 Low-Octane Spark
D. Insure MAF Sensor Circuit is displayed as a current DTC


2. Setup Calculated PIDS:

calc_pids.txt (http://forum.efilive.com/attachment.php?attachmentid=14575&d=1360953394) <--- updated calc_pids.txt file

Copy that calc_pids.txt file to this folder, or copy/paste its contents to the calc_pids.txt file at this folder on your PC:
My Documents\EFILive\V7.5\User Configuration\


3. Select the following CALC.VET pids and record a suitable log:

http://i1126.photobucket.com/albums/l609/weathermanshawn/CALCMAFTPids.png

Note: Keep Channel Count at 24 or less for Fastest Scanning.

Note: CALC.PE has been replaced by CALC.CL.


4. Apply CALC.VET/MAFT Filter:

http://i1126.photobucket.com/albums/l609/weathermanshawn/CALCMAFTFilter.png


5. Paste-with-labels the new CALC.MAFT map into Table B5001 in your tune file:

( ignore this step if you're running SD, i.e. ignoring MAF and doing VE table only )

http://i1126.photobucket.com/albums/l609/weathermanshawn/CALCMAFT.png

(to limit the cell display width to something sensible, in the map properties goto the Cell tab and look at Constrain Cell Size)


6. Paste-multiply-with-labels the new CALC.SELBEN map into Table B0101 into your tune file:

http://i1126.photobucket.com/albums/l609/weathermanshawn/VETableMAFTSELBEN.png

To display units on a map: go to map properties, on each of the Data, Row, Col tabs, checkmark Show Units.


APPENDIX:

Read these for more info:

( read 1. to gain a better understanding of how Calc.MAFT and Calc.VE are the mirror image inverse of each other )

1. CALC.VET: A-New-Twist-on-CALC.-VE-Table..Computing-the-Entire-VE-Table. (http://forum.efilive.com/showthread.php?15236-A-New-Twist-on-CALC.-VE-Table..Computing-the-Entire-VE-Table.)

2. Advanced CALC.VET Summary Notes: Summary-Notes (http://forum.efilive.com/showthread.php?16280-CALC-VET-Summary-Notes)

3. EFILive's AUTOVE Tutorial for full instructions on SD Tuning procedures (this is outdated): AutoVE Tuning Tutorial.pdf (http://download.efilive.com/Tutorials/PDF/AutoVE Tuning Tutorial.pdf)

4. How-to-match-wideband-output-to-B3601 (http://forum.efilive.com/showthread.php?13229-How-to-match-wideband-output-to-B3601&p=117265#post117265)

5. Two Methods for Calculating Analog Wideband Lambda

(http://forum.efilive.com/showthread.php?15236-A-New-Twist-on-CALC.-VE-Table..Computing-the-Entire-VE-Table.&p=137997&viewfull=1#post137997)
Credits: (in no particular order):
joecar (forum moderator) for analyzing/deriving the CALC.VET equation(s) in terms of a log-able pids.
Weathermanshawn for inventing/exploring the idea of correcting VE and MAF in from a single log.




EDIT: attached latest zips, hopefully I attached the right ones.

[Dieselman]

Sounds good. I will be tuning my first LS1 in a few weeks so and this sounds like it would be a handy tool to have


Cheers

Ben

[joecar]

I had meant to write this (SELBEN applies any multiplier correction to VETABLE_DMA):

MAF = {GM.VETABLE_DMA.VE}/{CALC.DAT.K}*{SAE.RPM}*{SAE.MAP.kPa}/15*{CALC.SELBEN}

(where the VE units are shorthand for g*K/kPa)

(where CALC.DAT.K is {GM.DYNAIRTMP_DMA.C}+273.15)

[joecar]

This method does these things simultaneously:
- corrects VE table using LTFT and/or wideband,
- calculates a MAF table from the corrected VE table.

[joecar]

Hi Shawn,

Here is a preliminary calc_pids.txt file...

the new pids are CALC.MAFN and CALC.MAFT, these require the pid GM.VETABLE_DMA to be selected, not all OS's have this pid; to keep the pid channel count from going above 24, we may have to delete some other pids (e.g. IAT, ECT, VSS... maybe).

note that GM.VETABLE_DMA has units [g*K/kPa] this means that CALC.MAFN and CALC.MAFT wil have units [g/s] ("VE" and "gps" respectively in the calc pids file).

[WeathermanShawn]

Thanks Joe:

I'll do a log in the next few days (weather permitting..:sly:)..

Joe, since the MAF would normally be failed, and the Airflow values will be coming from B0101, is CALC.VEN.VE the same as GM.VETABLE_DMA.VE?

I know the DMA Pids are superior..curious if they are identical?

[joecar]

CALC.VEN.VE would not be available with the MAF failed, so GM.VETABLE_DMA.VE is a direct lookup of the B0101 VE table (VE = g*K/kPa)...

i.e. GM.VETABLE_DMA is to VE what SAE.MAF is to MAF...

[ if you think about this, VE and MAF show symmetry... MAF is indexed by MAFFREQ, VE is indexed by MAP and RPM, they are both looked up in tables ]

So yes, GM.VETABLE_DMA.VE is what CALC.VEN.VE is (i.e. the uncorrected VE).

[WeathermanShawn]

Aaahh..Gotcha..

How about this for Pids..Figured we would not need CYLAIR.DMA?

[joecar]

...

How about this for Pids..Figured we would not need CYLAIR.DMA?That pid list looks good... yeah, we don't need CYLAIR_DMA since MAF is disabled, good point.

[WeathermanShawn]

Hopefully, I can do some logging tomorrow. I'll start with MAF-enabled just to compare calculations.

We also got a volunteer (Forum Member), Mr. P who does a lot of SD and SDCL Tuning who can do some logging/testing.

Once I get a decent log, I'll post up a few more instructions..

[swingtan]

A quick note for the E38....

I tried this some time ago with the E38, but we are missing the DYNAIRTEMP PID. I found you can get get very close with the following though....

"({SAE.RPM}/120)*({E38.APCYL_DMA}*8)"

This uses the ECM's existing Air/Cylinder figure which should factor in the air temp corrections. I'd think that the LS1 controller would be able to use a similar equation.

Simon.


I use it quite a lot to cross reference the VE table and the MAF and it helps point out things like reverberation.

[joecar]

A quick note for the E38....

I tried this some time ago with the E38, but we are missing the DYNAIRTEMP PID. I found you can get get very close with the following though....

"({SAE.RPM}/120)*({E38.APCYL_DMA}*8)"

This uses the ECM's existing Air/Cylinder figure which should factor in the air temp corrections. I'd think that the LS1 controller would be able to use a similar equation.

Simon.


I use it quite a lot to cross reference the VE table and the MAF and it helps point out things like reverberation.
Simon, good point.

E38.APCYL_DMA is the ECM/PCM computation of VE[g*K/kPa]/DAT[K]*MAP[kPa], and probably includes some internal adjustments/corrections.

LS1B equivalents of this are GM.DYNCYLAIR and GM.DYNCYLAIR_DMA.

LS1B also computes the equivalent airflow GM.DYNAIR, we could simply use this diectly, i.e. MAF = {GM.DYNAIR}.

We should probably experimentally log/calculate the following to see how they compare:
MAF1 = {GM.VETABLE_DMA.VE}/{CALC.DAT.K}*{SAE.MAP.kPa}*{SAE.RPM}/15
MAF2 = {GM.DYNCYLAIR_DMA}*{SAE.RPM}/15
MAF3 = {GM.DYNAIR}

[joecar]

Here's a calc_pids.txt file we can use to compare MAF1, MAF2, MAF3.

[joecar]

Shawn,

{GM.DYNAIRTMP_DMA.C}+273.15 now appears in too many calcpids, so it may be simpler to give it its own calc pid, see CLC-00-273.

[joecar]

...

LS1B equivalents of this are GM.DYNCYLAIR and GM.DYNCYLAIR_DMA.

LS1B also computes the equivalent airflow GM.DYNAIR, we could simply use this diectly, i.e. MAF = {GM.DYNAIR}.

...It seems that possibly the PCM may be including temperature adjustment/correction/modeling in these...

[swingtan]

Oh, I just thought of something! If E38.APCYL_DMA is "VE[g*K/kPa]/DAT[K]*MAP[kPa]", then we should be able to reverse the equation to create a calc-pid for the actual charge temp.

RE: comparing the tables, I've done this in the E38....

Green=MAF Airflow.
Turquoise=ECM Calculated Airflow (AIRPERSEC)
Purple=Calc PID based off DYNCYLAIR and RPM.

10924

A closeup of the airflow after the first big throttle close.

10923

Again, it's E38 based but the theory should hold true for LS1 as well.

Simon.

[joecar]

Simon, that's a very good observation, good insight :cheers:

[WeathermanShawn]

So the infamous SD Vs MAF Airflow Correction could be expressed (g/cyl) as:

GM.DYNCYLAIR.DMA-GM.CYLAIR.DMA/GM.DYNCYLAIR.DMA X 100 (%)...???

[Mr. P.]

There was no working or tuning on the truck last night - we had several rounds of quarter to ping-pong sized hail last night and thunderstorms here in Plano. :( So no log file to contribute this morning, sorry.

Mr. P.

[joecar]

So the infamous SD Vs MAF Airflow Correction could be expressed (g/cyl) as:

(GM.DYNCYLAIR.DMA-GM.CYLAIR.DMA)/GM.DYNCYLAIR.DMA X 100 (%)...???

Yes, correct (corrects MAF table from VE table):
(GM.DYNCYLAIR.DMA-GM.CYLAIR.DMA) /GM.DYNCYLAIR.DMA *100[%]

Or like this (corrects VE from MAF table):
(GM.CYLAIR.DMA-GM.DYNCYLAIR.DMA) /GM.CYLAIR.DMA *100[%]

Those would give the correction errors percentages.

Shawn, good observation... this presents a very interesting shortcut. :cheers:

[joecar]

The correction multipliers would be:

MAF multiplier (corrects MAF table from VE table):
GM.DYNCYLAIR.DMA/GM.CYLAIR.DMA

VE multiplier (corrects VE from MAF table):
GM.CYLAIR.DMA/GM.DYNCYLAIR.DMA

i.e. you would be using one or the other, not both at the same time.

[WeathermanShawn]

Joe, per previous conversation I think your concept of SD Vs MAF Airflow correction being similar to ASpark is probably correct..I.E. Scaler percentage.

My unproven theory is that it uses a percentage similar to the 'Charge Temperature Blending' formula. We know that by 4000 Rpms, the VE Table influence is 0%..we just don't know the values 'in-between'. See by the time you hit 150 g/s you are probably near or above 4000 Rpms..

The reason this is important and also pertinent to the thread, is that it would be inherently easier to correct a MAF/VE Table using Airflow Values than pure BENS or perhaps even the DYNAIRTMP.DMA Pid..

Something to think about..:grin:.

[joecar]

The calculated MAF pids look good, the non-corrected values are very close... with MAF disabled the corrected values would converge.

Interesting, look at MAF and DYNAIR :cheers:

Yes, we'll clean up and simplify the calc_pids.txt file.

[WeathermanShawn]

Yea..I see that. It 'smooths MAF Airflow or is filtering/averaging?

So are you thinking we can just use DYNAIR?

The only deviation I see MAF vs DYNAIR is letting off throttle.

Frame 20097 (cursor)..MAF: 59.17 g/s
DYNAIR: 253.73 g/s

I assume we are not lagging by a frame (latest software build).

If valid, it is implying MAF Airflow is changing faster than MAP referenced Air???

[joecar]

We will have to filter out transients, but yes it looks like we can use DYNAIR... let's take a few more logs first.

I don't think the lag is due to the pid evaluation order... there are other transitions where there is no lag.

Is MAF changing ahead of MAP derived airflow...? IDK... may be yes and/or no.

[WeathermanShawn]

There is enough data there to blow one's mind. Best advice I can give is to load up every possible calculated Pid, log it, and study it.

So far my analysis, is that if you are purely talking CALC.VET in reverse, its easiest to do the VE Lookup Table Value concept (your first calc_pids.txt).

Both the DYNAIR and DYNCYLAIR.DMA (g/s conversion) appear to average or 'lag' their calculation. Ironically, fueling (AFR/EQ) follows the Air Pids perfectly..:grin:.

I agree..More logs before reaching final conclusions..

[redhardsupra]

Simon, there's two (significant) wrinkles to your scheme:
1. airflow is based on air charge temp, which depends on bias, which depends on airflow--the sort of relationship that gives psychotic calculus teachers a mental boner. The best way around it I found is to assume that the estimated airflow DMA is close enough, and that due to the nature of the underlying function behind bias, small imprecisions in the estimated airflow wont make that much of an impact on the resulting bias, and thus airflow. So I use that to calc bias, then use bias to do temp, and then airmass/airflow. It's not perfect, but it works very well, comparatively to the other errors involved (especially on the fuel side, without us having a full fuel mass model and the full data set that it requires).
2. If you can solve for temp, you could solve for bias, which would be hugely useful. However, if you're trying to solve for VE/GMVE, and BIAS at the same time, you end up with one equation and two unknowns. Not exactly pretty to solve, especially on the newer ECU's where you got speed in the mix to make BIAS is a 3d function, and then you go the lag filter table that works on some unknown time unit, making it a bloody nightmare. It is doable tho, just fugly.

One experiment I've been trying to get to for years but haven't yet, is using the airflow equations for MAF and SD as each other's constraints. Let me explain: MAF is a smooth 3rd order poly. GMVE is a (mostly) smooth quadratic surface. So I think you could solve for either's MAF's poly cooefficients using GMVE surface parameters as a constraint, or vice versa. Or maybe treat them as simultaneous equations, with airflow/airmass as the common term? Or maybe just set the two airmass models equal to each other, and do an optimization minimizing the sum of error square, using AFRwb and AFRcommanded as the terms to compare? So many (horribly time consuming) ideas, so little time....

If you really want to get insight into the dichotomy between MAF and SD, generate their airmass estimations, and plot them against each other. Then do a residual analysis, and try to pinpoint for which conditions for which the big residuals happen, and you will learn why the formula that weighs MAF/SD's inputs in the hybrid model is the way it is... ;)

[WeathermanShawn]

For what it is worth..

Looks like a slight difference in DYNCYLAIR.DMA (g/s) vs DYNAIR (g/s) (MAFN3).

My assumption is that the DMA pid may have more sophisticated temperature corrections than DYNAIR alone???

[redhardsupra]

different PIDs are going to use different smoothing of component PIDs, so expect slight discrepancies, especially on transients.
also, you really need to stop looking at it as time series, and look at them as populations in scatterplots--WAY more telling of what's going on.

[WeathermanShawn]

As far as this technique (CALC.VET in Reverse or CALC.MAFT), for now I am sticking with Joecar's original suggestion to utilize the VE Table Look-Up and DYNAIRTMP.DMA Pid. It is essentially the CALC.VET formula in reverse and an user can simultaneously log Trims, and MAF Airflow in one log.

Page 1 of this thread has been updated: http://forum.efilive.com/showthread.php?16413-Calculating-MAF-Airflow-From-VE-Table..CALC-VET-In-Reverse&p=145857&viewfull=1#post145857

[joecar]

Hi Shawn,

Thanks for updating...

I made a minor edit to point 3.

Also, should point 5. (filtering) be done before points 3. (CALC.SELBEN->B0101) and 4. (CALC.MAFT->B5001)...?

On your maps, show the units.

:cheers:

[joecar]

Hi Shawn, I made another minor edit, I swapped the text between steps 4. and 5. to match the pics.

[joecar]

Shawn, also, the MAF has to be disabled.

[WeathermanShawn]

Well pretty much completed all the testing on CALC.MAFT, and it works quite well.

Did about a half-dozen runs, some MAF-Enabled (for comparison) and MAF Disabled.

Compared CALC.MAFT formula: "{GM.VETABLE_DMA.VE}/{CALC.DAT.K}*{SAE.MAP.kPa}*{SAE.RPM}/15" vs the following Airflow Pids: (All in g/s units).

"{GM.DYNCYLAIR_DMA}*{SAE.RPM}/15"

"{GM.CYLAIR_DMA}*{SAE.RPM}/15"

"{GM.DYNCYLAIR}*{SAE.RPM}/15"

“{GM.DYNAIR}

Results: CALC.MAFT equation was superior. It accurately reflected the VE/MAF Airflow relationship instantaneously and with no 'filtering'.

The various Airflow Pids all reflect a subtle filtering and averaging in their results. The DMA Pids also reflect a slight difference vs DYNAIR.

Conclusion: The CALC.MAFT equation most accurately reflects the direct relationship between the VE Table vs MAF Airflow/Frequency. The Airflow Pids can be substituted, but during Throttle Transitions the averaging/filtering components show an inconsistency vs CALC.MAFT.

Bottom line is that it can be a very exhausting and time-consuming study to substitute Airflow Pids as a Tuning method for the MAF. IMO, the CALC.MAFT represents the best approach to Tuning the MAF directly from a known VE Table.

[joecar]

Good deal :cheers:

[Mr. P.]

OK I have looked over the suggested calc_pids.txt file in Post #1, and question something:

joecar you express CALC.PE as: "{GM.EQIVRATIO} > 1 && {SAE.RPM} > 1000"

Shouldn't it instead be: "{GM.EQIVRATIO} <> 1 && {SAE.RPM} > 1000"? In my commanded AFR table I use 0.99 to prevent going into closed-loop as I log & do my VE table tuning.

Also, this seems to me to be more a function that determines when the PCM is in open or closed loop (versus whether it is in PE mode or not); and that's fine, I get it, you want to know when the PCM is updating TRIMs and leverage the feedback of those TRIMs during those windows of time when the PCM is calculating/updating them, and that happens when commanded EQR = 1.000, right??

Mr. P. :)

[WeathermanShawn]

Mr. P, quit asking tough questions!:grin:.

Joking of course..We have been trying to figure out a better Pid for PE Mode, but so far no luck. Obviously, you can change any of the Calculated Pids to your own definition. As you stated, this one is designed to know when Trims are being applied, and when they are not.

You can try what you are asking..if that does not work try a PM to JC..its a good question, a little out of my area of expertise..:)

[joecar]

OK I have looked over the suggested calc_pids.txt file in Post #1, and question something:

joecar you express CALC.PE as: "{GM.EQIVRATIO} > 1 && {SAE.RPM} > 1000"

Shouldn't it instead be: "{GM.EQIVRATIO} <> 1 && {SAE.RPM} > 1000"? In my commanded AFR table I use 0.99 to prevent going into closed-loop as I log & do my VE table tuning.

Also, this seems to me to be more a function that determines when the PCM is in open or closed loop (versus whether it is in PE mode or not); and that's fine, I get it, you want to know when the PCM is updating TRIMs and leverage the feedback of those TRIMs during those windows of time when the PCM is calculating/updating them, and that happens when commanded EQR = 1.000, right??

Mr. P. :)That (EQR 0.99) prevents it from doing STFT trimming while in open loop (which is a feature of the COS's, and is enable-able on the non-COS's via B4206).

Yes, exactly... we're trying to find a better way of determining CL/OL.

[joecar]

We may change the PE pid to be a CL pid... after logging a few STATExx pids, it seems we'll have to make a calc pid that uses FUELSYS to determine CL/OL.


I've been logging STATE05 and I see this:
- fuel state shows CL all the time after operating temp is reached;
- DFCO never triggers;

both of those are obviously incorrect.

[Mr. P.]

Mr. P, quit asking tough questions!:grin:...

Lol yeah I'm a PITA that way; blame the developer in me. I'm good at tearing stuff apart, just not always so good at putting it back together! ;)


We may change the PE pid to be a CL pid... after logging a few STATExx pids, it seems we'll have to make a calc pid that uses FUELSYS to determine CL/OL.


I've been logging STATE05 and I see this:
- fuel state shows CL all the time after operating temp is reached;
- DFCO never triggers;

both of those are obviously incorrect.
I totally understand your strategy, you want to leverage TRIMS and those are 'live' only when the PCM is in closed loop. :thumb_yello:

BUT - I thought there was already a PID which told us whether the PCM was in CL or not, because I remember when I first purchased EFILive years ago and I stepped through the tutorial there was a PID whose value was "CLOSED" or "OPEN", I remember exporting it and looking at the data because my truck runs f'n awesome when you first start it (value was "OPEN" and spark was dead steady) and then after 30-seconds or so the motor idled like crap and the spark randomly jumps all over the place and that PID displayed "CLOSED"...

In both the GM and custom operating systems it is True that when they are in CL operation the commanded EQR will be 1.00; however the converse is *not* True (that when EQR = 1.00 the PCM is in CL) because there are a few special situations where the PCM will command 1.00 EQR and be in OL (like at cold startup and restart, when the O2s are cold). But I think in the 'sandbox' we are working in, I would stick with your initial strategy, have your custom PID return a True value when EQR = 1, but I would rename that variable CALC.CLOSED_LOOP or CALC.DO_USE_TRIMS or something like that, but that's admittely nit-picking and a very minor suggestion.

I will go back and look for that closed/open loop variable I saw years ago, but I would not use it because that's just 2 more bytes [channels] eaten-up in your data stream when you can determine the same value from the commanded EQR you are already logging.

Mr. P. :)

PS - on the point you made about B4206, thanks did not know the PCM's OS acted like that - I did not know the PCM would update STRIMS in open loop, for some reason I had it in my head that TRIMS only updated when in closed-loop. ???

[joecar]

Yes, the pid SAE.FUELSYS gives OL/CL for each bank... and it takes up 2 pid channels... we're looking for something that takes up 1 pid channel (or less) and is bank-less.

[joecar]

Yes, we were thinking of renaming CALC.PE to CALC.OL or CALC.CL (and then rippling this thru the tutorial(s)).

[Ninety8C5]

11029

Is this (Fuel Loop Status) what you were thinking of?

[Mr. P.]

That would work great - but which is the low bit, and which is the high bit?! I'm starting to get a little critical of the documentation!!!

The value we are after is "Fuel Trim Learn" - but is that bit #3, or bit #6?

Actually, DFCO and Fuel Loop Status would be handy as well, you could craft some really trick logic knowing those three values; i.e. "when fuel trim learn is enabled, and decel fuel cutoff is inactive, and fuel loop status is closed - then use TRIMS, else use WB02" or something like that. ???

Or just K.I.S.S. and use TRIMS when EQR = 1.00 and MAP between 40 and 85, or some such thinking.....

Mr. P.

[joecar]

11029

Is this (Fuel Loop Status) what you were thinking of?When I look at my logs, Fuel Loop Status seems to lock at CL once warm up is achieved...

I see that when SAE.FUELSYS indicates OL on banks A and B, Fuel Loop Status still indicates CL.

[joecar]

That would work great - but which is the low bit, and which is the high bit?! I'm starting to get a little critical of the documentation!!!

The value we are after is "Fuel Trim Learn" - but is that bit #3, or bit #6?

Actually, DFCO and Fuel Loop Status would be handy as well, you could craft some really trick logic knowing those three values; i.e. "when fuel trim learn is enabled, and decel fuel cutoff is inactive, and fuel loop status is closed - then use TRIMS, else use WB02" or something like that. ???

Or just K.I.S.S. and use TRIMS when EQR = 1.00 and MAP between 40 and 85, or some such thinking.....

Mr. P.The bits are numbered starting at zero from the bottom and going up...

see here:


Embedding STATE/TSTATE pids in calc pid:
showthread.php?t=12081 (http://forum.efilive.com/showthread.php?t=12081)
showthread.php?p=20356 (http://forum.efilive.com/showthread.php?p=20356)


No, not Fuel Trim Learn, this indicates when trims are being learned or not, it goes on and off during Closed Loop.

Yes, those would be very very handy, but:
- DFCO does not seem to work, the bit is always off,
- Fuel Loop Status reads OL during warm up and then reads CL always after that;
keep in mind that it is the PCM that is not filling in these bits.

Yes I agree, that is how we arrived at the CALC.PE pid (altho we misnamed it).

[WeathermanShawn]

The only other brainstorm I had was to use an 'iff' for the PE Enabler Tables (via look-up).
I.E., iff RPM & TPS% this..then..

Every other solution is a lot of work. Remember, we just want to know if LTFT's are active.
You can always default LTFT's to 1.00 and use WO2BENS for the entire practice.

We may be stuck with a 'stupid', but easy solution as is..

Question is, how does the PCM determine when it is in PE Mode?

[joecar]

The PCM has the advantage that it knows what it is doing and we do not... :hihi:

us -> :chair: <- PCM


altho, the 411 PCM is way simpler/easier than the E38/E67 and others.


We can safely say that when GM.EQIVRATIO is not 1.00 then fuel mode is Open Loop...

there are a few exceptions to this, but when EQR is not 1.00 then trimming cannot proceed.

[joecar]

We could define either of these:
- CALC.OL = "{GM.EQIVRATIO} != 1"
- CALC.CL = "{GM.EQIVRATIO} == 1"

whichever one reads more better/correctly (I like the first on better);

then we would use this as the condition in the SELBEN iff.

[joecar]

...
Question is, how does the PCM determine when it is in PE Mode?There is a PE/enrichment bit in one of the TSTATE pids, it appears to not correspond to actual PE active... I meant to log this some more;

(and what is it doing in a transmission TSTATE pid).

[WeathermanShawn]

Joe, you will have to help me out a little on the decoding..:grin:.

The only issue I recall, is that when the car first starts up..EQ reads >1.00, but you are not in PE Mode..or closed-Loop..

[WeathermanShawn]

There is a PE/enrichment bit in one of the TSTATE pids, it appears to not correspond to actual PE active... I meant to log this some more;

(and what is it doing in a transmission TSTATE pid).

Well, here were a couple of logs I did with TSTATE5..Seemed inconclusive, but maybe I missed something..:confused:..Is that one you needed?

[joecar]

Joe, you will have to help me out a little on the decoding..:grin:.

The only issue I recall, is that when the car first starts up..EQ reads >1.00, but you are not in PE Mode..or closed-Loop..Hey no worries, I'll like swimming in the math... :hihi:


Well, here were a couple of logs I did with TSTATE5..Seemed inconclusive, but maybe I missed something..:confused:..Is that one you needed?I look at those on my other PC later.

It seems that all the single channel pids that could yield a useful indicator don't work...

we might have to either use EQIVRATIO (which we already log, so it is for "free") or also use FUELSYS (which uses up 2 pid channels).

[joecar]

Hi Shawn,

Attached here is a new calc_pids.txt which replaces CALC.PE with CALC.CL just as we discussed today.


Edit: I found an error due to my editing skills :doh2: (== should be =), so I corrected and re-attached the file.

[joecar]

Update: Shawn has updated the calc_pids.txt file in post #1.

[redhardsupra]

@joecar, could you please rewrite
"{SAE.MAF.gps}*({GM.DYNAIRTMP_DMA.C}+273.15)/{SAE.RPM}/{SAE.MAP.kPa}*3445.2/displacement()"

with more parenthesis, right now i'm a bit fuzzy on order of operations, especially the MAF/MAT/RPM/MAP...and then is the whole thing *3445.2/VOL, or just the MAP?
or better yet put it all on one division line, so there is no confusion, like ( a * b * c) / (d * e * f)?

[joecar]

@joecar, could you please rewrite
"{SAE.MAF.gps}*({GM.DYNAIRTMP_DMA.C}+273.15)/{SAE.RPM}/{SAE.MAP.kPa}*3445.2/displacement()"

with more parenthesis, right now i'm a bit fuzzy on order of operations, especially the MAF/MAT/RPM/MAP...and then is the whole thing *3445.2/VOL, or just the MAP?
or better yet put it all on one division line, so there is no confusion, like ( a * b * c) / (d * e * f)?Hi Marcin,

It follows the usual left-to-right associativity rules...



being the first factor places that factor in the numerator;
* preceding a factor places that factor in the numerator;
/ preceding a factor places that factor in the denominator;


i.e. the / preceding a factor means invert the factor and multiply to the current product;

so think of a*b*c/d/e/f as a *b *c /d /e /f which is same as a*b*c/(d*e*f) or (a*b*c)/(d*e*f).


So the whole thing is *3445.2/VOL.

[joecar]

a*b/c*d = a*(b/c)*d

a*b/c*d/e = a*(b/c)*(d/e)

[joecar]

Here is an alternate calc_pids.txt file that separates DAT out as a separate pid: calc_pids.txt (http://forum.efilive.com/attachment.php?attachmentid=12682&d=1329189400)

This file has pids for both the Calc.VET and Calc.MAFT tutorials.

[voda1]

Here is an alternate calc_pids.txt file that separates DAT out as a separate pid: calc_pids.txt (http://forum.efilive.com/attachment.php?attachmentid=12682&d=1329189400)

This file has pids for both the Calc.VET and Calc.MAFT tutorials.

Link does not work - shows:
vBulletin Message Invalid Attachment specified. If you followed a valid link, please notify the administrator (http://forum.efilive.com/sendmessage.php)

[joecar]

Link does not work - shows:
vBulletin Message

Invalid Attachment specified. If you followed a valid link, please notify the administrator (http://forum.efilive.com/sendmessage.php)See post #1 for the latest calc_pids.txt file.

[smellyflange]

gday all just trying just trying to set up my pids list and when it comes to the calculated maf pid all i seam to have is a calculated maf,not corrected.yet it is not supported by my pcm.im running os 01290005 osid v5.how will this affect doing calc.maft.
thanks

[joecar]

Do you see the pid CALC.MAFN...?

Does it have a red thru it...?


On the PIDs tab, click on the column titled "Parameter" (to sort the pids by this column), and scroll down until you see CALC.MAFN and CALC.MAFT...

if either of those have a red X, then do rightclick->More Info to see which other pids need to be selected.

[smellyflange]

thanks for the reply joecar
right click did the job i had to add
dynamic air temprature from the tuning system calc.dat
i had dynamic air temprature from the tune system gm.dyncylair_dma.
it seams to work now.time to log.
thanks again.

[joecar]

Ok cool :cheers:

[oreobadr]

I tried to use those PIDS but it does not allow me to do it as I think it is an old version of EFI live. Am I doing something wrong or does it need to be updated?

[joecar]

I tried to use those PIDS but it does not allow me to do it as I think it is an old version of EFI live. Am I doing something wrong or does it need to be updated?
Which V7 build version...?

Do you have V1 or V2...?

Which year/model/vehicle...?

Post some screenshots showing what is going on.

[oreobadr]

I have a V2, its a 2002 pontiac Trans am, and its the V7.5. Its when I download the PID text file and try and open it in the tuning tool, there are no PIDs present. Also, when I try and add the PIDs by myself some of the PIDs are not there to add.

[CHEVYHD496]

Ok, please go easy on me as I'm new to this! When you say "disable maf", how do I disable it? Then I do not have a WBO2, so can I then still use this setup to tune? Thanks!

[joecar]

I have a V2, its a 2002 pontiac Trans am, and its the V7.5. Its when I download the PID text file and try and open it in the tuning tool, there are no PIDs present. Also, when I try and add the PIDs by myself some of the PIDs are not there to add.
Did you copy the calc_pids.txt file ti the folder User Configuration...?

Did you name it calc_pids.txt...?

In the scantool, on the PIDs tab, click on the column heading of the right hand column to sort by tbat column, scroll down, look for those pids, do you see them...?

~ posted by phone ~

[joecar]

Ok, please go easy on me as I'm new to this! When you say "disable maf", how do I disable it? Then I do not have a WBO2, so can I then still use this setup to tune? Thanks!
Disable the MAF by causing a MAF DTC to immediately show up...

this can be done in any one of these ways:
- unplug MAF if you have 3-wire connector (i.e. IAT is on separate connector).
- edit C2901-3 to force MAF to fail.

You may have to edit C6001 to cause P0101-3 to trigger on 1-Trip.

If you don't have a wideband then you will only be able to correct VE for Closed Loop, i.e. low/light throttle only.

~ posted by phone ~

[oreobadr]

Can this be done without a wideband O2 sensor?

[joecar]

Can this be done without a wideband O2 sensor?Without a wideband, you can do only CL (meaning light throttle), so you won't be able to reach high into the upper MAF table and upper VE table.

[voda1]

In-Memory-of-Shawn-Sankey (http://forum.efilive.com/showthread.php?16849-In-Memory-of-Shawn-Sankey)
5. Paste-with-labels the new CALC.MAFT map into Table B5001 in your tune file:

( ignore this step if you're running SD, i.e. ignoring MAF and doing VE table only )

http://i1126.photobucket.com/albums/l609/weathermanshawn/CALCMAFT.png

(to limit the cell display width to something sensible, in the map properties goto the Cell tab and look at Constrain Cell Size)



Can't find a CALC.MAFT map. What is the data in the Value column above?

[joecar]

Can't find a CALC.MAFT map.
see attached zips for maps.


What is the data in the Value column above?For the MAF map, the Column pid can be any pid you logged... for convenience I make it GM.MAFFREQ (same as the Row pid).

[Bill00Form]

Can someone please provide the necessary pids because the pictures on the first post are gone. Thanks

[joecar]

Hmmm, I hate when PhotoBucket does that.

Look in the calc_pids.txt file, log all the pids mentioned in there.

There's a pdf of Calc.VET procedure here somewhere, let me find it.

[aaronc7]

Hmmm, I hate when PhotoBucket does that.

Look in the calc_pids.txt file, log all the pids mentioned in there.

There's a pdf of Calc.VET procedure here somewhere, let me find it.

Joe, here are the 4 pics in the OP without the photobucket watermark nonsense. Use them to update the OP if you'd like and I think it would be wise to host them directly on the website so it's not reliant on an external source. I'll do the same in the VET thread.

https://i.imgur.com/StdYwMe.png
https://i.imgur.com/vR2YyoO.png
https://i.imgur.com/17Ml0Ab.png
https://i.imgur.com/wEzVfSW.png

[joecar]

I'll look over the next few days.

[Scatfish]

I'm glad you guys have the pics. I'm going over this to try to set up to tune. I finally have my WB up and running. I want tot data log now and start the process.
Thank you!!

[joecar]

Thanks aaronc7.

I'm going to try to make the procedure self-contained...

[THEFERMANATOR]

see attached zips for maps.

For the MAF map, the Column pid can be any pid you logged... for convenience I make it GM.MAFFREQ (same as the Row pid).
Is there any way we can get the Calc-MAFT-maps.zip file added to the 1st post? I know it took me awhile to find the maps file when I tried this method.

On a side note, when I did this method the VE table is spot on, but the MAF table from this method was way high. It had me adding about 7-12% to the MAF table I came up with from doing the CALC.VET method which is just about spot on.

[joecar]

see attached zips for maps.

For the MAF map, the Column pid can be any pid you logged... for convenience I make it GM.MAFFREQ (same as the Row pid).

I also attached the zips to post #1.

[ticker]

Looking for some insight into the calc_pids.txt. I've been away from this for an extended amount of time and I'm trying to brush off the cobwebs. A lot has changed, including the version of EFILive from V7.5 to V8.

A couple generic questions.
1) It seems every operating system may support it's own selection of PIDs, no two the same ? I currently have the 'pleasure' of working with OS 09381344.

2) Regarding the calc_pids.txt, what should the name of the file and location be for V8 ? Here are some options I seem to have available, assuming this file should not go under "C:\Program Files (x86)\EFILive\V8"
a) C:\Users\xxxx\Documents\EFILive\V8\User Defined Cax8
b) C:\Users\xxxx\Documents\EFILive\V8\User Defined PIDs
c) C:\Users\xxxx\Documents\EFILive\V8\Config\UserCalc ulatedPids.ini
d) C:\Users\xxxx\Documents\EFILive\V8\Config\PIDs

3) I also assume any calculated PIDs defined in the "calc_pids.txt" will only work if all the dependent PIDs are available in the operating system in use.

4) I'm also trying to log WBO2 from an Innovate LM2 through the EFILive external inputs. Oddly enough I see voltage on the Innovate output wires, but when plugging them into the EFILive V2 input (AD1) I see no data on the AD1 PID ? Any thoughts as to what I'm doing wrong ?