New Tuning Tutorial: WeathermanShawn

[WeathermanShawn]

Hello everyone:

For those of you who have followed the extensive thread "Tuning Notes by WeathermanShawn", a few comments are needed.

First, getting a Tutorial 'published' is almost as hard as passing a Health Care Bill..:) (joke).

There are legitimate issues of liability and a healthy dose of skepticism. This is especially true when a concept is new. As a DYI Tuning enthusiast I took it upon myself to try a few new concepts that I felt met the need of many Closed-Loop Tuners. The response has been overwhelmingly positive, but it is always challenging to 'prove' new concepts.

Since a number of people have devoted a lot of their own time to improve this method (including myself), I feel a responsibility to at least have some further reader input.

I have attached a Preliminary Tutorial that describes a method of Calculating a VE Table that simultaneously allows for MAF and complete Trim Tuning. All in the course of one-two tuning runs. It is unique in that it can be done simply and efficiently, and incorporates EFILive's 'charge temperature' in its VE calculations which is a novel concept.

We need volunteers. This field does not advance without effort. This has been a total volunteer effort, but the burden of proof falls upon the 'originator' of the concept.

Would you guys and gals respectfully add your opinions, and constructive comments where necessary. If any experienced Tuners would volunteer to log the CALC.VE Table PID and compare it against their VE Table (preferably MAF-Closed-Loop), your efforts could help others.

Again, there is no personal or financial benefit for myself or anyone who has contributed to this tuning method. It just needs a fair shot.

Thanks..

CALC.VE. Update:
Calculate the entire VE Table from Idle to Redline RPM in a Single Log Session:

1. Tune Both Closed-Loop and PE Mode/WOT (simultaneously)
2. Calibrate MAF
3. Eliminate Trims
4. Calculate Entire VE Table Idle-Redline

Link Here for More Information: 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.&p=135867&viewfull=1#post135867)

[TAQuickness]

To further Shawn's post, we just need 1 or 2 folks to go thru this tutorial top-down and offer feedback on the flow and content, namely if anything is out of order, missing, or unclear. Please post your feedback in this thread or send a PM to WeathermanShawn, JoeCar, and TAQuickness.

[joecar]

We want some people to try it out so to see if anything needs to be added to it (some things are not obvious to everyone equally).

[RevGTO]

First, let me say that the revised tutorial is well thought out, the flow is good, and the additional level of detailed instruction is very helpful.

In particular, the placement of the additions to the calcpids.txt file BEFORE the creation of the pid selection is helpful to the logical progression of building the the tuning protocol.

One comment:
Could the .txt file for the calcpids be hosted in the sticky and a link included in the tutorial? This would allow a user to copy and paste them. I know it can be found in Shawn's thread, but future users will not likely be reading through it.

[joecar]

F...
One comment:
Could the .txt file for the calcpids be hosted in the sticky and a link included in the tutorial? This would allow a user to copy and paste them. I know it can be found in Shawn's thread, but future users will not likely be reading through it.Done.

Shawn has added the calc_pids.txt to his post above.

:)

[y2k2z28]

I am super new to tuning, so I am perfect to take a look at this. I have read it a couple of times and looks straight forward. I will give it a shot Monday. I am tuning an 08 Corvette so there will be some differences that I will note and pass along. If I am understanding this stuff right there should only be a few differences. I will let you guys know....

Should I get a serial WB connector before I try this?

[WeathermanShawn]

A lot of the Tutorial is focused on closed-loop..so if you can successfully log LTFTS and the supporting PIDS, it will tell you a lot.

Serial connection on the wideband makes life a lot easier..but as long as you have capability to log any WOT AFR (if you choose).

Could be a few differences on a 08 Corvette, but it would be interesting to see your results.

[DrkPhx]

Yesterday I tried this method yesterday when retuning a friend's 00 M6 WS6 with a small cam and FAST 92mm because we installed bigger injectors. I couldn't get the Calc VE map to record values (it did record cell counts), so I threw together a new Calc VE table using the LTFT Ben pid in it's place. The MAF map worked fine. After rescaling the IFR I started from the stock VE and MAF and had them both dialed in pretty good within a short time. The LTFT's were within -1 to +5% for the most part (except for some transient areas) after maybe 5-6 logs. Maybe not a true acid test, but close. Obviously the tune needs further tweaking, but I was impressed how much time it saved when starting from scratch.

On a similar note, I modified an existing Calc pid for WOT MAF tuning based on the LM1 value and commanded AFR because I was sick of using a spreadsheet. There may be one in the existing list, but I didn't see it. Anway, it works pretty good as well.

[WeathermanShawn]

It was smart you made that extra pid for WOT. I have thought of doing the same myself.

The only time I had problems on the Calc.VE Table values were when my displacement read zero. But, that did not sound like the problem. Its tricky since EFILive has a CALC.VE Pid also..as long as it was multiplying the LTFTBENS with the PID that had the DYNAIRTMP.DMA in it, life should be good.

I am sure Joecar will read this over. My only concern would be that you have two CALC.VE Pids that look very similar, but are different.

Sorry, DRKPHX, I am just thinking out loud. I am glad you ran through it and gave a pretty good report. Thanks for your efforts and report. We may have to make a few changes in the future to make sure that PID is an easy lookup and calculating with ease.

Thanks again.

[joecar]

DrkPhx, post your calc_pids.txt file.

[joecar]

To find the pids CALC.VE_Table and CALC.LTFTBEN, click on the column heading System (this sorts on this column) and then scroll down until you see Tuning in the System column.

Hmmm... in the map you have to make sure to specify the CALC.VE_Table pid with the % units.

[DrkPhx]

To find the pids CALC.VE_Table and CALC.LTFTBEN, click on the column heading System (this sorts on this column) and then scroll down until you see Tuning in the System column.

Hmmm... in the map you have to make sure to specify the CALC.VE_Table pid with the % units.

I will double check when I get home tonight. When selecting a PID I usually search by system. Speaking of pids, there were a couple in the tutorial listed under the wrong system.

[redhardsupra]

Yesterday I tried this method yesterday when retuning a friend's 00 M6 WS6 with a small cam and FAST 92mm because we installed bigger injectors.

how do different injectors change the breathing characteristics of the engine?

[WeathermanShawn]

Thanks DrkPhx:

Thanks for double-checking. Appreciate the feedback. We will check the Tutorial PID selection, and see if we can clarify any of the PID definitions etc.

Like you, I find working with LTFTBENS practical and 'easy'. Everything mentioned so far is comparable to 'early testing'. We thank you for having a good attitude and helping us refine the method. Even if one inadvertently uses the 'older' CALC.VE Pid, it is easily worked around.

Thanks for contributing to the Tuning community.

[DrkPhx]

how do different injectors change the breathing characteristics of the engine?

Ehh? The previous tune was with the stock injectors and flow rate, so we switched injectors and adjusted the IFR accordingly.

[redhardsupra]

Ehh? The previous tune was with the stock injectors and flow rate, so we switched injectors and adjusted the IFR accordingly.

yes, but you sounded like you're adjusting MAF/VE to make up for changes in fuel flow.

[y2k2z28]

Joe and Shawn,

Thanks for the help with the PID's. It appears that I had just added to the end of the existing file father then replacing the whole file. Removed the double parts of the file and now they show up..

Darrin

[WeathermanShawn]

Thanks Darrin:

Let us know how it goes.

DrkPhx, if you need a second opinion of the Injector Flow Rate, we have several people who can look at that. A lot of the research on air mass etc., has been centered on open-loop and on a load-bearing dyno. Sounds like you know what you are doing.

For purposes of this Tutorial, it is the application of LTFTBENS in Closed-Loop that is pertinent. If the formula or method needs tweaking, your feedback along with others is important.

Since I have my tune down, I will try various iterations of B0120 Thresholds, and differing stock VE Tables to see how they influence LTFTBENS. I finally have a few solid ideas of how to 'control' the experiment, and like you I had to wait until the weather clears. The 'beauty' of Trims is that eventually the tune becomes self-correcting, but it is important to know how that process works.

Thanks again.

[5.7ute]

What Marcin is trying to say is if the tune was right with the old injectors, fitting larger injectors should only need the injector tables modified. Not a complete retune of the airmass tables. This would obviously come from the assumption that the old tune was correct, which DrkPhx has not stated so IMHO is not really relevant to this discussion.
If the old tune was correct though, this opens a different can of worms that will need correcting before continuing.
Back on topic. It would be good to see some before & after tune & log files from those taking part in the validation process. This will give not only some extra eyes to ensure that the process is being followed, but will also help someone new to the method follow in the process with practical examples.

[WeathermanShawn]

I agree.

The more validation the better. Especially with Injector flow. I am sure in the next year I will probably be adding 'more' injector..Want to make sure to get it right. Its adds an additional challenge when tuning.

Good point 5.7ute!

[DrkPhx]

What Marcin is trying to say is if the tune was right with the old injectors, fitting larger injectors should only need the injector tables modified. Not a complete retune of the airmass tables. This would obviously come from the assumption that the old tune was correct, which DrkPhx has not stated so IMHO is not really relevant to this discussion.
If the old tune was correct though, this opens a different can of worms that will need correcting before continuing.


Good point. I should clarify The original tune was not correct with the old injectors. I knew this and wanted to try this method since I would be starting from scratch. My goal was to start from a stock tune with new injectors and work from there to see how fast I could get the new tune in order. Sorry for any confusion.

[joecar]

If there's any typos or problems with the pdf or the calc_pids.txt please let us know.

[y2k2z28]

Ok, I think I have everthing ready to go, well almost. I had a little trouble making the maps, well not really trouble just had to look around a little more. Since my car is E38 I did not have B0101, so I used B0141 for the CalcVe_Table map. For the Calc.LTFTBEN map I did not have B5001 so I had to use B1099.

The maps look right but are the values from the tables the same. My calcVE_Table map starts at -40 and goes to 216. I think this is ok since the MAF limits are higher, but just double checking.

Darrin

More trouble....GM.DYNAIRTMP_DMA, GM.AFR, AND GM.CYLAIR_DMA are unsupported by E38 are there different ones I can use and then change the calculated PID's?

[joecar]

B0141 is not the right table... E38 has tables B81xx... i.e. virtual VE... I am not sure how this will work for E38 or E67.

[WeathermanShawn]

Darrin:

I have only tried this on the LS-III OP systems. You or someone else may have to educate me on how E38 works with VE Tables, MAF, closed-loop etc.

Can you log DYNAIRTMP.DMA?

As Joecar said:

Shawn means GenIII LS1 systems, more specifically 1999-2008 LS1B.

[y2k2z28]

