Should I Download to a Later Software Build

[Steve Bryant]

I am now retired and working on my bucket list. One of the things on that list is to get re-acquainted with EFILive and to refine the tune on my 2000 GMC Yukon XL (AKA Suburban). I was one of the original Flash/Scan Beta Testers and at that time kept up with changes daily, but that's been about ten years ago. My vehicle has its original LQ4 6.0 L engine and 4L80E transmission.

Here are my questions:


Is there a compelling reason to update my V 7.5.7 Build 180 software for scan and tune?
If so, is there a specific build that you could recommend for me?
Do you have any other general recommendations to re-familiarize myself with the software?


I've flashed my PCM about 200 times and logged at least that many scan files, so I'm familiar with how things work, but most of that was seven to ten years ago and I also did some work in 2011, shortly after I retired.

Thanks in advance!

Steve

[joecar]

Hi Steve,

Welcome back :cheers:

Do you have FlashScan V1 or V2...?

If you have FlashScan V1, then you could stay at V7 build 180.

Do you have a wideband (if so, which one...?)...?


See post #1 of this thread, it introduces an interesting tuning concept (correcting MAF and calculating VE at the same time), and it exercises you on logging, map creation, how to use wideband lambda, and calibrations relationships (see linked material):

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

[joecar]

More info:

CALC-VET-Summary-Notes (https://forum.efilive.com/showthread.php?16280-CALC-VET-Summary-Notes)
Summary-Notes post #29 -> Tuning Method Comparisons (https://forum.efilive.com/showthread.php?14188-Summary-Notes&p=148674&viewfull=1#post148674)
Summary-Notes post #4 -> Calibration Parameter Relationships (https://forum.efilive.com/showthread.php?14188-Summary-Notes&p=127353&viewfull=1#post127353)
Summary-Notes post #37 -> Semi-Open Loop (https://forum.efilive.com/showthread.php?14188-Summary-Notes&p=195020&viewfull=1#post195020)
Summary-Notes post #38 -> IFR Calculations (https://forum.efilive.com/showthread.php?14188-Summary-Notes&p=199734&viewfull=1#post199734)

[Steve Bryant]

Joe,
Thanks very much for such a lightning-fast and helpful reply! I will study all of the threads that you have linked. I have FlashScan V1 and a PLX-300 analog WBAFR.

The main culprit that caused me problems in the early days (2004/2005) when I was trying to set up my VE Table and calibrate my MAF was that I had B4206 enabled (Use NBO2 with Open Loop Commanded Fuel Table) because that was the default setup on truck tunes for the PCM. The influence or consideration of B4206 was never discussed very much if at all in those days. On the tuck tunes of that era, everything was set up to discourage/eliminate open loop operation whenever the NBO2 has come up to temperature. PE wasn't set up in any way from the factory in any way (60 second time delay setting for B3608, among other obstacles). I've never had the time or taken the time to get all of this straightened out, so I'm trying again now.

Regarding the Calc.VET thread, I so appreciate the contributions that Shawn made before his untimely death. There is a great deal of valuable information in that thread and I've already been reviewing it during the last few days.

One thing that I think is problematic in Shawn's simultaneous approach of MAF/VE Table calibration is that the PCM always is using the MAF table and allows the VE Table to modify the mixture only during throttle/MAF transitions and only below value set in B0120. In order to get an accurate setup for your tune, I think that you must calibrate speed density and MAF separately. log data using Speed Density/VE Table to control the mixture (MAF/LTFT/STFT/NBO2 all disabled) and then repeat the procedure allowing MAF to exclusively control the mixture (fail MAP by setting B0120 to 0 RPMs or some other means) with LTFT/STFT/NBO2 all disabled.

[joecar]

...
The main culprit that caused me problems in the early days (2004/2005) when I was trying to set up my VE Table and calibrate my MAF was that I had B4206 enabled (Use NBO2 with Open Loop Commanded Fuel Table) because that was the default setup on truck tunes for the PCM. The influence or consideration of B4206 was never discussed very much if at all in those days. On the tuck tunes of that era, everything was set up to discourage/eliminate open loop operation whenever the NBO2 has come up to temperature. PE wasn't set up in any way from the factory in any way (60 second time delay setting for B3608, among other obstacles). I've never had the time or taken the time to get all of this straightened out, so I'm trying again now.
...
Yes, the early AutoVE procedure was based on the Camaro/Firebird tune files, in these B4206 was turned off and PE enabled immediately.



...
One thing that I think is problematic in Shawn's simultaneous approach of MAF/VE Table calibration is that the PCM always is using the MAF table and allows the VE Table to modify the mixture only during throttle/MAF transitions and only below value set in B0120. In order to get an accurate setup for your tune, I think that you must calibrate speed density and MAF separately. log data using Speed Density/VE Table to control the mixture (MAF/LTFT/STFT/NBO2 all disabled) and then repeat the procedure allowing MAF to exclusively control the mixture (fail MAP by setting B0120 to 0 RPMs or some other means) with LTFT/STFT/NBO2 all disabled.
The Calc.VET method uses the transient filter to filter out any VE usage... you can rely on the filter, or you can set B0120 to zero to eliminate VE usage (I do it either way).

Note the following:
- Calc.VET is similar to AutoMAF.
- Calc.MAFT is similar to AutoVE.

The Calc.MAF method requires that the MAF be disabled (since there is no other way ensure VE only).

Also, Calc.VET and Calc.MAFT can be tailored to use wideband only (i.e. use CALC.WO2BEN only).

In most cases, when I do Calc.VET I find that the resulting VE table is fairly close, it may need minor retouching at idle, and some very minor correcting with the wideband if any... i.e. in most cases the VE and MAF match closely enough to get almost zero LTFT's when running SD or MAF independently.

Also, the Calc.VET produces a suitably close VE table that can be used for doing AutoVE (i.e. we're using the MAF to calculate VE, and if we tuned correctly then both should produce the same result).

The beauty of Calc.VET (and this is the core of Shawn's ideas) is that without much (any) editing of the tune, you could get both MAF and VE very close in a single log... most of the effort is in making sure the wideband is installed and working correctly; and along the way. Shawn and I discovered that this also introduces the newbie to various tuning concepts (using lambda rather than AFR, calculating VE from corrected MAF, dynamic air temperature, VE/MAF transition, PE) and the scantool/tunetool mechanics (i.e. creating maps properly, transient filtering, pasting, smoothing, etc... and judging whether data was good or bad) by means of expanding the "tutorial" (by linking to to various explanatory material)... i.e. multiple goals: providing a one-step tuning method and teaching the user the concepts and usage of the EFILive tools.

[joecar]

Some advanced tuners will first correct the MAF using wideband and then use a spreadsheet to calculate a VE table (as a starter table to do VE correction)... Calc.VET does this same thing using the EFILive tools (this is Paul's intent, to not have to dive into a spreadsheet).

BTW: the EFILive tools also allow going the other way (only for some LS1B OS's): first correct VE and calculate MAF table from corrected VE.

[Steve Bryant]

Joe,
Thanks very much for your responses and taking the time to write-up the details. This is helpful to me and should be helpful to others!

[Steve Bryant]

The Calc.VET method uses the transient filter to filter out any VE usage... you can rely on the filter, or you can set B0120 to zero to eliminate VE usage (I do it either way).



Joe,
You have stated the effect of setting B0120 to zero, where I did not. So for anyone reading this in the future, please use Joe's explanation.

Also, I think that I'm going to use the Calc.VET approach in the next tuning cycle.

[Steve Bryant]

I've been studying that joecar provided this past week. I've also braved the frigid weather here in Kansas and logged some data a read/uploaded the existing .tun file in my PCM...so far, so good. However, my GM.* PIDs are missing in action from my PID tab. But, the GM.* PIDs are right where they should be in the pid_info.txt file (see attachments). How do I get my GM specific PIDs back? I miss them and I need them.

Thanks,

Steve1766517666

[joecar]

Hi Steve,

Click on the column heading "Parameter" once or twice to sort by that column, then eyeball down that column until you see your pids.

Also, you may have to do a Validate Pids (while connected to PCM).

[Steve Bryant]

Hi Steve,

Click on the column heading "Parameter" once or twice to sort by that column, then eyeball down that column until you see your pids.

Also, you may have to do a Validate Pids (while connected to PCM).

Thanks Joe, however I did click the "Parameter" column heading until they were sorted in ascending alpha order for the first screen shot of the PIDs tab. Also, note that "Supported" check box is not checked/ticked, so that should give me all of the possible PIDs in the table (both supported and unsupported by my PCM/OS). Also, I did Validate PDIs several times when I was logging some data. I got anywhere from 55 to 65 PIDs as being available. It is my recollection that several years ago, I would get about 100 valid PIDs.

One of the things that I can't figure out is why the GM specific PIDs don't at least show up as being available but unsupported on the PIDs (F8) tab since these PIDs are clearly in the pids_info.txt file.

Steve

[joecar]

Steve,

Try this:

in scantool, do this:
- File->Select Controller (select LS1B),
- File->Enter VIN (enter your VIN),
- connect to vehicle (green button at upper LHS),
- on PIDs tab uncheck Supported PIDS,
- Info->Validate pids.

If that does not work, then delete/rename the pid_info.txt file, and repeat the above.

[Steve Bryant]

Thanks Joe, I'll give it a try and let you know the results!

Also, just to clairify; if I rename the existing file to something like old_pid_info.txt and go through the steps you've recommended, should EFILive generate a new/replacement pid_info.txt file?

[joecar]

Yes, EFILive should generate a new pid_info.txt file.

[Steve Bryant]

Joe,
A few added thoughts:

1. If this doesn't work (steps listed in post #12, above), what do you think that I should do next?

2. If I create a new directory/folder like (EFILive Build 2XX) in Documents and download a more current version of the software to see if this resolves the GM Specific PIDs issue, would this tell you something more? I'm not opposed to going to a newer, stable build. The only reason that I was hesitant was the thought of an initial learning curve when I'm just getting my head back into the log, tune process and trying a different way of tuning like CALC VET.

3. If I do go to a newer build, what build would you recommend? I've thought about V7.5.7, Build 262.

4. It's interesting to note that I can't see any GM specific PIDs on any of my old files or even the sample logged data (*.efi files) on either my laptop or desktop computers. I used to be able to do this as I would almost always log KR and some others like commanded AFR (see attached file).

5. I'm running Windows 7 on both laptop and desktop, but my drivers are possibly not the most current...they all have file dates of 2011 or earlier.

Thanks again. I know that my many questions probably try your patience!

Steve

[joecar]

Hi Steve,

With Win7/Win8 you have make sure that you have privilege to write to system folders/directories before installing the V7 software (i.e. log in as Admin, and make sure that the system folders allow all privileges to Admin).

Also make sure your EFILive software license registration info has been entered (Help->Register).

I would download and try V7 build 269 from here: Update Oct 28 (https://forum.efilive.com/showthread.php?24830-Update-Oct-28-2014)

I'll take a closer look at your files.

No worries... it is odd that you can't view old log files, we'll figure out what is happening.

[Steve Bryant]

Joe,
I haven't loaded V7.5.7 Build 269 on my Laptop yet, but I went ahead and replaced Build 180 with 269 on my desktop and I now have my GM specific PIDs back (see attachments). :cheers: I'll now make the changes on my laptop and validate PIDs, log some data, etc. and report back. Right now, the problem appears to be some fluke in my Build 180 software.

[Steve Bryant]

Now for the software on the laptop. I first tried the steps in post 12 and nothing worked. Then I replaced build 180 with build 269 and everything seems to work normally now. After validating the PIDs with the scan tool connected and Build 269, I now have 365 detected PIDs (one for each day of the year)! I'm sure that I'll have more questions, but right now, I'm a very happy camper! :rotflmao:

BTW, why did the .tun extension change to .ctz?

Thanks so much, Joe!

[joecar]

.ctz = more compact compression compared to .tun


tunetool opens .tun and .ctz, saves as .ctz (i.e. you can convert your .tun files to .ctz )

[Steve Bryant]

I've been using Shawn's CALC.VET Tuning Tutorial (http://download.efilive.com/Tutorials/PDF/Calc.VE%20Tuning%20Tutorial.pdf) and the Calc.VET thread (https://forum.efilive.com/showthread.php?15236-Calc-VET-correcting-MAF-and-calculating-VE-(in-single-log)) as a guide. Since my OS (09381344) doesn't have some of the PIDs that I need, I replaced my calc_pids.txt file with the one in the attachment (from section III in post 1 of the Calc.VET thread with my modification for my PLX analog AFR). Note: I've substituted my PLX analog Lambda calculation (CALC.AFR_PLX1/14.68) in the CALC.WO2BEN formula. However the following calculated PIDs don't work (they all hinge on CALC.WO2BEN being correct): CALC.WO2BEN, CALC.SELBEN and CALC.VET.

Please take a look at my calc_pids.txt and tell me what I'm doing wrong.

Thanks again,

Steve

PS
I've logged some data and uploaded and downloaded tune files and that's all going good.

[joecar]

Hi Steve,

In CLC-00-110, replace {CALC.AFR_PLX1/14.68} with {CALC.AFR_PLX1}/14.68

i.e. the parentheses go immediately around the pid name.

[Steve Bryant]

Also Joe,
Since I have now upgraded to the current build of V 7.5 Tune/Scan, should I start asking further questions in one of the forums related to VET Tuning? If so, which one?

Thanks

[Steve Bryant]

Hi Steve,

In CLC-00-110, replace {CALC.AFR_PLX1/14.68} with {CALC.AFR_PLX1}/14.68

i.e. the parentheses go immediately around the pid name.

OK, I'll fix it.

Thanks Also, as I mentioned in post 22, should I switch my questions to one of the other VET tuning threads?

[joecar]

OK, I'll fix it.

Thanks Also, as I mentioned in post 22, should I switch my questions to one of the other VET tuning threads?Steve, you can use this thread, it will keep the context consistent.

:)

[Steve Bryant]

Joe,
Regarding some quandaries that I raised back in Post 20 of this thread, I've gotten CALC.W02BEN AND CALC.SELBEN straightened out. I've also gotten my MAF Table in good shape {B5001} since I've disabled {B4206} (enable NBO2 when in open loop). That has caused me untold grief as I've mentioned before.

Questions:
1. I still cant get CALC.VET (or CALC.VEN) to work since I don't have GM.DYNAIRTMP as an available PID with my OS. I've substituted the alternate calc.pids.txt which has been further modified to reference my analog PLX WBO2 from #6 in Section III of post 1 in the CALC.VET thread. However the VEN/VET calculations still don't work. I'm wondering where the "B4901 ECT/IAT blend factor lookup" information comes from and if that is the missing link. I can select B4901 as a valid pid, but when I look at CALC.VEN/VET the More Info query says:

Dynamic Air Temperature
{CALC.DAT}
Expression:
°C = {SAE.IAT.C}+({SAE.ECT.C}-{SAE.IAT.C})*{CALC.B4901}
is VALID
Dynamic Air Temperature
{CALC.DAT}
Expression:
°F = {SAE.IAT.F}+({SAE.ECT.F}-{SAE.IAT.F})*{CALC.B4901}
is VALID
Dynamic Air Temperature
{CALC.DAT}
Expression:
K = {CALC.DAT.C}+273.15
is NOT valid because:
Required parameter {CALC.DAT.C}, at position 13 is not selected.
PID value cannot be determined because
the following error would occur:
Expression not valid: Required parameter {CALC.DAT.C}, at position 13 is not selected.
Dynamic Air Temperature
{CALC.DAT}
Expression:
R = {CALC.DAT.F}+459.67
is NOT valid because:
PID value cannot be determined because
the following error would occur:
Expression not compiled
　

Can you help?

2. Once I get CALC.VET to work and my MAF table is correct, will I be able to populate the entire Main VE Table {B0101} in the tune?

Thanks in advance. I really getting somewhere, it's just a multi-step journey.

Steve

[joecar]

Hi Steve,

Post your calc_pids.txt file here.

Also, post a screenshot of the PIDs tab.

[Steve Bryant]

Joe,
1. Here are the calc_pids.txt file and the screen shot.

2. Also, related to the values for the charge air temperature for my truck. They're fairly different from the ones presented in the alternate calc_pids.txt file (see screen shot). Should I substitute my values to perhaps have more fidelity for my vehicle? I've created an attached file, Yukon_calc_pids.txt to show you how I would do this. Of course, I would change the file name to calc_pids.txt in the User Configuration directory if this is what I end up dong.

Thanks for your help!

Steve

[joecar]

Hi Steve,

1. I'm going to try out your yukon calc_pids.txt file shortly...

2. Yes, use your own B4901 values... when you do this, on the PIDs tab do not select GM.DYNAIRTMP_DMA, instead select CALC.B4901 and CALC.DAT.

No worries :cheers:

[Steve Bryant]

Joe,
I have fooled around with the selected PIDs (F8 Tab) and now I have the apparent capability of determining CALC VET. I don't have a red X anywhere and I am at 23 channels, 30 PIDs. I've also revised my Yukon calc_pids.txt file to add the last two column values that I had previously omitted. Please take a quick look, but I think that I'm ready to log data now.

[joecar]

Yes, no red X's, you're ready to log.

[Steve Bryant]

Joe,
I've done several things in the last week.



I've logged some data since I didn't have any red x's with my original OS (9381344) which has a backup VE table.
I've re-flashed my PCM to a newer OS (12208322) that does not have a backup VE table. I transferred all pertinent parameter values to the new OS and everything seems to work fine plus I now have even more PIDS (383).
I've logged data several times with the following results:

Refined MAF Sensor Calibration using LTFT BEN Data
Determined that my ten year old PLX WBO2 displays but is inaccurate using bidirectional control of AFR while monitoring WBO2/Commanded AFR/NBO2 Voltages (sensor is probably dying so I've ordered a new generation unit...see attached screen shot)
Determined that I can't get the Calculated VET BEN to tell me anything to correct my existing VE table.



Questions:
Please review the attached logged data file to see if you can determine what I am doing wrong. I can't get the forum to upload my CALC.VET.map file as I am told that it is an invalid file type.

Thanks,

Steve

[joecar]

Hi Steve, also post the tune file that produced Log_0020.

[Steve Bryant]

Joe,
I inserted the tune into post 31 (https://forum.efilive.com/showthread.php?24793-Should-I-Download-to-a-Laterr-Software-Build&p=213945&viewfull=1#post213945)above so that the files would be bundled in the same post.

Steve

[joecar]

Hi Steve,

Are you using CALC.WO2BEN rather than CALC.BEN_PLX1...?

MAF map looks good (SELBEN is very close to 1.00).

[joecar]

There is not enough data spread to calculate a sufficiently wide VE table...

you could either log more data (use throttle progressively, use brakes to increase load at lower throttle openings)...

or you could do a Calc.MAFT (disable MAF, use logged data to correct VE table, ignore calculate MAF since MAF is already very good).

[joecar]

I made some changes to you VE table based on the calc'd VE map from your log file...

but for some reason the forum software is not letting me upload the file...

I'll switch to Mac OS and see if I can upload...

[joecar]

Here is your file with my VE changes...

( hmmm, my Mac OS is running a different version of Java )

[Steve Bryant]

Joe,
Thanks for your investigations. Here is some additional information:


I can't open the file you sent in your post 37. First I tried to click on the hyperlink and Windows does not associate this file with EFILive Tune. Although, I can open other tunes that are on the forum with no problem. So, I saved the file and moved it to my desired BIN sub-folder/sub-directory and I still can't open it with EFILlive Tune. I manually assigned the file to be opened with Tune, and Tune starts up but it doesn't open the file so that I can look at the B0101 table.
Now to your question in post 34. I'm trying to use a CALC.VET map, but all the results show a zero (0.00) change is needed (see attached .jpg file). I expected to see a fairly complete VE table that had been calculated based on dynamic airflow that was temperature corrected and this is what confused me. This map is based on SEL BEN and when I look at SEL BEN, it appears to choose from "iff({CALC.CL}, {CALC.LTFTBEN}, {CALC.WO2BEN})". I'm also attaching my calc.pids.txt file and you can see that I made WO2BEN associate with the value from my PLX WB AFR which I've determined has failed and always is reporting stoic (see screenshot in post 31).
Considering that my WO2BEN and LTFT are both reporting stoic mixtures, that's likely why I getting zeros in the table. However, this brings me to the fundamental questions that I've always had with the CALC.VET method:


If the CALC.VET method relies on fuel trim or wideband data that is predominately controlled by the MAF lookup table to determine the engine fueling at any given time , how can this approach work to get valid values in B0101? I expected this CALC.VET approach to truly calculate data to fill in the B0101 table.



Wouldn't I be better off to just fail the MAF and do a Speed Density tune? Once I've re-enabled the MAF I'd have a reasonably accurate VE Table and MAF table?

[joecar]

Hi Steve,

1. you would need the latest V7 software from here (https://forum.efilive.com/showthread.php?24830-Update-Oct-28-2014).

2. to use % units you have to enter engine displacement (see Calc.VET thread post #1)... it is easier/better to use g*K/kPa units instead of % (more technically correct)... I don't yet think that your wideband has failed.

3. this method uses LTFT when in CL and wideband when not in CL (CALC.SELBEN selects CALC.LTFTBEN or CALC.WO2BEN depending on CALC.CL). In many cases it does calculate a correct VE table (I have seen a few where it failed, but only a few). Give it anther try, this time use g*K/kPa for the VE map.


Later, you can still do an SD tune (by tailoring the Calc.MAFT prodecure to ignore the step that calculates a new MAF).

You wideband has not failed, the log 20 file shows a good signal from it.

[Steve Bryant]

Joe,
Thanks for your reply! Also, happy holidays to you sir!

1. I know that it's hard to keep up with all the questions that everyone poses, but I upgraded to Build 269 of EFI Live 7.5 about a month ago.

2. I'll look into the use of g*K/kPa.

3. I'll give it another try.

The reason that I believe my wideband has failed is shown in the screenshot in post 31 and linked here (https://forum.efilive.com/attachment.php?attachmentid=17841&d=1419208569). I was using the bidirectional controls to control mixture. initially, I left it at 14.7:1 briefly (WBAFR showed stoic and NBO2 voltages still were switching back and forth as they should at about stoic). Then I went to a bi-di controlled commanded a rich AFR of about 13.0:1 (WBAFR showed stoic while the NBO2 voltages went high). Next I used bi-di to command a lean AFR of about 15.3:1 (WBAFR showed stoic while the NBO2 voltages went low). So in the latter two cases, the NBO2 responded correctly to the mixture changes whereas the WBAFR just stayed at stoic (like a bump on a log). I suspect that the Bosch LSU 4.2 sensor has failed since it has already exceeded its normal life. Also, the controller is outputting an analog voltage about 20 mV high when stoic is indicated on the digital indicator.

All my best,

Steve

[joecar]

Hmmm... maybe I'm running beta software and that's why you can't open the file I posted... let me redo that with released software.

[joecar]

...

The reason that I believe my wideband has failed is shown in the screenshot in post 31 and linked here (https://forum.efilive.com/attachment.php?attachmentid=17841&d=1419208569). I was using the bidirectional controls to control mixture. initially, I left it at 14.7:1 briefly (WBAFR showed stoic and NBO2 voltages still were switching back and forth as they should at about stoic). Then I went to a bi-di controlled commanded a rich AFR of about 13.0:1 (WBAFR showed stoic while the NBO2 voltages went high). Next I used bi-di to command a lean AFR of about 15.3:1 (WBAFR showed stoic while the NBO2 voltages went low). So in the latter two cases, the NBO2 responded correctly to the mixture changes whereas the WBAFR just stayed at stoic (like a bump on a log). I suspect that the Bosch LSU 4.2 sensor has failed since it has already exceeded its normal life. Also, the controller is outputting an analog voltage about 20 mV high when stoic is indicated on the digital indicator.

All my best,

SteveOh, I see, WB is not responding.

[joecar]

Steve, Merry Christmas to you and your family :cheers:

[Steve Bryant]

Hi Steve,

2. to use % units you have to enter engine displacement (see Calc.VET thread post #1)... it is easier/better to use g*K/kPa units instead of % (more technically correct)... I don't yet think that your wideband has failed.

3. this method uses LTFT when in CL and wideband when not in CL (CALC.SELBEN selects CALC.LTFTBEN or CALC.WO2BEN depending on CALC.CL). In many cases it does calculate a correct VE table (I have seen a few where it failed, but only a few). Give it anther try, this time use g*K/kPa for the VE map.

Joe,
While you're looking at sending me a tune file using released software, I'd like to focus on your comments 2 and 3 (quoted above).

2. My EFILive Tune software is set up in the Configure Display Units area to use kPa as the Column Unit of measure and B0104 is set at 746 cc. However, I don't see any way to set up Table B0101 using g*K/kPA . So even if I make a VE MAP in Scan with g*K/kPa data in the table (which I can do and have done), how would I put this information back in the Main VE table in those units since the tune file isn't set up for it?

3. How does tune know whether to look at SELBEN or WO2BEN at any given time? In my log 20 that I submitted and you looked at, I happened to have logged Fuel System Status A and B (OL vs. CL)., but is that what SELBEN is looking at?

Thanks,

Steve

[joecar]

H Steve,

2. In tunetool do Edit->Properties and on the first tab you will see VE table units, select g*K/kPa
( I'll make sure to add this info into post #1 of the Calc.VET thread ).
While in Edit->Properties make sure fueling units are EQR.

(BTW: to enter displacement in the scantool go Edit->Log File Information->Vehicle Options... but we're avoiing % units so we don't need this)

3. CALC.SELBEN is looking at the true/false value of CALC.CL...
CALC.CL is defined as: when commanded EQR is 1.00 return TRUE otherwie return FALSE;
CALC.SELBEN is defined as iff({CALC.CL}, {CALC.LTFTBEN}, {CALC.WO2BEN})
which is the same as (if you're a C programmer):


SELBEN = CL ? LTFTBEN : WO2BEN;

which is the same as:


if (CL)
SELBEN = LTFTBEN;
else
SELBEN = WO2BEN;


i.e. when commanding stoich the PCM is able to trim so use LTFTBEN, and when not commanding stoich the PCM is not able to trim so use WO2BEN.

[Steve Bryant]

Joe,
Thanks for the update. I was able to do the Edit<Properties business and now I have the VE data set up for g*K/kPA and the mixture units set for equivalence ratio. So is EQ the desired approach for everything? Should I always steer away from lambda and AFR in favor of EQ?

I worked most of my career in aviation electronics working with wiring interface, flight crew human factor interface, etc. but I never did any programming after college. In college I only learned Fortran. We did learn about "conditional if/IFF" statements, but the language/syntax stated things in the form of if-then format. However, your explanation does add clarity for me!

Thanks,

Steve

[joecar]

For editing/viewing tables in the tunetool, use EQR to avoid mistakes (EQR > 1 is richer than stoich, EQR < 1 is leaner than stoich)...

i.e.
- for commanded fueling, using EQR;
- for wideband measurements use Lambda;
this avoids confusion since any EQR we talk about will be from the tables (i.e. commanded fueling),
and any Lambda we talk about will be measured from the wideband.

( keep in mind that Lambda = 1/EQR )

Note that by using EQR and/or Lambda we're able to avoid having to deal with the different stoich AFR's for available pump gas
(for example, E10 can have from 5% to 15% alcohol content, so the stoich varies from 14.00 to 14.50).

The Calc.VET procedure does this:
- it uses EQR for commanded fueling (GM.EQIVRATIO);
- it uses Lambda for wideband measured fueling (EXT.WO2LAM1);
- it mulitplies those two to calculate WO2BEN.

[joecar]

With your wideband, CALC.WO2BEN is defined as: {GM.EQUIRATIO} * {CALC.AFR_PLX1}/14.7

note that {CALC.AFR_PLX1}/14.7 is the wideband's measurement of Lambda...

i.e. the point is: that mulitplying by wideband Lambda is the same as dividing by wideband EQR.

:^)

[Steve Bryant]

With your wideband, CALC.WO2BEN is defined as: {GM.EQUIRATIO} * {CALC.AFR_PLX1}/14.7

note that {CALC.AFR_PLX1}/14.7 is the wideband's measurement of Lambda...

i.e. the point is: that mulitplying by wideband Lambda is the same as dividing by wideband EQR.


:^)

Thanks,
I understand that Lambda and EQ are the inverse of each other and in either case stoic = 1.0. However, I didn't get that WBO2 should be mainly associated with Lambda!

Someday, when I finish the tuning for my truck (after I get the new WB installed and have sufficient time), I want to have a discussion with you and/or others about how leaving the vehicle in closed loop (when the EQ = 1) can really be used to calibrate anything other than the MAF. So be thinking about that, if you will.

Regards,

Steve

[Steve Bryant]

Joe,
I've received my new wideband, but it's too cold to install it in my driveway (16° F now and forecast for 14° F tonight). So while I'm waiting for warmer days, I'd like to study a bit on optimizing the High-Octane Spark Advance and other spark-related parameters.

Would you provide me a couple of links for some good threads on the subject?

Thanks,

Steve

[joecar]

Hi Steve,

lol, that is finger-numbing cold...

if PE fueling is safe, look at the 2002 Camaro/Firebird HO/LO spark tables, these are pretty good for street application;

to tune spark advance you would need a large slice of dyno time (find minimum timing that produces almost maximum torque without knock) which may not always be feasible.

[Steve Bryant]

Joe,
First (or firstly), Happy New Year!!!

Thanks for your recommendation on the 2002 Camaro/Firebird Tables. I've looked briefly and the topography is similar, but not the same as what I have now. One thing that I noticed is that the timing tables (mine are not stock but have probably been changed 20+ times) for my truck are too close to the Camaro. I'm running 87 octane and the Camaro was set up for 91-ish octane.

You mention a chassis dyno. I've made several pulls on an inertial dyno about seven years ago. That was an interesting experiment, but doesn't translate much to the real world of daily driving.

Has there ever been a discussion on this forum that you know of that discusses the merits and limitations of an eddy current dyno versus an inertial dyno? There is a world of difference and to do much tuning for a street vehicle, you'd really need access to an eddy current unit.

Steve

[joecar]

Happy New Year :cheers:

With compression ratio 10 or above, you should really run 91 octane (you're not really saving very much, the difference is $0.20/gal).

Inertial dyno simply allows the engine to pull against the dyno's rotational interia, it cannot hold the engine to a particular RPM.

Eddy-current dyno has the ability to hold/load the engine at a particular RPM, this allows (for example) each cell in the VE table to obtain a sufficient hit count.

You are correct, an eddy-current dyno is required for tuning for driveability (i.e. a street tune).

[Steve Bryant]

My current CR is 9.4:1 as my LQ4 engine is the 3/4 ton truck engine. If I ever build the 6.7 L version that I'm planning, the CR will be about 10.0:1.

Steve

[joecar]

Ah, I see... with CR below 9.5 you would have a high resistance to knock, you can probably run a little more timing (maybe an extra 5 to 10 degrees).

[Steve Bryant]

I'm back again! I installed my new WB and I've gotten my tune pretty well straightened out. The main two remaining issues are fine tuning the PE a bit and dealing with some knock retard that may be related to the sudden change in air mass rate versus the limits of the burst spark retard table values. I'd like opinions on the knock retard issue. I am thinking about dealing with the burst knock possibility before I pull timing out of the high octane table. I'm attaching my current tune and two log files, one running 87 octane gas and the other running 91 octane gas.

[Steve Bryant]

As an aside, here are a few quick pictures of my new PLX AFR installation that I took with my cellphone:

Old PLX AFR that had a failed sensor
http://i172.photobucket.com/albums/w33/SteveBryant2/2000%20K2500%20YukonXL%20Modifications/PLX%20Installation/Old%20PLX%20AFR%20On%20Dash.jpg (http://s172.photobucket.com/user/SteveBryant2/media/2000%20K2500%20YukonXL%20Modifications/PLX%20Installation/Old%20PLX%20AFR%20On%20Dash.jpg.html)

New PLX AFR mounted on A Pillar
http://i172.photobucket.com/albums/w33/SteveBryant2/2000%20K2500%20YukonXL%20Modifications/PLX%20Installation/Gage%20on%20A%20Pillar.jpg (http://s172.photobucket.com/user/SteveBryant2/media/2000%20K2500%20YukonXL%20Modifications/PLX%20Installation/Gage%20on%20A%20Pillar.jpg.html)

Remote Unit located below dash to left of steering column
http://i172.photobucket.com/albums/w33/SteveBryant2/2000%20K2500%20YukonXL%20Modifications/PLX%20Installation/Remote%20Unit%20Installed%20to%20Left%20of%20Steer ing%20Colum.jpg (http://s172.photobucket.com/user/SteveBryant2/media/2000%20K2500%20YukonXL%20Modifications/PLX%20Installation/Remote%20Unit%20Installed%20to%20Left%20of%20Steer ing%20Colum.jpg.html)

General Layout of Vehicle Workstation and Pillar Mounted Gage
http://i172.photobucket.com/albums/w33/SteveBryant2/2000%20K2500%20YukonXL%20Modifications/PLX%20Installation/Gage%20and%20General%20Work%20Station%20Layout%20i n%20Vehicle.jpg (http://s172.photobucket.com/user/SteveBryant2/media/2000%20K2500%20YukonXL%20Modifications/PLX%20Installation/Gage%20and%20General%20Work%20Station%20Layout%20i n%20Vehicle.jpg.html)

Sometime in the future, I plan to take some better pictures and do a separate thread of the installation process and document the details.

Steve

[joecar]

I'm back again! I installed my new WB and I've gotten my tune pretty well straightened out. The main two remaining issues are fine tuning the PE a bit and dealing with some knock retard that may be related to the sudden change in air mass rate versus the limits of the burst spark retard table values. I'd like opinions on the knock retard issue. I am thinking about dealing with the burst knock possibility before I pull timing out of the high octane table. I'm attaching my current tune and two log files, one running 87 octane gas and the other running 91 octane gas.A few preliminary comments:

- B3618: you should probably set this richer, say EQR 1.165 rather than EQR 1.13.
- set D0925-7 below D0910-2 (downshift point must always be below upshift point, at least 5mph difference).
- set D0930-3 below D0915-7.
- set D0935-7 below D0920-2 (same with any other downshift/upshift MPH pair).
- D1108-10: set to 100% (to allow the PT tables to work correctly); see When-throttle-kickdown-is-not-set-at-100 (https://forum.efilive.com/showthread.php?7388-When-throttle-kickdown-is-not-set-at-100).
- D1001, D1004: set to 256mph (do not apply TCC in 2nd)).
- D1002, D1005: at 80% TP and above, set to 256mph (do not apply TCC above 80% throttle).
- D1003, D1006: at 80% TP and above, set to 256mph.
- D0701-3: depending on shift feel, slope up from zero (i.e. no flat areas, raise to 70 psi by 300 ftlb, increase linearly to max).

[joecar]

Steve, post your calc_pids.txt file...

You have a FSV1, right...?

[joecar]

I like the neat/tidy PLX installation, and I like the laptop table :cheers:

[Steve Bryant]

I like the neat/tidy PLX installation, and I like the laptop table :cheers:

Thanks Joe! I'll study all of your recommendations and make the changes.

I haven't made any shift point changes in a number of years, but my past practice is to have the WOT upshift point where the RPM is approximately at the HP peak and the RPM is dumped somewhere in the strongest part of the torque curve. With the WOT downshift, I want to be able to downshift well above the normal factory shift point to take advantage of the torque (once downshifted) to quickly get me back to the HP peak.

My calc_pids.txt file is in the attached files. Also, you're right, I do have FSV1...you can see it just behind the folded laptop. I had the privledge of being one of the beta testers during the transition from scanning to FlashScan. That was a fun experience. If I ever have a vehicle that requires FSV2 (CAN bus, etc.) I'll make the transition then.

Regards,

Steve

18272

[joecar]

...

I haven't made any shift point changes in a number of years, but my past practice is to have the WOT upshift point where the RPM is approximately at the HP peak and the RPM is dumped somewhere in the strongest part of the torque curve. With the WOT downshift, I want to be able to downshift well above the normal factory shift point to take advantage of the torque (once downshifted) to quickly get me back to the HP peak.

...The WOT downshift point must be below the WOT upshift point (otherwise either the upshift or the downshift may not occur when expected)...

the PCM's rules are like this:
- when VSS is at or above the WOT Upshift point: upshift is commanded;
- when VSS is below the WOT Downshift point: downshift is commanded;

following those rules, if the downshift point is above the upshift point (i.e. they are upside-down), and VSS is in between them, should an upshift or should adownshift be commanded...?

[joecar]

Also, it has been found that with the 4L60E and 4L80E that you obtain the fastest ET by shifting as high as possible (i.e. as high an rpm as the engine valvetrain can handle, and as high an rpm as the transmission clutches/bands can handle)... this is because immediately after a WOT shift the engine rpm gets pulled down a huge amount (unless a very high stall torque converter is used)... so if the rpm starts off as high as the engine/trans can survive, then when it gets pulled down it still is within the high torque range.

[joecar]

FSV1 is perfectly fine (I still use mine occasionally), it is more compact than V2

Ok, I'll use your calc_pids.txt to analyze your logs (I have a whole collection of calc_pids.txt files, I forget which is who's).

:)

[Steve Bryant]

Thanks Joe for the further information! I've consolidated your comments from three posts and am working with the tune.

Steve

[joecar]

Hi Steve, I'm running behind today (lol, it's 4:00am and I need to get some sleep), so I'll look closer at your log tomorrow.

[Steve Bryant]

Joe,
No problem. If I could get your feedback within the next several days, I'll be happy! Please take care of yourself and don't burn the candle at both ends!

Regards,

Steve

[joecar]

Hi Steve, I'm looking at your log file... the LTFT's look pretty good.

You didn't log the DYNAIRTMP_DMA pid, but I'll see how the map turns out without it (it allows more accurate VE calculation).

Take a closer look at the pids mentioned in the Calc.VET thread post #1.


Let me play with your files, I'll get back you later tonight....

[Steve Bryant]

Joe,
I did do some experimenting with the calculated VET method a couple of months ago. At that time, I was logging DYNAIRTMP_DMA. I feel like this method is really no simpler and still requires some filling in of the gaps in the VE table. I'll go into some of my feelings about this method later.

The log files here represent a more traditional two step approach for setting up VE and the MAF as follows:


set-up the VE table with the MAF disabled using LTFT as the controlling reference plus
set-up the MAF with VE disabled using LTFT as the controlling agent
both logs were made with the same tune that had VE, MAF, PE, LTFT, STFT and DFCO enabled.


I'm satisfied that VE and MAF are reasonably aligned and working properly at stoichiometric (Commanded EQR = 1.0). You've given me some excellent recommendations already in post #58 (https://forum.efilive.com/showthread.php?24793-Should-I-Download-to-a-Later-Software-Build&p=218278&viewfull=1#post218278). My remaining request is to take a look at the two logs (one running 87 octane and the other running 91 octane gas) regarding the KR that I'm getting occasionally. Obviously, enriching the Commanded EQR to 1.165 should help at WOT. So that's the main thrust of my questions beyond the recommendations that you made in post 58. I hope that this helps.

As always, I appreciate your help! :cheers:

[joecar]

DYNAIRTMP_DMA is the air temperature calculated based on engine inlwt air heatsoak modelling... if the modelling is correct, then DYNAIRTMP_DMA should give better results than IAT.

[joecar]

...

The log files here represent a more traditional two step approach for setting up VE and the MAF as follows:


set-up the VE table with the MAF disabled using LTFT as the controlling reference plus
set-up the MAF with VE disabled using LTFT as the controlling agent
both logs were made with the same tune that had VE, MAF, PE, LTFT, STFT and DFCO enabled.


Hi Steve,

Some comments/oobservations:

Calc.VET is the same as AutoMAF (MAF correction using wideband-only) with calculation of VE table thrown in;

Calc.MAFT is the same as AutoVE (VE correction using wideband-only) with calculation of MAF table thrown in;

both methods can be tailored to use wideband, LTFT, STFT or any combination thereof for the correction BEN pid;

both methods will correct/calculate the cells in the MAF/VE whose operating condition (i.e. the axes) have been hit
(i.e. for example, Calc.VET can calculate VE table only from the MAP and RPM points hit)
you still have to interpolate/smooth to obtain the unhit cells.

Calc.VET is quick/easy to setup and log (disabling VE, or allowing transient filter to remove VE contributing frames);
Calc.MAFT takes a bit more effort (disabling MAF).

PE:

I would leave PE enabled for several reasons:
- the pids GM.EQIVRATIO and GM.AFR both match the PE table when PE is enabled (I prefer to use GM.EQIVRATIO);
- it is safer to allow PE to kick in as required while driving;
- PE kicking in/out usually coincides with throttle movement, and the transient filter filters this out.

[joecar]

...
I'm satisfied that VE and MAF are reasonably aligned and working properly at stoichiometric (Commanded EQR = 1.0). You've given me some excellent recommendations already in post #58 (https://forum.efilive.com/showthread.php?24793-Should-I-Download-to-a-Later-Software-Build&p=218278&viewfull=1#post218278). My remaining request is to take a look at the two logs (one running 87 octane and the other running 91 octane gas) regarding the KR that I'm getting occasionally. Obviously, enriching the Commanded EQR to 1.165 should help at WOT. So that's the main thrust of my questions beyond the recommendations that you made in post 58. I hope that this helps.

In those logs, I see KR on throttle opening, each KR hump is jagged on top, indicating that it is real knock...

I would set B3618 to EQR 1.175.


Also, run at least 91 octane gasoline, since LQ4/LQ9 engine is designed with compression ratio 10, and you're not really saving much bu running less than 91 octane.

[Steve Bryant]

Joe,
I have reviewed (studied/considered) your comments in posts 58, 71 and 72 and I will incorporate them into my further tuning and logging. Thank you very much for your knowledge and insight!

I appreciate your help in all things!

All my best,

Steve