Yeah, I am running nto more trouble, see above edited post. some of the PID's are not supported. I will keep at it with your help and see what happens.

[joecar]

Shawn means GenIII LS1 systems, more specifically 1999-2008 LS1B.

[joecar]

For E38 see here: showthread.php?t=8961 (http://forum.efilive.com/showthread.php?t=8961)

[y2k2z28]

Yeah, I am begining to think this will not work for me. I did fine the VE map B8101 now my map looks right...

[WeathermanShawn]

Sorry about that. There are so many differing types of vehicles and platforms. Hard to have a technique that can work for them all.

For the Gen-III LS1's, it is not that hard to do. I have plugged in 4 differing tunes from 15% +/- values added to the VE Table, and differing RPM Airflow Calculations. In each case with MAF enabled, Trims are almost identical. I would have to have an expert to figure how it effects transient fueling situations.

May not help you in your current situation, but just reassuring other users I have tested almost every combination of tunes (even throwing in bogus VE Tables) and have found as long as the MAF airflow is correct, you get very consistent results.

It may take a few days to summarize the results..always willing to share the logs and tunes..but I think it will take more than my results to add to the credibility of the method.

Maybe someone can figure out a method for you Darrin? Hate to leave you high and dry..

[y2k2z28]

Shawn,

I am not high and dry, I am still playing with it a little, trying to see if there are capatible PID's for the E38. Then I will change the calc PID's and see what happens. You never know it might work.

If nothing else I have learned a ton about the program and how to change different this.

[5.7ute]

One thing I believe people should be aware of, is that B0120 isnt an absolute switchpoint between a predicted & measured cylinder airmass. With increasing rpm, B0120 is where the pcm transfers from Speed density(predicted) to maf (measured). However, once enabled the rpm has to drop x rpm below B0120 to return to the predicted airmass tables. In the Holden OS 12202088 & 12220574 this value is set at 100rpm.
So when filtering the data, it may be wise to exclude this rpm band.

[WeathermanShawn]

Good point.

One thing I have been working on, is whether B4107 is controlling when MAF is enabled (just like B5913).

If that is the case (big if), then B4106 the LTFT Update Filter will be totally controlled by MAF.

If that is the case, then any Airflow correction is being ignored by MAF unless it exceeds the amount dictated in C2911 (MAF Rationality Test).

At this point, I have no way of proving it. Except for the fact that you can load up a lot of bogus VE Tables B0101, and the effects on Trims seems very negligible.

While I know there is a lot more to tuning..it really makes you wonder if anybody really knows the exact MAF/VE blending. How much of the VE Table is 'just in case of MAF failure.???

Proving this is the challenge!

[TAQuickness]

One thing I believe people should be aware of, is that B0120 isnt an absolute switchpoint between a predicted & measured cylinder airmass. With increasing rpm, B0120 is where the pcm transfers from Speed density(predicted) to maf (measured). However, once enabled the rpm has to drop x rpm below B0120 to return to the predicted airmass tables. In the Holden OS 12202088 & 12220574 this value is set at 100rpm.
So when filtering the data, it may be wise to exclude this rpm band.


The PCM doesn't measure anything. It looks up the air mass data from a table respective of the input signals. Both cases, VE and MAF, would be better described as predicted or interpolated.

[5.7ute]

B4107???
The LTFT will be stored in a seperate part of the pcm & added to the final Airmass?/fuelmass? (not sure which but it will work out the same). So it wont matter what model it is using at the time, Sd or maf.

[5.7ute]

The PCM doesn't measure anything. It looks up the air mass data from a table respective of the input signals. Both cases, VE and MAF, would be better described as predicted or interpolated.

I agree. It is just that the maf measures the airflow, where SD is a predicted best guess. I find it easier to comprehend when using this terminology.

[WeathermanShawn]

Its just something to think about (B4107).

I did not start thinking about it until I did two separate logs..one where I added +15% to the VE Table, and another where I subtracted -15% from the VE Table..(still keeping MAF Enabled-Closed-Loop).

The LTFT Trims were so identical, that I started hypothesizing that just like cylinder air (when MAF enabled) dictates spark, perhaps when MAF is enabled it also dictates Trims. I mean 100% of the time..just like spark is controlled by MAF (when enabled).

In no case does it dictate that your VE Table does not need to be accurate, but I think the PCM may act differently in airmass and fueling computation when MAF is enabled, vs MAF failure.

It almost is like when MAF is enabled it is close to 100% determining airflow. Again, I can not prove it..just am amazed that a +/- 15% VE Airflow change would have almost a negligible effect on Trims.

We need a PID that tells you have much MAF, and how much VE Table is being used...:) (I know you have a PID that comes close!)...

[5.7ute]

What I mean by B4107??? is I cant find that table. Is it a typo?

[WeathermanShawn]

B4107:

Mick, on my OP..2002 Camaro-Z28..It is the Table that determines what Closed-Loop-Mode you are in.

Interestedly, it is referenced by SAE.MAF (g/s)..I know if you go SDCL it is DYNAIR.DMA, but the Table for MAF users..does say SAE.MAF.

Just makes you wonder? I know you can do loop-up Tables to reference what Closed-Loop Mode you are in, but it might explain how Trims are applied when MAF enabled..I..E..B4106 LTFT Update Filter.

Sorry, I know every OP is different..but may be an important distinction.

[mr.prick]

I used GM.DYNCYLAIR_DMA as it is in g/cyl and {B4107} used to be linked like this:


;Closed Loop Mode
B4107.ROW=GM.DYNCYLAIR_DMA,GM.CYLAIR_DMA,GM.DYNCYL AIR,CALC.CYLAIR

Check out this thread:
{B4105} how do i link this table? (http://forum.efilive.com/showthread.php?t=8142&highlight=B4107)

[WeathermanShawn]

Thanks Mr. Prick, I'll check that out.

The mystery to me though is I wonder if it is identical to B5913 (High Octane Spark). You can PID both DYNCYLAIR.DMA and CYLAIR.DMA, but with spark you can definitely tell with MAF enabled that CYLAIR determines spark irregardless of what DYNCYLAIR is.

I guess my 'theory' is that with MAF-enabled, Trims come exclusively from MAF (CYLAIR)..same as spark. I don't know whether a PID for B4107 really 'proves' it. It is more of an intuitive observation. Other than doing something ridiculous, like doubling your VE Table and logging Trims..it is hard to know.

Spark values you can log. It is easy to see it follows CYLAIR 100% from MAF when it is enabled. So no 'Airflow correction' affects the load calculation for spark. Maybe it is the same with Trims..

[5.7ute]

Shawn, without going deep into the code, you could pretty safely assume that the references for these tables will be whatever airmass model the pcm is using at that time. Under B0120 the Dyncylair value will be used, over this Cylair will be referenced.

[WeathermanShawn]

Yea, I figured it would be far more complicated than I was assuming. Airmass and fueling would be far more complicated than how the PCM calculates spark load.

Add to it the complexity of LTFT Update Filters, Trim function, etc., it is not as simple as I was stating it.

Suffice to say that is why us MAF-enabled closed-loop guys still put in the work to nail down the VE Table. In simple terms, it would really be cool to have a PID that says, I am using 85% MAF airflow right now, 15% 'SD' right now..I just accelerated now I am using the following percentages.

I know it sounds ridiculous that it could ever be that easy..:grin:

[joecar]

If it doesn't twist your brain in a tight knot, then it's no fun at all... :hihi::hihi::hihi::hihi:

[TunasTwins]

I've been following this theory from the get go and have been very excited about it. I'm completely new to EFI live as I have been using autotap and tunercats. If you guys can walk me through this, I can do the testing on a stock to-the-air filter 4.8L 2005 Tahoe. I had made a previous log that shawn had looked at to make sure I had the correct PID's selected.
My hurdles:
1. I'm using Tunercats to do the flashing.
2. I need to set up the new CALC PID's which I've never done before (working on that right now...I'm slow ;) ) DONE, that was retardingly simple.......
3. Limited time.

I FINALLY pulled my LM1 from my '96 WS6 so I have something to verify all this with.

Again, I've been following ALL of this and want to contribute.

[WeathermanShawn]

Well, the 'limited time' aspect is about as good as it can get with this method.

You can reasonably tune VE, MAF, and Trims simultaneously.

Unfortunately, in tuning nothing is totally easy..but I think if you can successful log the PIDs, and paste and cut..then you just need some level of computer skills to go from there.

I am not that familiar with 'Tunercats', but anything we can do to help..let us know.

Thanks..

[TunasTwins]

OK Guys,
i'm confident I have the PIDS and maps set up correctly. However, I cant select the two WBO2 PIDS as they are not there and probably need to be set up. Is this necessary for the initial log? I thought I could apply the calc PID's to a previous log but that appears to be a no go. I'll have to go for a ride in the truck which I may do tonight, definitely tomorrow. I assume we're using the WBO2 as a sanity check. Can I log and flash. Then log with the WBO2 as a check? Her truck doesnt have a bung for the WBO2 so I'll have to pull an 02 to install it (at the cat???). BTW in Atlanta we have E10 so I have to deal with that next. Tunercats is tunercats, sorta the win95 of tuning :)

[mr.prick]

You can add calc_pids to a log if they're dependent pids are logged and
I suggest setting PE EQ to 1.176 for E10 if you want to run aggressive timing.

I've found the GM.AFR pid to be unreliable at times and gives a different value
to what {B3601} & {B3618} are. :nixweiss:
I made a new calc_pids for commanded AFR ({B3601}/{GM.EQUIVRATIO})
and commanded Lambda: (1/{GM.EQUIVRATIO})
I use WBO2 EQ & Lambda to make a new BEN factors.

There's a spread sheet in my sig to create a new expression for your WBO2.
To find the slope & intercept for {B3601} the lambda min/max must be entered.
If you don't know the Lambda min/max for your WBO2 divide the min/max AFR by the stoich AFR.

[TunasTwins]

I noticed the calc pid in the tutorial and the one in shawn's first post are different. The LTFT BEN in the tutorial ends in...)/2/100+1 where as the attached file ends in /200+1. Also for the sake of clarity, should the attached calc pid in the post have "displacement" instead of the actual number(5.669). For newbs to EFI live, shouldnt we make it as easy to cut and paste as possible? Also, I noticed in the tutorial when showing how to do the filtering, the second screen shot shows temp in metric where as the first is imperial.

[TunasTwins]

I'm using 1.165 currently, the timing's not too advanced right now. I'm still trying to wrap my head around the E10 tuning and the 2005 OS but lets keep on topic....

[WeathermanShawn]

I noticed the calc pid in the tutorial and the one in shawn's first post are different. The LTFT BEN in the tutorial ends in...)/2/100+1 where as the attached file ends in /200+1. Also for the sake of clarity, should the attached calc pid in the post have "displacement" instead of the actual number(5.669). For newbs to EFI live, shouldnt we make it as easy to cut and paste as possible? Also, I noticed in the tutorial when showing how to do the filtering, the second screen shot shows temp in metric where as the first is imperial.

Good eye on the filter temps. Missed that one..:).

Let me look over the LTFTBEN..I think I know what you are referring too. I believe they are mathematically equivalent, but it could be a typo, so thanks.

Yes, the CALC.PID should read displacement. There has been a problem using displacement instead of the actual value, but I believe the latest software corrected it.

As far as 'cut and paste', believe me we saved a lot of steps with this method. A lot of the 'cut and paste' is being accomplished by the CALC.VE being multiplied instantly by the LTFTBEN, but I hear you. First couple of months I thought the same thing. Now, it is a distant memory.

I think that covers your last few points. Thanks for pointing out some problem areas.

As far as the wideband..If you can keep out of KR and avoid WOT, and trust your narrowbands..the method will work. But, I can not responsibly suggest it. Even today, a wideband saved me from some headaches. Your mind can fool you. Rich, lean are very hard to guess at. But, the method is not wideband dependent to work..your $6000.00 engine can go lean and start doing damage really quick. I think widebands should be mandatory in tuning..

[WeathermanShawn]

I've found the GM.AFR pid to be unreliable at times and gives a different value
to what {B3601} & {B3618} are. :nixweiss:

Mr. P..off by a lot?

[TunasTwins]

I hope you understand I'm trying to make this method workable for the challenged(me):doh2: The formula looked correct to me so I was just pointing it out. I'll try and test this out as promised and will report back. TIA!

[WeathermanShawn]

No, I understand. We honestly appreciate the feedback.:cheers:..

[mr.prick]

I've found the GM.AFR pid to be unreliable at times and gives a different value
to what {B3601} & {B3618} are. :nixweiss:

Mr. P..off by a lot?

Commanded AFR ≠ {B3601} (http://forum.efilive.com/showthread.php?t=13124&highlight=gm.afr)

Not when EQ1 is commanded but when PE comes on it was returning
a leaner value than what commanded EQ was.
I feel that is unacceptable. :cussing:

If commanded AFR is leaner than {B3618} then
BEN will pull out fuel when it should not.
{GM.EQUIVRATIO} is reliable and always matches {B3601} & {B3618}

[joecar]

I noticed the calc pid in the tutorial and the one in shawn's first post are different. The LTFT BEN in the tutorial ends in...)/2/100+1 where as the attached file ends in /200+1. Also for the sake of clarity, should the attached calc pid in the post have "displacement" instead of the actual number(5.669). For newbs to EFI live, shouldnt we make it as easy to cut and paste as possible? Also, I noticed in the tutorial when showing how to do the filtering, the second screen shot shows temp in metric where as the first is imperial.
Welcome to the forum...:cheers:

Those two are the same.

displacement() doesn't seem to always produce a value.

Good point... depends on whether your calc_pids.txt already has stuff in it or not.

Good catch, thanks.

[joecar]

Commanded AFR ≠ {B3601} (http://forum.efilive.com/showthread.php?t=13124&highlight=gm.afr)

Not when EQ1 is commanded but when PE comes on it was returning
a leaner value than what commanded EQ was.
I feel that is unacceptable. :cussing:

If commanded AFR is leaner than {B3618} then
BEN will pull out fuel when it should not.
{GM.EQUIVRATIO} is reliable and always matches {B3601} & {B3618}I have seen a few times where GM.AFR wasn't {B3601}/{GM.EQIVRATIO}... I'll have to dig thru my logs to find some examples...

[WeathermanShawn]

I notice you guys use EQ (always) instead of AFR. Am I behind the times here, or is that necessary if you are only working with one OP.

Any inherent advantage?

[joecar]

The advantage is that it allows you to instantly see the % richer/leaner (i.e. the fraction part).

Here's my current calc_pids.txt.

:)

[mr.prick]

I use EQ for the reason I stated previously. :mad:
It gives you an accurate multiplier and you don't need to worry
about your WBO2's stoich AFR not matching {B3601} perfectly.
Using AFR is fine if both match closely and {GM.AFR} is what it should be. :rolleyes:
You can change the analog output slope or expression to match {B3601}
but there is still the accuracy problem with {GM.AFR}. :bad:

[WeathermanShawn]

Once you guys explained it..it seems so obvious.

Thanks for explaining and for the CALC PIDS..

[joecar]

In the calc_pids.txt attached to post#59 you may have noticed that I multiplied {SAE.MAP.kPa} by 1000... this allows CALC.VE_Table.VEpcm to be in grams instead of milligrams...

actually VE units map to g*K/kPa.

[joecar]

I applied this to some of my log files, I didn't have DYNAIRTMP logged, so I changed the calc pid to use IAT instead...

this is what it produces, VE_Table looks pretty close...

:)

[WeathermanShawn]

Hows it looking?(CALC VE).

[joecar]

I updated the calc_pid.txt file... see attached.

Changes:
- in equation for VEpcm, multiplied MAP.kPa by1000.
- changed VEpcm units to VE units (i.e. g*K/kPa).
- changed VEpcm range from 0-3000 to 0-3.
- changed LTFTBEN % range from 0-2 to 0.5-1.5 for more resolution.
- removed extra set of parenthesis from around displacement multiplication.

:)

[TunasTwins]

Would changing the high for the calc_VE to something like 110 be O.K. for boosted applications? I'm trying to understand the calc_pids boundaries in general. The only hurdle I see in this is my VE table isnt in %VE but grams/cyl. I think I need to make a BEN table to multiply my stock table with OR convert my table to %, find the difference, and go from there? Either way, I work at 3AM and will hopefully log the truck when I get home.

[joecar]

Would changing the high for the calc_VE to something like 110 be O.K. for boosted applications? I'm trying to understand the calc_pids boundaries in general. The only hurdle I see in this is my VE table isnt in %VE but grams/cyl. I think I need to make a BEN table to multiply my stock table with OR convert my table to %, find the difference, and go from there?
...
Yes, that's the gauge/chart high tickmark display mark, it doesn't affect the calculation.

High = highest tickmark on gauge/chart,
Low = lowest tickmark
Fmt = how many decimal places

Try the VE_Table with VE units in the calc_pids.txt I posted in post #65... not g/cyl but g*K/kPa (same as B0101).

[mr.prick]

The calc_ve PID still doesn't work. :frown:

[joecar]

The calc_ve PID still doesn't work. :sad:
Huh, what happens...?

[WeathermanShawn]

Mr. Prick, is it a displacement issue? (all zero's), and it just won't validate?

Remember, we have two VE type PIDS. The 'newer' one that utilizes DYNAIRTMP is under Tuning..

[mr.prick]

I meant the predefined one.
I hacked the sae.generic.txt to see what it looks like after a log w/MAF.

[joecar]

Mike, are you using the pid CALC.VE_Table under system Tuning like Shawn said...?



. . .
CALC.LTFT F001 CLC-00-001 % Tuning "LTFT Average"

CALC.LTFTBEN F002 CLC-00-002 factor Tuning "LTFT BEN"

CALC.VE_Table F003 CLC-00-003 "%,VE" Tuning "CALC VE Table"

[WeathermanShawn]

I assume it may still relate to displacement..

http://forum.efilive.com/showpost.php?p=115729&postcount=41

[mr.prick]

I replaced the displacement() part of the sae_generic.txt with my engine's size in CC.
I don't think {CALC.VE} has been working for a while even tho the
displacement in the customer details has been fixed.

[WeathermanShawn]

Mr. P., mine has been working. I just use the V2 right now, not BBL. Don't know if that is the issue, but both my PIDs worked perfectly on a run 1 day ago..???


************************************************** ******


On the 'issue' of the EFILives pre-defined CALC.VE Pid vs the CALC. VE Table Pid.

The CALC VE Table Pid includes the calculation of charge temperature to more accurately 'convert' a MAF based-airflow into a dynamically calculated airflow.

Here is an example of using just the predefined EFILive CALC.VE Pid..and simulating a total MAF failure.

The second MAP shows how adding the ECT & IAT blending (charge temperature), again assuming a total MAF failure, greatly enhances the accuracy of the VE Table calculation.

The second example is utilizing the CALC VE Table Pid..

Using the new CALC VE Table Pid, will increase your VE Table values ~ 5-10% in high ECT, low airflow situations, and ~ 1-3% at WOT..where the PCM uses almost exclusively IAT in its calculations.

Hope that makes sense..

[mr.prick]

I was just adding the {CALC_VE} pid to a log I already had to check it out.
I don't normally log {GM.DYNAIRTMP_DMA}.

[WeathermanShawn]

The only other thing I can think of..since I may have a similar problem once...

I recall making sure every unit in my scan pid selection was all metric. I think I got hung up once on the MAF units..made sure they were g/s.

Occasionally on my desktop I could not utilize the CALC VE Pid, unless I had a run transferred from my laptop. The laptop of course I had validated all the pids etc., and I had the Pid working (prior to a run).

I am probably getting in over my head on the computer end..Perhaps there is still a 'bug' somewhere??

[joecar]

Mike, does your log contain GM.MAF or SAE.MAF...?

We might need to make a set of pids for GM.MAF, and to manually blend ECT and IAT...
this will allow CALC.VE_Table_Handraulic to be applied to old logs.

[joecar]

Try this calc_pids.txt (I haven't tested it yet)...

In CLC-00-004 and CLC-00-005 you may have to replace SAE.IAT with some blend of SAE.IAT and SAE.ECT...

e.g. 0.90*{SAE.IAT} + 0.10*{SAE.ECT} (where the two fractions add up to 1.0)

Change 5.669 to your actual displacement in litres.

[joecar]

Shawn, good point on Metric units.

Mike, on the PIDs tab, highlight every pid (ctrl-A) and do rightclick->Metric.

[joecar]

Mr. P., mine has been working. I just use the V2 right now, not BBL. Don't know if that is the issue, but both my PIDs worked perfectly on a run 1 day ago..???


************************************************** ******


On the 'issue' of the EFILives pre-defined CALC.VE vs the CALC. VE_Table.

The CALC.VE_Table pidincludes the calculation of charge temperature to more accurately 'convert' a MAF based-airflow into a dynamically calculated airflow.

Here is an example of using just the predefined EFILive CALC.VE..and simulating a total MAF failure.

The second MAP shows how adding the ECT & IAT blending (charge temperature), again assuming a total MAF failure, greatly enhances the accuracy of the VE Table calculation.

The second example is utilizing the CALC.VE_Table..

Using the new CALC.VE Table, will increase your VE Table values ~ 5-10% in high ECT, low airflow situations, and ~ 1-3% at WOT..where the PCM uses almost exclusively IAT in its calculations.

Hope that makes sense..Yes those two maps are quite different.

I'm going to try this with BBL today, I'll post up later.

[WeathermanShawn]

Joe, I like that idea of a manual ECT/IAT blend. Had thought of it before, but could not quite figure out how to introduce the bias factor (unless you use 5.7ute's lookup Temp bias method..you know MAF/DYNAIR flow, etc..).

On the addition of ECT/IAT blend. It took simulating a MAF failure to see the difference. When you log DYNAIR and CYLAIR a .20-.22 difference, does not look like much..but that is a 10% difference.

Because of your previous point(s) on B0120..and if/when you use 4000 Rpms, it tends to take some 'smooth' out some of the LTFTBEN differences vs the direct MAF failure example. You see more of an 5-10% increase in 'VE Values' at 800-2000 Rpm, less as airflow increases.

But, nevertheless it really makes you understand and appreciate that charge temperature weight in the DYNAIR calculation.

[mr.prick]

Try this calc_pids.txt (I haven't tested it yet)...

In CLC-00-004 and CLC-00-005 you may have to replace SAE.IAT with some blend of SAE.IAT and SAE.ECT...

e.g. 0.90*{SAE.IAT} + 0.10*{SAE.ECT} (where the two fractions add up to 1.0)

Change 5.669 to your actual displacement in litres.

Changing CC to liters?
Isn't displacement() meant to be in CC like what's in the customer details? :confused:


Would 0.90*{SAE.IAT}+0.10*{SAE.ECT} be the same as {GM.DYNAIRTMP_DMA}?

[WeathermanShawn]

Mr. P., We figured out it wanted Liters..I could not get it using CC's.

We may not have communicated that effectively (sorry).

Hopefully Joe will comment on Point #2. That charge Temperature Blending B4901 is a moving target..

[joecar]

It wants Liters...

The term "5.669*61.024" in the equation is a conversion of 5.669L to cubic inches...

61.024 has units ci/L... i.e. it converts Liters to cubic inches.

[joecar]

...
Would 0.90*{SAE.IAT}+0.10*{SAE.ECT} be the same as {GM.DYNAIRTMP_DMA}?No... it is an approximation... and since our old logs don't have GM.DYNAIRTMP_DMA, then it is a good starting point.


[ GM.DYNAIRTMP_DMA is updated dynamically by the PCM ]

[WeathermanShawn]

Here are a few examples of a log showing the effects of DYNAIRTMP on CALC.VE & CALC.VE TABLE.

This was done with MAF FAULTED (SDCL)..

1. Tried to keep ECT the same
2. Very cold IAT's (tried to keep steady).

Whether DYNAIRTMP includes B4902 Charge Temperature Filter..I can not tell. But it follows B4901 quite well..

1. WOT
2. IDLE
3. Cruise
4. DYNAIRTMP AVG

[mr.prick]

I guess 273.15+IAT+((ECT-IAT)*lookup {B4901} would be the same. :nixweiss:

[WeathermanShawn]

Yes!

Whether B4901 comes into play..I can not tell. I was looking over some logs to see if DYNAIRTMP changes with the same ECT and rapid change in IAT..but I followed my own advice and picked cold mornings where I kept ECT and IAT steady.

But, I think your statement is correct. I think it must indeed by the 'TMP' that the PCM sees. Maybe that is more important than knowing if other tables come into play??

[joecar]

I guess 273.15+IAT+((ECT-IAT)*lookup {B4901} would be the same. :nixweiss:That would be much better than "0.90*{SAE.IAT}+0.10*{SAE.ECT}"... I was running late this morning...:doh2:

Let try to apply B4902 to this as well...

[mr.prick]

Ve is in g*K/kPa
What is g?

[joecar]

g is the abbreviation for grams...

[mr.prick]

Grams per second?

[5.7ute]

Grams per second?

No. Just Grams.

[TunasTwins]

Here's the log I made following the tutorial. Most of the values seem plausible. I also attached a excel file with my stock VE table in grams/cyl-converted to %VE. The excell has filtered data, the log is a virgin. I did experience a little bit of knock retard which was odd. Now I just need to figure out the EASIEST way to convert the EFI Live table to a tunercat friendly table.

[WeathermanShawn]

Yea, it looks like you got everything right..and the results look valid.

As far as the KR..Well, it looks real. If it was just 'Burst KR", it might reduce your timing, but not show up as KR.

See, without the wideband..can not tell your AFR at WOT. A good test might be to just knock your Spark Advance down 4-5 degrees at WOT, and see what happens. The only other issue that can cause KR is 'noise'..tranny, exhaust pipes, etc.

For now, I would assume it is legitimate KR and reduce your timing until you can determine your WOT AFR.

Otherwise, the results look valid. Thanks for helping..

[5.7ute]

Here's the log I made following the tutorial. Most of the values seem plausible. I also attached a excel file with my stock VE table in grams/cyl-converted to %VE. The excell has filtered data, the log is a virgin. I did experience a little bit of knock retard which was odd. Now I just need to figure out the EASIEST way to convert the EFI Live table to a tunercat friendly table.

What is the difference with how Tunercat display the table compared to Efilive?

[TunasTwins]

I noticed my VE has increased as much as 9%. I thought VE decreases with engine life?? As far as the knock, my high and low tables are the same right now so getting the low table back in order may take care of that. The next step is adjusting my O2 switch points to compensate for the E10 here in Atlanta. That should be a nice follow up: the effects of lower switch points and E10 on the VE table. Should it make a difference? I wouldnt think not but we'll see. Thanks again. I'll report back after the next log.

[WeathermanShawn]

Your VE Values might have increased just due to the nature of the 'charge temperature' in the formula. Adding ECT/IAT blending will almost always add a little more DYNAIR than CYLAIR alone. But, that is good. If your MAF fails, you will have accurate fueling in closed-loop..(part of the point of the CALC.VE Table Pid).

I have played around with some of the O2 switch-points. I eventually just settled on whatever O2 value would give me stoich. I have seen it make a significant change on Idle AFR's when you change it.

Can you expand on the Tunercats vs EFILive?

[joecar]

Ok, even tho V2 displayed DYNAIRTMP_DMA 10x too big (firmware bug), the scantool sees the correct value...

VE[%] looks good, matches my stock B0101 (I'm all stock since I had remove my LT's for smog test a few months ago... wb is not on either).

VE[g*K/kPa] is off, but it is proportional to VE[%], so this means I have to discover the correcting constant (I have to do a units analysis see what is missing).

:)

[WeathermanShawn]

Good work there Joe.

Yea, I see the same unit problem using g*k/kPa. I can't tell if it is the LTFTBEN multiplication (%) factor or elsewhere. Like you said VE % works fine.

I'm using the same cal_pids.txt..

[TunasTwins]

What is the difference with how Tunercat display the table compared to Efilive?

Well I dont know what EFI Live displays unless someone has a stock file for an 05 4.8L:sly: The OS is 12592618....Quote from TC help file: The values is this table are expressed in grams per cylinder per second. These values can be converted to %VE which was used in earlier calibrations using the following formula:

%VE = 0.2871 x VE / CV

where VE is the value from the table and CV is the volume a one cylinder in liters.

It would be lots easier to conceptualize VE if it were in percentage.

[joecar]

Good work there Joe.

Yea, I see the same unit problem using g*k/kPa. I can't tell if it is the LTFTBEN multiplication (%) factor or elsewhere. Like you said VE % works fine.

I'm using the same cal_pids.txt..
It's not the LTFTBEN... it is the large constant being incorrect...


I analyzed the VE[g*K/kPa] equation, read on (see below for how I arrived at it):

when I use the following it equals with my B0101 exactly:
VE[g*K/kPa] = {SAE.MAF.gps} * {CALC.DAT.K} * 15 / {SAE.RPM} / {SAE.MAP.kPa} * {CALC.LTFTBEN}

where CALC.DAT.K is definend as {GM.DYNAIRTMP_DMA.C}+273.15

I'll edit the calc_pids.txt and post it later today.



In one cycle (4 strokes) (2 revs) all N cylinders are filled/emptied once.

Time for one cycle (2 revs):
t[s] = 2[rev] * 60[s/min] / RPM[rev/min]
= 120[s*rev/min] / RPM[rev/min]

Mass of air thru engine in one cycle (for N cylinders):
VE[g] = MAF[g/s] * t[s]
= MAF[g/s] * 120[s*rev/min] / RPM[rev/min]

Mass of air normalized for temperature and pressure in one cycle (for N cylinders):
VE[g*K/kPa] = VE[g] * DAT[K] / MAP[kPa]
= MAF[g/s] * DAT[K] * 120[s*rev/min] / RPM[rev/min] / MAP[kPa]

Normalized airmass per cylinder (in an N cylinder engine):
VE[g*K/kPa] = MAF[g/s] * DAT[K] * 120[s*rev/min] / RPM[rev/min] / MAP[kPa] / N

When N=8, normalized airmass per cylinder becomes:
VE[g*K/kPa] = MAF[g/s] * DAT[K] * 15[s*rev/min] / RPM[rev/min] / MAP[kPa]


where: DAT[K] = DYNAIRTMP[K] = DYNAIRTMP[°C]+273.15[°C]

Units analysis shows the correct units on both sides of the equation.

So, in calc_pids.txt, after applying LTFTBEN and rearranging, VE[VE] becomes (for 1 of 8 cylinders):
VE[VE] = {SAE.MAF.gps} * {CALC.DAT.K} / {SAE.RPM} / {SAE.MAP.kPa} * 15 * {CALC.LTFTBEN}

The units [VE] is shorthand for [g*K/kPa]

Notice that VE[VE] is not dependent on air density or IGL.

:)

[joecar]

To get VE[%]...

VE[%] is the actual airmass as a percentage of the theoretical airmass...

This can be calculated for the whole engine, or for an individual cylinder, the same result either way (the cylinder count cancels out)...

I did it for the whole engine as it is simpler:



Ideal Gas Law equation:
P[Pa] * V[m^3] = n[mol] * R[J/K/mol] * T[K] = (m[g] / M[g/mol]) * R[J/K/mol] * T[K]

where:
M = 28.96[g/mol] = molar mass of air
R = 8.31447[J/K/mol] = Universal gas Constant
T = DAT[K] = DYNAIRTMP[K] = DYNAIRTMP[°C]+273.15[°C]
P = MAP[Pa]
V = displacement[m^3] of engine (all N cylinders)

Theoretical air mass of engine displacement (rearrange IGL):
m[g] = V[m^3] * MAP[Pa] / DAT[K] * M[g/mol] / R[J/K/mol]

Note:
1[Pa] = 1[N/m^2] = 1[J/m^3] since 1[J] = 1[Nm]
1[kPa] = 1000[Pa]
1[m^3] = 1000[L]

So, converting to [L] and [kPa]:
m[g] = V[L] * MAP[kPa] / DAT[K] * M[g/mol] / R[J/K/mol] * 1000[Pa/kPa] / 1000[L/m^3]
= V[L] * MAP[kPa] / DAT[K] * M[g/mol] / R[J/K/mol] * 1[Pa/kPa*m^3/L]
= V[L] * MAP[kPa] / DAT[K] * 28.96[g/mol] / 8.31447[J/K/mol] * 1[Pa/kPa*m^3/L]
= V[L] * MAP[kPa] / DAT[K] * 3.4831[g*K/kPa/L]

So, mass volumetric efficiency of engine (for N cylinders):
VE[%] = VE[g] / m[g] * 100[%]
= MAF[g/s] * 120[s*rev/min] / RPM[rev/min] / V[L] / MAP[kPa] * DAT[K] / 3.4831[g*K/kPa/L] * 100[%]
= MAF[g/s] * DAT[K] * 3445.2[s/g*kPa/K*rev/min*L*%] / RPM[rev/min] / MAP[kPa] / V[L]


Units analysis shows the correct units on both sides of the equation.

If you did this per cylinder, then the expression would be:
VE[%] = (VE[g] / N[cyl]) / (m[g] / N[cyl]) * 100[%] = VE[g] / m[g] * 100[%]

and it would come out the exactly same since N[cyl] divides out.

So, in calc_pids.txt, after applying LTFTBEN, VE[%] becomes (for 5.7L displacement):
VE[%] = {SAE.MAF.gps} * {CALC.DAT.K} / {SAE.RPM} / {SAE.MAP.kPa} * 3445.2 / 5.669 * {CALC.LTFTBEN}

Notice that VE[%] is dependent on air density (expressed by the IGL).

:)

[WeathermanShawn]

Wow..

I think I need to break out some of my math books!!!:).

I'll probably have to wait to see how you get it worked out. Its been a while since I crunched that much algebra..

[5.7ute]

Well I dont know what EFI Live displays unless someone has a stock file for an 05 4.8L:sly: The OS is 12592618....Quote from TC help file: The values is this table are expressed in grams per cylinder per second. These values can be converted to %VE which was used in earlier calibrations using the following formula:

%VE = 0.2871 x VE / CV

where VE is the value from the table and CV is the volume a one cylinder in liters.

It would be lots easier to conceptualize VE if it were in percentage.

Using edit/properties Efilive can display in
g*K/kpa
% of theoretical maximum
g/cyl
g/sec
I thought that by doing the log & converting the units in the Efilive tune tool you would be able to do a straight cut/paste into the tunercat file. The tunercat units make no sense to me. You would think it would be either g/cyl or g/sec.

[TunasTwins]

I thought that by doing the log & converting the units in the Efilive tune tool you would be able to do a straight cut/paste into the tunercat file. The tunercat units make no sense to me. You would think it would be either g/cyl or g/sec.

I just discovered the properties table and thought it was my aha moment for the day. It doesnt work however. I have made the VE table, smoothed it three passes and need to convert it back to grams/cylinder/sec and then go for a log. My MAF was nearly dead on but I'll make sure to take care of that too. Hopefully I can get some good/verifiable data for WeathermanShawn's theory.

[TunasTwins]

Here are the first two logs. both drives were about 25 minutes mostly interstate driving last night. I've looked at the fuel trims and have adjusted the VE table to get me closer in the lower map higher rpm areas. I am going to flash and log again shortly (hopefully). I have a remote start Viper alarm I've been meaning to get installed for two months so maybe I'll drive to the guy today. Its a good 30 mile drive so I should get a much better log this round.

[WeathermanShawn]

To me (other than KR) this looks like an good tune.

MAF, and Trims are nailed down (LTFTBENS), and when you look at his DYNAIR and CYLAIR they are as perfect as you can get.

The CALC.VE Table looks good.
Thanks TunasTwins:cheers:...

[Wolfie]

What am I missing here...
the pids:
GM.CYLAIR.DMA
GM.DYNCYLAIR.DMA
GM.DYNAIRTMP_DMA
are not valid for me.

[WeathermanShawn]

Wolfie, I am definitely not the computer expert..but here is what I usually do if I can not validate a PID.

I make sure I am running the latest software and firmware. I actually hook up the scantool and in my case a laptop, and under "INFO" on the Scantool I enter "Validate PIDS".

Those are fairly common Pids, so I would be surprised if you can not get it too work.

If you run into further problems, I am sure we will get you some more help.

[Wolfie]

I've done that... I have a laptop in the van. I will try again though...

[TunasTwins]

To me (other than KR) this looks like an good tune.

MAF, and Trims are nailed down (LTFTBENS), and when you look at his DYNAIR and CYLAIR they are as perfect as you can get.

The CALC.VE Table looks good.
Thanks TunasTwins:cheers:...
Can you expand on this for me? I felt I had a ways to go as all trims were not negative, with fuel being added at 2400-4000RPM/25-55KPA range.

Here's an a log I mad after FINALLY getting my remote start alarm installed. I know if off topic but I put it off for two months so I stoked that I got it done... The only change was to the stoich AFR vs. %alcohol in fuel table. I changed it to 14.37 to adjust for the E10. I did not change the O2 switch point yet as I was unsure if this table would have an effect.

[WeathermanShawn]

Tunas:

I always look at the DYNAIR (SD) and CLYAIR (MAF) g/cyl and see how closely they match. Thats really 90% of the theory of tuning the MAF Airflow and VE Table (SD) to replicate each other. For instance if you had +10% Trims, and just changed the Injector Flow Rate (IFR), your Trims might be perfect, but your DYNAIR and CYLAIR would still be off.

Does that make sense?

As far as your Trims. I am not as nit-picky as I used to be to get them all perfectly in that -1 to -3 range. I actually aim for as close to zero (0) as I can. It makes my tuning of WOT AFR easier. You see, if you are MAF-enabled, by the time you get above 2400 RPM and especially as you approach 4000 rpms and hit PE mode..you can really see the MAF beginning to take over the command of the WOT AFR. So, I really try to concentrate on the workable portions of the VE Table. When I say workable, I also think of what if the MAF failed..I do tune as much of the VE Table as I reasonably can. When I looked at your previous log, I concentrated on looking at your MAF frequencies and Trim..they looked as good as mine..and I have done over 50 log runs to test out this method.

I am not as versed about the E10 stoich and AFR/switchpoints as you are, so I may have to get you some help on that one.

Sorry for the book response. Hope that helps..

[RevGTO]

I'm having a problem with the LTFTBEN table. First, all the results are 1.0. Second, when I go to paste and multiply into B5001, I get a pop-up saying "Cannot find any matching row/col labels, no data has been pasted."

AFAIK, I have followed the tutorial exactly ... the MAFFREQ values chart properly. I even tried substituting Mass Airflow g/s for RPM in the column, but same result. What am I doing wrong?

[WeathermanShawn]

Hey RevGTO:

If you are computer savvy enough to post up that PIDS you are logging, and a copy of the MAP that will not transfer..that could really help.

Otherwise, my guess is that somehow LTFTFT1 and LTFTFT2 are not being logged? Obviously you need both banks to calculate LTFTBENS.

Perhaps if you could post up your calc_pids.txt file we could make sure the LTFTBEN formula is right.

Sorry to make you do the computer work to figure it out. Its a necessary evil. It took me half a day to figure out how to do attachments and screen-shots..But, people who do almost always get their questions answered.

Thanks for you patience. I have used Joecar's following link to help me figure out how to post up those screen-shots..http://forum.efilive.com/showthread.php?t=3064

Thanks..

[mr.prick]

In the map properties (data tab) change the precision to 2 or 3.

[RevGTO]

In the map properties (data tab) change the precision to 2 or 3.Good suggestion. The precision did not match between the scan and the tune, so I set them to match and tried it, and no go. But increasing the precision did show the scan results.

Then I tried copy and paste/multiply without labels and it worked. The labels are the same, so after thinking about it, why would they need to be copied back to the tune table?

[WeathermanShawn]

RevGTO, if I am following you here..

Did you ever get any data for LTFTBENS?

If you are asking why would you need to copy Table B5001 with the corrected LTFTBENS back into your tune. Thats how you calibrate the MAF.

Otherwise you will have difficulty getting your Trims in line. And the Calc_VE Table utilizes the values(g/s) from Table B5001.

So you need LTFTBENS working, and Table B5001 is essential.

[RevGTO]

RevGTO, did you ever get any data for LTFTBENS?Yes. When I increased the precision on the data units, then the deviations from the base tune became apparent. So I pasted/multiplied them in (again, it worked without labels) to my B5001.

Yesterday's logging was a preliminary effort to test the tuning system. Hopefully, with better weather tomorrow and decent road conditions (it snowed today here in KS) I will be able to do some more extensive logging.

I realized after yesterday that with an automatic one will have to shift manually through the gears to get a good distribution of hits on the cells. That is apparent from the way the hits are clustered.

So I've modified my tune with the initial results and will continue with more logging. It will be interesting to see if the modified cells change again.

[mr.prick]

The labels of the map must match the table exactly for paste with labels to work.
COL={GM.MAFFREQ}
ROW=Value

Re-paste the labels in the map properties and see if that works.

[RevGTO]

I tried copy and paste/multiply without labels and it worked. The labels are the same, so after thinking about it, why would they need to be copied back to the tune table?The labels are exactly the same, and like I said when I pasted/multiplied back to B5001 without labels, it worked. Is there any reason that copy and paste/multiply without labels would yield a skewed result, if the labels end up the same?

[RevGTO]

The labels of the map must match the table exactly for paste with labels to work.
COL={GM.MAFFREQ}
ROW=Value
BTW, the tutorial has it inverted: COL=MAFFREQ, ROW=Value

[mr.prick]

I screwed up. :doh:
it should be:
ROW={GM.MAFFREQ}
COL=Value

If only paste and multiply won't work then there is something wrong with the map labels.
Post your map.

Pasting with labels is good for specifically selected cells,
if you copy the whole map and paste over the whole table that works as well.
Paste with labels is best IMO.

[joecar]

RevGTO, can you post some screenshots of your scantool map and your tunetool B5001 table.

[ display the map or table, do Ctrl-PrtScrn on your keyboard, then paste this into a Microsoft Paint file... then Reply to this thread, click Go Adavnced and then Manage Attachments. ]

When you created the map in the scantool, did you do these steps:
- in tunetool, copy-with-labels of B5001,
- in scantool, for each or row and column properties, Paste (without copying anything else in between).

The scantool map's axis's must look exactly like the B5001 axis's (including decimal digits).

[RevGTO]

Ok, guys, Here is the LTFTBEN table. After messing with trimming the image down in Paint, and saving it as a jpg, I finally got it to upload.

[RevGTO]

Here are the B5001 files; #1 is the file before the paste/multiply of the LTFTBEN results; #2 is after.

[WeathermanShawn]

Just eyeballing the table, it looks fine.

If you have a calculator, or can do math in your head..just check a few frequencies vs LTFTBENS..I.E. 4000 Hz X LTFTBEN = New Value, etc..

Its the only Table where you have to paste and multiply (with labels). I could probably figure out a way to eliminate that step..but it seemed more work to do that, than to just putting the new values back into the tune.

Then if you do another CALC.VE Table log..the precision and accuracy just gets better, as your MAF Freq (g/s) vs LTFTBENS becomes even more accurate.

Overall, how were your results?

[joecar]

RevGTO,

On the scantool map, does the second column say "Value" at the top (in post #126)...?

If it doesn't then paste-with-labels won't work.

[ it probably says "RPM"... in the map properties, on the Col tab, change the Title to "Value". ]

[mr.prick]

http://forum.efilive.com/attachment.php?attachmentid=7405&d=1269203449
This map does not have matching labels, this is why you can't paste w/labels.

[joecar]

I have worked out the equations from first principles to gain an understanding of the big constants (and their units)...

The equations I came up with are in the attached calc_pid.txt.

Original equations: we don't really know where they came from, Paul doesn't have that info anymore...
New equations: I understand the equations, constants and unit analysis.

The differences between the new ones and the original ones:
- VE[%]: the new one is about 1% less than the original.
- VE[VE]: the new one is about 18% less than the original (and matches my existing B0101).

note: [VE] units is a shorthand for [g*K/kPa].

So, try the tutorial with the new equations and see how you go.

Use VE[%] if your B0101 table is in %.
Use VE[VE] if your B0101 table is in g*K/kPa.

:)

See here for derivation:
showpost.php?p=117044&postcount=103 (http://forum.efilive.com/showpost.php?p=117044&postcount=103)
showpost.php?p=117048&postcount=104 (http://forum.efilive.com/showpost.php?p=117048&postcount=104)

[WeathermanShawn]

Joecar is being very humble when he said he 'worked out the equations'.

His actual work would probably take up half a page. He made something very difficult easy (at least to me). Thanks for the mathematical insight! It makes me wonder if VE Tables were really all done on a dyno, or mathematically solved in a similar manner...

Thanks..:cheers:

[RevGTO]

This map does not have matching labels, this is why you can't paste w/labels.I thought "matching values" meant that the LTFTBEN table had to have the same row numeration as B5001 - which it does. Do you mean to say that since the data begins on the 8th row, that copy with labels won't carry over the first 7 blank rows - and so the table is misaligned, and doesn't have "matching values"?

And here's a shot of the column set up, as that has been questioned ...

[joecar]

RevGTO, the column heading should say "Value" with an uppercase "V", same as table B5001 (your pic shows "value").

[joecar]

Shawn, thanks for the kind words... :cheers:

I hope I did learn something 30 years ago and not just warm the bench at school... :doh2:

[Blacky]

The differences between the new ones and the original ones:
- VE[%]: the new one is about 1% less than the original.
- VE[VE]: the new one is about 18% less than the original (and matches my existing B0101).

My math is maybe not so good, which would explain the difference :doh2:
Paul

[RevGTO]

RevGTO, the column heading should say "Value" with an uppercase "V", same as table B5001 (your pic shows "value").Ok, thanks. It's shown in lower case in the Tutorial, so if that's erroneous, correction needed there.

[joecar]

Ok, thanks. It's shown in lower case in the Tutorial, so if that's erroneous, correction needed there.Thanks. Noted. The tutorial will be updated.

[WeathermanShawn]

Thanks everybody for the feedback.

I will try to post up a list of Tutorial Typos, updates, etc..

It is always smarter to get them all corrected in one big update, but we realize people are using the Tutorial in its current form.

Other than the necessary 'computer work', has this method of tuning made tuning easier or simpler? Any feedback on the actual tuning method itself?

Thanks..

[joecar]

Once you setup the maps it's pretty simple, one log gives pretty good results (with filtered out throttle transients, as said in the tutorial).

[TunasTwins]

RevGTO, the column heading should say "Value" with an uppercase "V", same as table B5001 (your pic shows "value").
Explains why I couldnt multiply with labels. Thanks. I'll try the new formula in the next two days.

[WeathermanShawn]

So far these are the Typographical errors noted with the Tutorial, or where clarification is needed.

If anybody notes any others, please post them up.

Thanks..



***Tuning Tutorial Changes:***


Page 2: Update calc_pids.txt
Provide Link to Text Thread?

Page 6: Line 10. Last word value, should read Value.

Page 7: Change Filter to Read SAE.ECT.C less than or equal to 80C

[joecar]

Yes please, if anyone has found anything that needs fixing, please post.

[RevGTO]

Update: I did a base run, adjusted my VE & MAF tables, and then did a number of logs with the altered tune. My results so far show a fair amount of variability between the logs. For example LTFTBENs vary from the 1.00xxx range to the 0.97xxx range for the same hz category from log to log.

I had been using a downloaded VE table from Holdencrazy from a car with very similar mods. The VE results have been consistent enough for me to have established my own baseline B0101, with generally lower VE% numbers than downloaded table I was running.

Fuel trims have stayed close to what they were in my previous tune, but vary some from log to log. One was nearly ideal in the the -3 to +0.8 range, with the exception of numbers as high as +4 at 0%TPS in decel. My car has always tended to trim upon decel for some reason. I should say that my previous tune was developed when I ran OLMAF for a year; I continually adjusted my MAF calibration to get my actual fueling in line with commanded. Thus my MAF/VE combo was fairly close resulting in decent fuel trims even before factoring in the CALC VE results.

I'm going to take some more logs with my freshly edited Main VE table. If those results continue to fall within range, then another LTFTBEN adjustment should get it squared away.

My only issue is PE. My results so far indicate it is off. But it is hard to do extended runs at WOT on local streets and highways. I'm not going to be able to get a good indicator there until we have some decent weekend weather and I get the car to the strip.

[WeathermanShawn]

RevGTO:

Thanks for the report.

It was very informative. Believe it or not that swing in LTFTBEN's is not that uncommon. Weather changes, fuel type, even your fuel level can sometimes alter the Trims.

But, it is important to get consistency. And it sounds like you have. Your right, probably by run 3 you can be dialed in.

Trims on Decel. Always an interesting topic. So many of these Trims get locked in early on the learning curve. Just depends on your year of vehicle and what Fuel Trim Cell (FTC) you are in. Sometimes Decel gets it own unique FTC, and once its hard to budge some of the Trims in those cells.

More worrisome is PE. This method relies on the narrowbands and its relationship with LTFTBENS. Obviously PE ignores the narrowband feedback and requires a little more finesse to get it right. Suffice to say, if you can enter PE Mode with 0+ Trims, then you just need to look at the % difference between Commanded and Actual AFR (BENS) and adjust the MAF Freq accordingly.

Perhaps at some point the Tutorial can link to 'Methods of WOT Turing'..as it does require a some different approach. The challenge in writing a Tutorial was not only where to begin, but where to stop. Hopefully in the future we can figure out a way to combine Idle and WOT Tuning into a series of Tutorials.

Thanks for the feedback. Hope you can get your WOT Tuning done. Its only 10% of the VE Table, but arguably the 10% that is the most fun :grin:!

[TunasTwins]

We've got two documented trials now. Lets keep them coming guys! I'll get more data next Tuesday or Wednesday.

[RevGTO]

Believe it or not that swing in LTFTBEN's is not that uncommon. Weather changes, fuel type, even your fuel level can sometimes alter the Trims.You're so right. I took one of my logs after putting some gas in the car, and the results went wildly off ... LTFT's in the -12-13 range. MAF readings too. I dropped that log when I factored in my results.

One thing that I've learned from this approach to tuning is that there is a certain statistical margin of error in logging that cannot be overcome. That probably has to do with the fact that all the factors in the system cannot not fully accounted for.

As a result of this tuning approach, my VE table is undoubtedly closer than it's ever been. I've given my MAF tables another round of adjustments from LTFTBEN multipliers ... we'll see where that gets me when I log tomorrow. If my fuel trims are still overactive, then I know I can manually bump my MAF settings to where my LTFT's are close to ideal.

[WeathermanShawn]

Thanks RevGTO:

Looks like you and at several others have had been reasonably successful in following the Tutorial. We will 'polish' up some of the typo's and update the calc_pids.txt information shortly.

I think it was very perceptive of you to see the normal variances in tuning, and to know when you are within the tuning 'zone'. It is a good idea to manually tweak when logging and tuning has taken you as far as you can go.

Thanks to you and to the others who have helped..:cheers:

[mr.prick]

After filling up your gas tank, the cold fuel will throw LTFTs off for awhile.
Wait until LTFTs settle down before making changes otherwise
any adjustments made will be exaggerated and need to be undone later.
LTFTs get highly negative after I fill up the tank.

[DrkPhx]

Need some help. I finally got the Calc VE table to work, however the displayed values in the map are wacked out (way too high). I looked at the pid display in the scan tool and noticed it wouldn't let me select % or VE and the displayed values in the Units column are g*k/kPa,%. Can someone take a look at the attached txt file and see what's wrong? TIA

[WeathermanShawn]

I noticed that was your sae_generic.txt file.

I think you want it as your calc_pids.txt file. Look under 'Tuning' after you add it (My documents..user configuration..).

I have attached Joecar's latest calc_pid.txt file..Just make sure the displacement takes..You may have to enter the amount in Liters..per the Tutorial..

Just make sure you have DYNAIRTMP & LTFTBENS, MAF (g/s)selected also.

That should do it..

[joecar]

DrkPhx,

Try the attached sae_generic.txt file (it has your 6.587L displacement)...

Be sure to use CALC.VE_Table a rather than CALC.VE.

[DrkPhx]

Thanks Joecar. I see the option to select the different units now, but I'm still getting wacked out values in the scantool map.

For the "VE" map there are values between 1.21-1.47 in the lower rows. When the same values are displayed in % they range between 44-62%. Maybe I'm missing something; but that's a huge difference.

[WeathermanShawn]

Hey DrkPhx:

Probably need to see that log if you have time.

Generally (depending on displacement) a '100'% VE' equates to ~ 2.49 g*k/kPa. Of course that depends on DYNAIRTMP, air density, etc..

It is confusing. There is a CALC.VE and a CALC.VE Table. And you have to make sure displacement is being properly calculated.

If it makes you feel any better..once you get it..it is never hard again!

If you have successfully logged all the PIDS, Joecar or I can double-check your CALC.VE Table %'s on this end.

[DrkPhx]

I'm definitely logging the Calc.VE_Table pid. I don't have the Calc.VE pid selected.

I just looked at my pids and didn't even realize GM.DYNAIRTMP.DMA is coming up invalid and not logging. I have it set to C.

[joecar]

I'm definitely logging the Calc.VE_Table pid. I don't have the Calc.VE pid selected.

I just looked at my pids and didn't even realize GM.DYNAIRTMP.DMA is coming up invalid and not logging. I have it set to C.That's what's causing the VE values to be wrong...

Which year/model and OS id do you have... (the latest V7.5 software has an update for '97/'98 OS 19980200)... Edit: I am mistaken, I confused this with something else, sorry.

if your OS doesn't have DYNAIRTMP_DMA, then you can approximate it using 0.85*ECT+0.15*IAT or by looking up the temperature blend table.

[redhardsupra]

if your OS doesn't have DYNAIRTMP_DMA, then you can approximate it using 0.85*ECT+0.15*IAT or by looking up the temperature blend table.

Joe, what's the basis for this estimator?

[DrkPhx]

That's what's causing the VE values to be wrong...

Which year/model and OS id do you have... (the latest V7.5 software has an update for '97/'98 OS 19980200)...


It's 98 OS 19980100.


if your OS doesn't have DYNAIRTMP_DMA, then you can approximate it using 0.85*ECT+0.15*IAT or by looking up the temperature blend table

How close is that formula to the pid? Can someone do a quick comparison between the two and see how close the net values are?

[Ninety8C5]

That's what's causing the VE values to be wrong...

Which year/model and OS id do you have... (the latest V7.5 software has an update for '97/'98 OS 19980200)...



Where did you find that ? I just checked OS 19980400 (that's the one I asked for) and a quick check of OS 19980200 and they are both X out as not valid. Is there something else I need to look at? Do I need to re-validate PIDs?

Thanks.

[WeathermanShawn]

Hey Guys & Gals:

Its possible Joe may have went to church or slept in. I am sure he can explain the 'estimator'. It merely an attempt to approximate the 'charge temperature blending' (B4901)..though it varies a lot by OS and year.

The Look-Up Table 'works', but has a problem with Low Airflow (< 10 g/s) in interpolating.

The difference between CALC.VE Table (with DYNAIRTMP) and the the older CALC.VE (No DYNAIRTMP) is ~ 3-9 %. CALC.VE Table will be greater and is highly advised to use (and also very accurate..I.E. MAF Failure verified..) I am sure Joecar can track down the status of the DYNAIRTMP PID..

Attachments Follow..

[mr.prick]

Where did you find that ? I just checked OS 19980400 (that's the one I asked for) and a quick check of OS 19980200 and they are both X out as not valid. Is there something else I need to look at? Do I need to re-validate PIDs?

Thanks.

Sometimes PIDs are invalid until you start logging or monitoring.
Select them anyways and start logging/monitoring to see if they become valid.
Of course calc_pids need their dependent PIDs selected to be available.

[joecar]

...

if your OS doesn't have DYNAIRTMP_DMA, then you can approximate it using 0.85*ECT+0.15*IAT or by looking up the temperature blend table.


Joe, what's the basis for this estimator?


...

How close is that formula to the pid? Can someone do a quick comparison between the two and see how close the net values are?
It was late last night when I typed that... :doh2::doh2::doh2::doh2: <- me slapping upside my head 4x

Sorry, I had meant to type this: 0.85*IAT+0.15*ECT

i.e. it should biased toward IAT.

I intended that as a simple estimation, exactly what Shawn guessed I was doing...

I say this from looking at B4901 and from observing DYNAIRTMP_DMA say when VSS > 30 mph in various logs...
I should have instead said to study B4901 for your airflow range, which brings us to the next point:

A more accurate way to do this is to do a lookup of the B4901 values as suggested by mr.prick earlier in this thread...
and this is exactly what Ninety8C5 did: showpost.php?p=118165&postcount=29 (http://forum.efilive.com/showpost.php?p=118165&postcount=29)

[ but this still doesn't factor in B4902 ]

:)

[joecar]

Where did you find that ? I just checked OS 19980400 (that's the one I asked for) and a quick check of OS 19980200 and they are both X out as not valid. Is there something else I need to look at? Do I need to re-validate PIDs?

Thanks.

I see you have already found this: showthread.php?t=13320 (http://forum.efilive.com/showthread.php?t=13320)

Hmmm... I though I had seen an update for 19980200...:doh2:...I don't know now what I had been looking at (sorry).

Do what mr.prick said, Validate Pids.

[joecar]

Ok, I'm confused... I pm'd Tech Support regarding the 19980x00 os's support of these pids:

GM.CYLAIR_DMA
GM.DYNCYLAIR_DMA
GM.DYNAIRTMP_DMA

If DYNAIRTMP_DMA isn't supported, then the lookup of B4901 would be the way to go.

:)

[DrkPhx]

Ok, I'm confused... I pm'd Tech Support regarding the 19980x00 os's support of these pids:

GM.CYLAIR_DMA
GM.DYNCYLAIR_DMA
GM.DYNAIRTMP_DMA

If DYNAIRTMP_DMA isn't supported, then the lookup of B4901 would be the way to go.

:)


Joecar - Any updates on this?

BTW - Both GM.CYLAIR_DMA and GM.DYNCYLAIR_DMA work fine for me, it's just the GM.DYNAIRTMP_DMA that doesn't work.

[joecar]

Ok, I'm told that those do not exist for the 1998 OS's... sorry.

So the next best thing is to use the lookup(B4901) method, see Ninety8C5's link in my post above (post #162).

[Ninety8C5]

It was late last night when I typed that... :doh2::doh2::doh2::doh2: <- me slapping upside my head 4x

Sorry, I had meant to type this: 0.85*IAT+0.15*ECT

i.e. it should biased toward IAT.

I intended that as a simple estimation, exactly what Shawn guessed I was doing...

I say this from looking at B4901 and from observing DYNAIRTMP_DMA say when VSS > 30 mph in various logs...
I should have instead said to study B4901 for your airflow range, which brings us to the next point:

A more accurate way to do this is to do a lookup of the B4901 values as suggested by mr.prick earlier in this thread...
and this is exactly what Ninety8C5 did: showpost.php?p=118165&postcount=29 (http://forum.efilive.com/showpost.php?p=118165&postcount=29)

[ but this still doesn't factor in B4902 ]

:)

The 1998 OS's don't have B4902.

[joecar]

The 1998 OS's don't have B4902.That's one less thing to worry about... :)

I think the lookup of B4901 will work pretty good (GM did spend many man-hours on this).

:)

[joecar]

Here is the current calc_pids.txt file for the tutorial (works for VE[%] and VE[g*K/kPa]).


The pdf is included in the latest install of V7.5.

[stigmundfreud]

cheers Joe! I saw that thread the other day but didnt think it applicable due to e38 but if it does the MAF its worth a shot

PS do you not know where anythings located ;)

[joecar]

There's so much stuff that I keep forgetting where it all is... :doh2:

[redhardsupra]

The pdf is included in the latest install of V7.5.
Why?

[joecar]

Along with the other tutorials...

We are able to reconcile units correctly.

It's easy-to-do in 1 pass (gives a first-timer confidence).

It does point you further to things like AutoVE.

:)

[Wolfie]

http://forum.efilive.com/images/icons/icon14.gif

[SOMhaveit]

I must be missing something here. I set this up and did a few runs to log data and my MAF calibration has the fuel trims much better, but I'm not sure what to do with the data for the VE Table. The tutorial says to copy with labels and then paste with labels to the VE Table. My VE data map shows numerical values like 1.1, 1.9, 2.5.

Is that indicating my VE Table is off by 10%, 90%, and 150%? Should the Scan Tool map be copied with labels and then pasted and multiplied to the Tune Ve Table?

I have a head ache.

[WeathermanShawn]

Somhavit:

Probably best if you post a new thread..I.E. the 18 page thread is getting a little crowded..:).

Always best if you can post a tune and log (or some screen-shots). Its hard to know exactly what is happening, but it sounds like a unit 'problem'. Perhaps you are utilizing default VE units (and thats O.k.), or did you want percentages?

As long as you are logging DYNAIRTMP, MAF Freq (Hz), MAF Airflow (g/s), and LTFTBENS..you should be O.K. Keeping all units Metric, makes the equations go flawlessly. The VE units should be both in %'s and g*K/kPa..

Post up a new thread..Title it..[..CALC.VE Table Tutorial..need help please..]. If you do that I promise you will get some constructive help.
Let us know..:cheers:

Edit: The CALC.VE Table from the Scan Tool only needs to be pasted..not pasted and multiplied..All the values have already been 'multiplied' in the formula..its all to make that step even easier..:)

[joecar]

What units are you displaying the B0101 VE table in (g*K/kPa or %)...?
What units are you displaying the tutorial VE map (g*K/kPa or %)...?

[SOMhaveit]

I see my error now. I needed to use the % VE Table in the Tutorial. Thanks.

[joecar]

Same as the units being used to display B0101.

[picnic_george]

Any idea how to do something like this on an ls2 e40 pcm?

I'll be trying this on my 98 ls1 and see what happens. Got the autove/automaf thing working out and have been very satisfied with how it works. Still got some tweaking to do but it runs good. :)

[WeathermanShawn]

Picnic:

Any vehicle that has a MAF and can run Closed-Loop..it is possible. Of course I used my 'Donor Car' (my own) for most of the CALC.VE tuning. Also, you need to have the DYNCYLAIR.TMP to really make it all tie in.

Glad to hear things are working out. There are many avenues to good tuning.

Good luck..

[picnic_george]

I have no problem with trial and error with my own car. Makes tuning fun. :) I can try it with this GTO it's not a big deal its my best friends car. Just not as easy as it is on my car that's sitting in my garage everyday. Guess I'll start with what I know and do it that way. Maybe in the furture I can come up with something like that. Or maybe I'll just try it this way and see what happens hahahaha I'm always up for a new challenge

Thanks Shawn

[joecar]

Can you post the E40 .tun file.

[picnic_george]

Can you post the E40 .tun file.Here ya be..

[RevGTO]

This method relies on the narrowbands and its relationship with LTFTBENS. Obviously PE ignores the narrowband feedback and requires a little more finesse to get it right. Suffice to say, if you can enter PE Mode with 0+ Trims, then you just need to look at the % difference between Commanded and Actual AFR (BENS) and adjust the MAF Freq accordingly. Perhaps at some point the Tutorial can link to 'Methods of WOT Turing'..as it does require a somewhat different approach. The challenge in writing a Tutorial was not only where to begin, but where to stop. I am bringing this back up from an old post for anybody who might be reading this thread contemplating a Calc VE tune. It's an important bit of info toward completing the tune. Since there is no narrowband feeback in PE mode, those LTFTBENs will show up as 1.000. As Shawn says, one has to manually adjust the appropriate MAFFREQ cells by the differential between commanded and logged AFR's to get PE fueling on target. It took me a couple of trips to the track and a few adventurous freeway runs to get my PE in line doing this.

[WeathermanShawn]

RevGTO:

It is an excellent point. I am very glad you brought it up. I will try to clarify.

In a MAF-Enabled Closed-Loop tune there will a certain MAF Frequency known as the 'PE MAF Crossover Frequency (Hz) or MCF. Depending on your PE TPS & RPM settings, all MAF Frequencies above the 'MCF' will no longer be in closed-loop. In fact they will be in Open-Loop as defined by the PCM.

The short summary is that that portion of the MAF Calibration Table will need to be tuned using the general techniques of the AUTOVE method. This utilizes a wideband and the use of AFRBEN's. It is the only method that will allow you to calibrate your Commanded AFR vs Actual AFR in PE Mode and WOT.

If you think about it, this method shares a lot of similarities with AUTOVE. It simply uses the narrowbands to solve the stoich (~14.63 AFR) closed-loop portion of the VE Table. Of course, its uniqueness is that it takes advantage of the PCM's reliance on MAF Airflow and Trims to determine a highly accurate and representative VE Table.

Could the CALC.VE Tutorial be expanded to cover this portion of tuning? Yes. I left this portion of the Tutorial purposely open, since wideband AFR tuning is well-documented. I knew a few more astute tuners and deep thinkers would understand the connection.

So, congrats RevGTO you have hit that designation. If you ever get a tune and log that you want to share, let us know.
Thanks for sharing..:cheers:

[FeetDry]

I'm looking at the files in post 169. It appears the tutorial was last updated March 28.
Looking at the calc_pids.txt,...
It appears the displacement() has been replaced w/ 5.669. I'll guess this # is in Liters. True? (5.7L~= 350CuIn)
It wasn't clear to me if the call to displacement() was suppose to work. i.e. Is the call suppose to return a #? Where does this # come from, (PCM, EfiLive)? Is this suppose to work for all OS's, just specific ones? Is this suppose to work for only the latest version of EfiLive? (A manual entry will lead to errors down the road.)

What is the purpose of CALC.LTFT? I don't see it used in any of the other CALC PIDs. So, is it needed?

When there is no air temp PID, can I use DYNAIRTMP= 0.85*IAT+0.15*ECT for any OS? Or will this only work for LS1's? (This is just a best guess equation, right?)

[WeathermanShawn]

I'm looking at the files in post 169. It appears the tutorial was last updated March 28.

Yes. This was a Tutorial started from the efforts of 2-4 people (multiple contributors). We are logging errors and discrepancies. It makes more sense to make significant updates all at once, so please be patient.

Looking at the calc_pids.txt,...
It appears the displacement() has been replaced w/ 5.669. I'll guess this # is in Liters. True? (5.7L~= 350CuIn)

When this Tutorial was published there was still an unrelated software bug that affected any equations that included displacement. The figures are for a 5.7 Litre engine. By now, you should not have to manually insert the engine size..

It wasn't clear to me if the call to displacement() was suppose to work. i.e. Is the call suppose to return a #? Where does this # come from, (PCM, EfiLive)? Is this suppose to work for all OS's, just specific ones? Is this suppose to work for only the latest version of EfiLive? (A manual entry will lead to errors down the road.)

I believe it comes from the Scan Tool entry under Customer Details. I will check on your other inquiries.

What is the purpose of CALC.LTFT? I don't see it used in any of the other CALC PIDs. So, is it needed?

The method utilizes CALC.LTFTBENS. In closed-loop it takes the average of the LTFT Trims correction and applies them to the MAF Frequency. It is an essential tool to accurately calculate an equivalent VE Table for those running MAF-Closed Loop.

When there is no air temp PID, can I use DYNAIRTMP= 0.85*IAT+0.15*ECT for any OS? Or will this only work for LS1's? (This is just a best guess equation, right?)

There is a DYNAIRTMP.DMA Pid available for the LS1 PCM's. It is the heart of the method. Since the VE Table calculations utilize DYNAIRTMP it uniquely applies it to the corresponding MAF frequency/airflow. In its purest form, DYNAIRTMP is highly accurate. Other OS's without that PID must utilize a look-up table methodology, or use the 'best guess' equation referenced above.

Hope that helps..

WeathermanShawn..

[TunasTwins]

Hey guys, cant find dynairtemp on a buddies 99 vette PCM 9354896. What am I missing here?

[WeathermanShawn]

Hey guys, cant find dynairtemp on a buddies 99 vette PCM 9354896. What am I missing here?

On MY OS (12212156) it is found under 'Tune' on the Scan Tool...

[TunasTwins]

Well, its there- just not supported??

[WeathermanShawn]

Well, its there- just not supported??

A lot of times you just need to hook the Scan Tool up to the vehicle. using the Scan Tool..under Info..hit Validate Pids..

That usually does it for me. I am not the computer 'expert', so perhaps there is a newer and better way. The bottom line is that a number of 'Unsupported Pids' only become validated when you 'Key-on the Car'..with the Scan Tool connected.

Hope that does it for you.

[TunasTwins]

A lot of times you just need to hook the Scan Tool up to the vehicle. using the Scan Tool..under Info..hit Validate Pids..

That usually does it for me. I am not the computer 'expert', so perhaps there is a newer and better way. The bottom line is that a number of 'Unsupported Pids' only become validated when you 'Key-on the Car'..with the Scan Tool connected.

Hope that does it for you.
Thats what I did. It was the first time connecting to this vehicle so I had to validate PIDs but couldnt see dynairtmp. I'll have to try again

[WeathermanShawn]

TunasTwins:

If that does not work, I have been working on a few solutions for CALC.VE Table that involves a way around utilizing the DYNAIRTMP PID. I have to think it over a little more and run it by Joecar and some other math and engineering majors.

I have to catch some sleep right now (worked night shift), but I'll get back to you on it. There are just so many OS's that do not allow DYNAIRTMP, so I am working on a few ideas.

Hopefully then more MAF-equipped vehicles (closed-loop) can utilize the method.

Later..

[TunasTwins]

great news for everyone

[WeathermanShawn]

Well, here is just a tease.

The following is an attachment of CALC. LTFTBENS utilizing a total MAF failure (SD). This was utilizing the 'canned' version of EFILive's CALC.VE (without DYNAIRTMP).

8334

You can see the distribution of LTFTBENS across the VE Table.

It is higher when ECT is higher and airflow/Rpms are low. The LTFTBENS are lower where airflow/Rpm are higher. The distribution follows the charge temperature blending factor.

So, since you know the ECT, IAT, MAF Frequency, MAF Airflow..follows that you should be able to build a Calculated Pid that will compute this all after the fact.

Otherwise, you could add an average 'fudge factor' (not recommended at this point) or..just perform a CLSD tune. It comes out to be exactly what the CALC.VE Table looks like if properly done..

Food for thought. It still will take some work to perfect. Until then, lobby EFILive to include DYNAIRTMP wherever it is technically possible to 'Pid'..

[joecar]

Thats what I did. It was the first time connecting to this vehicle so I had to validate PIDs but couldnt see dynairtmp. I'll have to try againNot all OS's have that pid... Paul tells me that in some OS's that pid can't be internally located (the _DMA pids are lookups of internal PCM memory).

You do either of these:

- change OS to say 12212156 (you will need to copy all your tables over).

- make a calc pid to blend IAT/ECT based on lookup of B4901, see this:

A more accurate way to do this is to do a lookup of the B4901 values as suggested by mr.prick earlier in this thread...
and this is exactly what Ninety8C5 did: showpost.php?p=118165&postcount=29 (http://forum.efilive.com/showpost.php?p=118165&postcount=29)

[FeetDry]

What is the purpose of CALC.LTFT? I don't see it used in any of the other CALC PIDs. So, is it needed?

The method utilizes CALC.LTFTBENS. In closed-loop it takes the average of the LTFT Trims correction and applies them to the MAF Frequency. It is an essential tool to accurately calculate an equivalent VE Table for those running MAF-Closed Loop.WeathermanShawn..

I see that both CALC.LTFTBENS & CALC.LTFT take the average of both banks (LTFT). And I see that CALC.LTFTBENS is used in the %_VE table calculation. But I'm not seeing any use of the CALC.LTFT number. That is why I raise the question. Either it is not needed, or it has some use that is "hidden".

Is this needed: CALC.LTFT = ({SAE.LONGFT1}+{SAE.LONGFT2})/2

[joecar]

...
Is this needed: CALC.LTFT = ({SAE.LONGFT1}+{SAE.LONGFT2})/2It isn't needed other than for displaying the average in %.

We were possibly maybe going to write CALC.LTFTBEN in terms of CALC.LTFT:
CALC.LTFTBEN = {CALC.LTFT}/100+1

But it was simpler to keep CALC.LTFTBEN uncoupled from CALC.LTFT.

[joecar]

The calc_pids.txt file from post #169: [/URL][url=http://forum.efilive.com/attachment.php?attachmentid=7765&d=1272268658]calc_pids.txt (http://forum.efilive.com/attachment.php?attachmentid=7765&d=1272268658)


[ if you use [%] units, change the 5.669 to your engine's displacement in Litres ]



(http://forum.efilive.com/showthread.php?13152-New-Tuning-Tutorial-WeathermanShawn&p=120121&viewfull=1#post120121)

[joecar]

For the tutorial pdf and calc pids, see post # 169: showthread.php?13152-New-Tuning-Tutorial-WeathermanShawn&p=120121 (http://forum.efilive.com/showthread.php?13152-New-Tuning-Tutorial-WeathermanShawn&p=120121&viewfull=1#post120121)

[WeathermanShawn]

The CALC.VE Tuning Method has been Updated..

Please Link Here for Further Information:http://forum.efilive.com/showthread.php?15236-A-New-Twist-on-CALC.-VE-Table..Computing-the-Entire-VE-Table.&p=135867&viewfull=1#post135867