Tuning Notes by WeathermanShawn

[WeathermanShawn]

Here is a description of the CALC.VE method of Tuning.

I originally followed the current method of disabling the MAF and mapping my VE Table using the wideband and AFR BEN's as described in the Tutorials. I then followed the protocol of then 'calibrating' the MAF. I found the procedure of mapping the VE Table with disabling the MAF a little tedious, but in the end it was successful. However, once I enabled the MAF..I ran into trouble. It was a long and tedious procedure to match the SD Airflow. And went I went back to closed-loop..it was a lot of work to then get LTFT's to match up.

For those who run MAF and closed-loop, I have the following method to propose. First MAP MAF Frequency against your LTFT's. Apply the same filters that are normally suggested when you construct a VE Table. Then simply cut and paste the correction to the MAF Calibration Table found in your Tune. I then used the following EFILive Pid: CALC.VE.

Volumetric Efficiency {CALC.VE}:
% = {SAE.MAF.gps}*({SAE.IAT.C}+273.15)/((displacement()*61.024)*{SAE.RPM}*{SAE.MAP.kPa})* 212544

It is basically utilizing the MAF Airflow along with your RPM's and MAP. It also utilizes the IAT, and in the end utilizing a RPM vs MAP..you can easily construct a VE Table..just from the MAF output.

You must utilize a wideband! This is to verify that your narrow-band O2's are switching properly and maintaining stoich. Also, you must be commanding the proper AFR at WOT. It actually matches up fairly well to the original VE Table (SD method).

Feel free to add any comments, constructive criticism, or comments.

[mr.prick]

100% MAF first w/LTFTs then VE w/CALC.VE, or is VE changed the same time as MAF?
How are LTFTs applied, do you have a calc_pid?
Did you change the O2 switch points before using LTFTs?

Its fun to try to hit those high MAP areas @ mile high isn't it. :rockon:
At most I am able to hit 90kPa but only when I go down hill. :laugh:

[5.7ute]

Shawn, I believe that you must also calculate the IAT/ECT blending factor into your pid to get it closer. I will add something to try as soon as it quietens down here.

[5.7ute]

Something like this.
CALC.BLEND ="lookup({SAE.MAF}, 0.00,0.799805, 10.00,0.419922, 20.00,0.282715, 30.00,0.243652, 40.00,0.219727, 50.00,0.202637, 60.00,0.188477, 70.00,0.175781, 80.00,0.164551, 90.00,0.153809, 100.00,0.143555, 110.00,0.134277, 120.00,0.124512, 130.00,0.115234, 140.00,0.106445, 150.00,0.089844)"

% = {SAE.MAF.gps}*({SAE.IAT.C}+(({SAE.ECT}-{SAE.IAT})*{CALC.BLEND})+273.15)/((displacement()*61.024)*{SAE.RPM}*{SAE.MAP.kPa})* 212544

[WeathermanShawn]

100% MAF first w/LTFTs then VE w/CALC.VE, or is VE changed the same time as MAF?
How are LTFTs applied, do you have a calc_pid?
Did you change the O2 switch points before using LTFTs?

Its fun to try to hit those high MAP areas @ mile high isn't it. :rockon:
At most I am able to hit 90kPa but only when I go down hill. :laugh:

Yea, I am drastically limited by altitude! I can only hit ~ 82-84 kPa on a good day.I

I somehow settled on a O2 switch-point of 550 mv. Maybe just the way my car responded. But, it does give me stoich (wideband logged) when I MAP it.

[mr.prick]

Ok.
After MAF is done w/LTFT, then VE is molded w/calc_ve via straight paste.

[WeathermanShawn]

Ok.
After MAF is done w/LTFT, then VE is molded w/calc_ve via straight paste.

Perfectly stated! Do you think it has some validity?

[5.7ute]

It certainly has some validity. It would be interesting to compare the resultant AFR's going straight from maf to SD, after the VE table has been calculated in this manner.

[redhardsupra]

ok, i'm gonna be a science stickler again...
check your units, what does g*K/(sec*m^3*kPa) simplify to?

you do know that IAT != MAT and that cylinder airmass from MAF is already done for you in the form of CYLAIR, right? so then to solve for VE, all you need to do is start with CYLAIR=VOL*VE*MAP/(R*MAT), and rearrange to isolate VE so you end up in the form of
VE=CYLAIR*R*MAT/(VOL*MAP)

if you want dimensional analysis of it done, it's a bit convoluted, but it checks out clean. it's all in my 'how SD works' from four years ago.

[WeathermanShawn]

ok, i'm gonna be a science stickler again...
Check your units, what does g*k/(sec*m^3*kpa) simplify to?

You do know that iat != mat and that cylinder airmass from maf is already done for you in the form of cylair, right? So then to solve for ve, all you need to do is start with cylair=vol*ve*map/(r*mat), and rearrange to isolate ve so you end up in the form of
ve=cylair*r*mat/(vol*map)

if you want dimensional analysis of it done, it's a bit convoluted, but it checks out clean. It's all in my 'how sd works' from four years ago.

o.k.

[redhardsupra]

yes, it's all been solved. have you read any of my stuff? it's all there black on white. solving for VE, calibration of MAF, equivalence and transforming MAF to SD models... and then there's stuff I didn't publish because it's not 'production-grade'

[WeathermanShawn]

yes, it's all been solved. have you read any of my stuff? it's all there black on white. solving for VE, calibration of MAF, equivalence and transforming MAF to SD models... and then there's stuff I didn't publish because it's not 'production-grade'

Marcin, I have read your entire website. I don't see your tuning methods published.

It is a way of tuning using just the MAF and closed-loop tuning. No need to do a SD tune, or the traditional MAF Calibration. The bottom line is that both the MAF and VE Table accurately reflect the Airflow. As long as you have accurate WOT AFR's, and maintain stoich (using the narrowband O2's) and LTFTs, and verify with your wideband..saves a lot of steps, and gets you the proper AFR's required for a good tune.

[redhardsupra]

I absolutely agree that no matter what airflow model you're using, the airflows need to be identical. I will go even further with this statement, and say that they need to agree across the full range of airflows. What makes it difficult to compare them is that MAF is against a completely arbitrary frequency, and SD has the more naturally laid out airflow values, for different RPM/MAP tuples. If you want a wacky visualization, use the RPM/MAP map, use the MAF frequency as the data for it. You should see small groupings of similar frequencies within each cell, just like the corresponding airflows would.

It doesn't really matter which airmass model you start with. They are equivalent. That's what all of the 'three airmass models' writeup was all about. It combines WB data and fuel usage estimation to produce an airmass that you can map on either MAF or VE scales. I've done all kinds of transformation like this, MAF->VE, VE->MAF, fuel->both VE and MAF, wrong fuel mappings to right fuel mappings... basically, the method works.

[WeathermanShawn]

I absolutely agree that no matter what airflow model you're using, the airflows need to be identical. I will go even further with this statement, and say that they need to agree across the full range of airflows. What makes it difficult to compare them is that MAF is against a completely arbitrary frequency, and SD has the more naturally laid out airflow values, for different RPM/MAP tuples. If you want a wacky visualization, use the RPM/MAP map, use the MAF frequency as the data for it. You should see small groupings of similar frequencies within each cell, just like the corresponding airflows would.

It doesn't really matter which airmass model you start with. They are equivalent. That's what all of the 'three airmass models' writeup was all about. It combines WB data and fuel usage estimation to produce an airmass that you can map on either MAF or VE scales. I've done all kinds of transformation like this, MAF->VE, VE->MAF, fuel->both VE and MAF, wrong fuel mappings to right fuel mappings... basically, the method works.

Let me be clear..My approach eliminates many time-consuming steps that are laborious and unnecessary. No SD tuning, and no MAF Calibration using wideband AFR values.

You are using the MAF Airflow to calculate the VE Table. The only use of your wideband is to properly log that your are remaining at stoich AFR in non-PE mode, and to accurately maintain an accurate AFR at WOT (in PE Mode). You are using your LTFT values vs MAF Frequency to address discrepancies in fueling (Airflow).

[5.7ute]

Shawn, if your method can demonstrate fuelling accuracy when running either off the maf or in SD mode it is obviously working. When you get the time it would be good to see a couple of comparison logs to see how well your system works.
Personally I would use STFT only so any correction isnt carried over when entering PE. But not everyone would upgrade to a custom OS to get this function.

[Aloicious]

Yea, I am drastically limited by altitude! I can only hit ~ 82-84 kPa on a good day.

Great read, thanks! My baseline barrometric pressure around here is ~85-86kpa, on a very rare day I could hit 90 for maybe 1-2 cell counts. now that I have the blower I can break through that barrier, but I saw a significant drop in power when I moved from ~500 ft to ~4500 ft.

[WeathermanShawn]

Shawn, if your method can demonstrate fueling accuracy when running either off the maf or in SD mode it is obviously working. When you get the time it would be good to see a couple of comparison logs to see how well your system works.
Personally I would use STFT only so any correction isnt carried over when entering PE. But not everyone would upgrade to a custom OS to get this function.

Thanks Mick:

You have an excellent point about utilizing STFT's in lieu of LTFT's.

I have done logs utilizing both SD and MAF runs. I say virtually no difference. In SD mode, I might have gained ~ a +2 MAP max, vs MAF..and interestedly when I tried a SD closed-loop tune..it was easier to manage the LTrims vs the MAF-closed-loop. But, acceleration-wise and fueling were nearly identical.You simply make a run..log your LTFT's vs MAF Frequency..then cut and paste the LTFT % correction vs MAF Frequency. That gives you a nearly perfect MAF Calibration Table. You then do another log and utilize the EFILive CALC.VE pid and using the EFILive MAP function, you apply the data to a RPM vs MAP Table. You then cut and paste that directly to your VE Table.

Your VE Airflow and MAF Airflow then match perfectly. You then log another run..log your AFR's at Stoich and WOT..and it all works.

The bottom line is that all your Airflow and fueling is nearly perfect.

[mr.prick]

I'm trying to figure out how you are adding LTFTs to the MAF.
You can add them as percentage but paste & add will add them as whole numbers.
I made a calc_pid for paste & multiply.
Are you just adding them by hand with the Adjust: box?

[redhardsupra]

heh, good question: how do you know what units are the trims in? are they percents? are they grams/sec of airflow? are they ms of pulsewidth?

as for the rest: i totally disagree. you cant have ' a simple version for beginners' and then some other set of routines for more advanced users. Nature does not alter its behaviour based on the audience. the hacks at the tuningschool tried that approach, PE hacks for beginners, MAF jacking for the rest sort of approach, and i ripped them a new one for that. their answer was 'well, but it still makes us money so we're right' 'nuff said.

[WeathermanShawn]

heh, good question: how do you know what units are the trims in? are they percents? are they grams/sec of airflow? are they ms of pulsewidth?

as for the rest: i totally disagree. you cant have ' a simple version for beginners' and then some other set of routines for more advanced users. Nature does not alter its behaviour based on the audience. the hacks at the tuningschool tried that approach, PE hacks for beginners, MAF jacking for the rest sort of approach, and i ripped them a new one for that. their answer was 'well, but it still makes us money so we're right' 'nuff said.

Marcin, the LTrims are in percent, but the MAF Frequency is being logged with g/s as its units.

As far as the other comments..I have a hard time understanding your combative style. You are very quick to criticize everything.
I have yet to see you put into plain words a Tuning Tutorial that works. You are knee-deep in theory, but never step up with a plan.

I am offended when you throw out words like 'hack' and so quickly dismiss ideas that you have never really stepped up to publish.Why don't you step up and help, instead of being the perpetual 'house' critic and being continuously offensive in your language and tone.

Give us your technique, and put it on this forum. It takes courage. Lets see you do it..

[mr.prick]

I gotcha. ;)
Excel is useful but I just make calc_pids for everything even offsets and filters.
For me that's easier.

[joecar]

I'm still catching up on the reading and digesting and checking the units (after some leaky roof repairs... we're getting the whole years worth of rain in 4 days here in So Cal... :doh2:).

Any place/time you use the MAF to correct something means you have reason to believe that the MAF table is already calibrated... this may or may not be a valid assumption... oh, I see, you're using LTFT's to correct thwe MAF table... (my roof is still distracting me...:doh2:)

Anything that saves time-consuming steps is good...:cheers:...we all don't have lots of time on our hands.

If you see actual EQR matching commanded EQR then the method has validity... that can't be refuted.

No, this is good reading, it makes me go back over Marcin's papers.

Please do continue... :cheers:

BTW: I like the good intelligent discussion... on other forums this would have degenerated into a closed-minded pissing match about MAF's or something. Thanks to all.

[joecar]

Shawn,

Marcin is not being hostile... he is being devil's advocate, he brings up things to make you rethink and possibly from another angle...

:)

[joecar]

...

You simply make a run..log your LTFT's vs MAF Frequency..then cut and paste the LTFT % correction vs MAF Frequency. That gives you a nearly perfect MAF Calibration Table. You then do another log and utilize the EFILive CALC.VE pid and using the EFILive MAP function, you apply the data to a RPM vs MAP Table. You then cut and paste that directly to your VE Table.

Your VE Airflow and MAF Airflow then match perfectly. You then log another run..log your AFR's at Stoich and WOT..and it all works.

...
That is it in a nutshell, very simple, can be done in 2 runs with some thought out driving pattern...
one run to correct both MAF and VE tables, a second run to verify AFR's with wideband.

that is very simple and saves a lot of time, and uses a wideband only for verifying the result.

Edit: see red ink.

[WeathermanShawn]

I'm still catching up on the reading and digesting and checking the units (after some leaky roof repairs... we're getting the whole years worth of rain in 4 days here in So Cal... :doh2:).

Any place/time you use the MAF to correct something means you have reason to believe that the MAF table is already calibrated... this may or may not be a valid assumption.

Anything that saves time-consuming steps is good...:cheers:...we all don't have lots of time on our hands.

No, this is good reading, it makes me go back over Marcin's papers.

Please do continue... :cheers:

BTW: I like the good intelligent discussion... on other forums this would have degenerated into a closed-minded pissing match about MAF's or something. Thanks to all.

Thanks Joecar.

Any place/time you use the MAF to correct something means you have reason to believe that the MAF table is already calibrated... this may or may not be a valid assumption.

My method is to use the narrowband O2's and LTFT's to 'calibrate the MAF. If after logging a LTFT MAF Calibration and simultaneously logging your wideband..say you come up with an average of 14.63 AFR's for all non-PE Modes, and you have an accurate Commanded Fuel for your AFR's. Why would that not be an accurate method? Both MAF and VE Table airflows match, and all you RPM/MAP's show perfect stoich values during non-PE modes..and WOT AFR's are perfect.

The end result appears to valid. And the Airflow models are virtually identical.

[joecar]

I use the old meaning of the word "hack" where it means that someone who knows there stuff inside-out can make a simpler code edit to make it work properly... :D

Ok, the method of calculate-IFR, correct-VE, correct-MAF eliminates several assumptions and is a more-scientific approach... a wideband is required... and this approach is very time consuming.

The LTFT-correct-MAF and calculate-VE approach is very quick/simple and doesn't require a wideband other than to see the results (did me comprehension skills support me correctly...? :))... even tho this is simple/quick, this might not necessarily be for beginners since the user has to understand some of the interactions going on.

[WeathermanShawn]

Shawn,

Marcin is not being hostile... he is being devil's advocate, he brings up things to make you rethink and possibly from another angle...

:)

I think Marcin just needs to take the plunge and publish his own Tuning Tutorial.

[joecar]

...

My method (shortcut) is to use the narrowband O2's and LTFT's to 'calibrate the MAF. Maybe my question would be thiis. If after logging a LTFT MAF Calibration and simultaneously logging your wideband..say you come up with an average of 14.63 AFR's for all non-PE Modes, and you have an accurate Commanded Fuel for your AFR's.

Why would that not be an accurate method? Both MAF and VE Table airflows match, and all you RPM/MAP's show perfect stoich values during non-PE modes..and WOT AFR's are perfect.
...
If the wideband shows actual EQR matching commanded EQR (i.e. BEN is at 1.00) then like 5.7ute said this is valid...

the test is then to see what the BEN's are for the boundary cases.

[WeathermanShawn]

If the wideband shows actual EQR matching commanded EQR (i.e. BEN is at 1.00) then like 5.7ute said this is valid...

the test is then to see what the BEN's are for the boundary cases.

Granted..some of the lower Idle Rpm's and MAPs < 25 kPa do not always meet Commanded AFR's. I have had to lower some of my MAF produced VE Table for Idle (~10-15% less fuel), and reduce the Airflow for the 15-25 kPa for the 1200-1600 Rpm's (~10-15%).

[redhardsupra]

Shawn, you're confusing 'combative' with 'scrutiny.' If you say something wrong, I will point it out. Besides, I wasn't calling you a hack, but the tuningschool guys. So unless you're related to them, I don't think your outrage is applicable. I'm not the only guy that tries to approach life with logic and science, I just found this and it made me think of you: http://scienceblogs.com/dotphysics/2010/01/flying_r2-d2_you_are_doing_it.php

If all you want to do is remap MAF's airflow numbers to SD axis and then calculate VE out of it, I've had that done in '06. Nothing new here. Also, it doesn't solve any other problems inherent to the BEN-based methods:
1. proper attribution--this is a big one, with the standard approach, you attribute ALL changes in airflow to ONE cause. If you're calibrating MAF this way, you end up with all the errors 'built into' the MAF calibration. If you do it on VE table, then the errors are all attributed to VE numbers. What if that's not it? What if it was the temperature? How about fuel delivery imprecisions? Sensor miscalibration? you cannot blame all errors on one arbitrary calibration, that's severly oversimplifying the problem. You must split all the pieces properly, account for pressure, temps, and then see how much error is left, and that's MAYBE something we could attribute to VE table.
2. Accounting for temps is hugely complicated in the GM scheme of things. I have it partially solved, and it's fantastically convoluted, and it takes some gnarly math to get anywhere proper solution.

so no, there is no easy step-by-step solution. that's why i didnt make one. not because i'm lazy, not because i dont like to write, it's because i think it would be spreading misinformation, and i refuse to be responsible for that.

[WeathermanShawn]

Marcin, all good points, but you need to back it up with data.

The issue presented on this forum was that beginners lack any viable Tutorials on how to tune. If you leave customers frustrated and unhappy..word of mouth spreads and people will hesitate to pay big bucks to buy tuning software.

I think you are missing my conclusion. This method of Mapping the VE Table has virtually perfect stoich AFR values in non-PE Modes and perfect WOT AFR's. You are simply utilizing a closed-loop system and applying LTFT corrections to help in perfecting the model.

I am just skipping the entire AUTOVE BEN application and secondary MAF Calibration that uses the current AFR and BEN method. Again, Marcin..if this is nothing new, and you published it in 2006..you need to help us out and publish a Tuning Tutorial. You need to have an open-mind here. I thought that was the goal of tuning?

[tinindian]

Shawn - Let me start by saying I am not even a beginning tuner yet, but your theory sounds really exciting. I just recently bought an '02 Z28 and EFILive, and have an LC-1 on the way. I'm doing my best to take the advice I see here and on other forums - read, read, read - before I start making changes. I have a book on the way and I read here & LS1Tech daily. I initially liked the AutoVE idea after reading the tutorial until I came across some posts that talk about stalling and other issues. I'm not sure I'm your 'target' tuner at this point by I'd love to see how this plays out. Obviously some of this is way over my head but it appears you are trying to simplify the process. Kudos and keep the wheels turning.

[mr.prick]

I understand the "waste your time" argument but it would make it easier to understand the method and end result for some of us.;)

I don't see why one can't be modeled from the other,
as long as the first one's done right. :angel_innocent:
IMO
As long as LTFTs are "good" and BENs are close to 1.00 @ WOT
who care what anyone thinks.
Your VE is not rocky and your off throttle AFR does not go overly rich so I'm inclined to believe you on to something.

[joecar]

tinindian (http://forum.efilive.com/member.php?u=9969), welcome to the forum...:cheers:

[redhardsupra]

Shawn,
1. you're assuming that MAF calibration is correct. I find that rarely to be true, whether you're using narrowbands, widebands, or ouija board. Fix the basics first, do not move forward until the fundamentals are satisfied.
2. whatever error you carried over from #1, now you're spreading to other tables.
3. The fact that you do some stuff, and then you use CL to cover up your results sounds awfully weak. Let's compare apples to apples. Do one tune, using whatever method you'd like. Create a metric for it, make it a good one, none of that AFR%Error average based weaksauce. Fix it up with your method. Use the same metric again. CL is to be used as a corrective measure, not the main driving force behind where do calibration comes from. The idea of a perfect tune is that no corrective mechanisms are needed. The rarer and smaller the corrections are, the better the underlying tune.

anyway...
if you find my writeups hard to understand, ask me a question, on my site, through email, through IM, on this forum, skype, whatever. you can accuse me of many things, but not willing to discuss tuning issues ain't one of them ;)

yes, you are correct, i am knee deep in theory. why? because without _correct_ underpinnings, you end up with the sort of horsepoop we have now: improper attribution, corrective mechanisms that never converge on stable solution, oversimplifying complex systems, disabling not understood functionality, etc.
I've developed enough theory so I know that the sort of calibration you're talking about is a formality. It's a linear regression from some scannable data. I've played with it, I tried to make it better by using robust fitting and other tricks, but ultimately it will not work, because the very fundamentals are plain wrong.

Why don't I publish some step-by-step instructions for it? Because it's incorrect.

'Incorrect' does not make a good 'second best' in absence of 'correct' solution.

[5.7ute]

Marcin. While I agree 100% in what you are saying, I believe you are missing Shawns point.
What he is attempting to do is design a method for the newbie tuner that will get him off & running with a minimum of fuss. Bad science aside it should result in a much better tune than the one that the factory with millions of dollars & thousands of man hours has produced.
As this person gains more knowledge, of which IMO your blog is required reading, they can then begin addressing the system one table at a time.(or more if necessary)
my 2c

[Wolfie]

Not that anyone cares, BUT I have only been "toying" with EFILive for 2 years now, but for over 200,000 miles... I am waiting on the results of WeathermanShawn. I like the way he is looking at it. I have tried the auto ve, but never actually got through it. I just ended up enabling lean cruise, running ol without cats and a base afr of 15 and some adjustments which keeps me in the 16/17:1 afr most of the time. I am/was only interested in mpg as I drive over 100,000 miles a year. So... You Go! Shawn...

[WeathermanShawn]

Mick, you hit the main point on the head! I appreciate it.:cheers:
Marcin, I think you need to accept that closed-loop under certain circumstances is of use. The idea is for beginners. People need clear and concise instructions to learn.

[5.7ute]

Shawn, Marcin does make some extremely valid points which could be added as a disclaimer in your method. This being that any inaccuracies in the fuel or temperature model will be carried over into these tables & that this is a work around & not a final solution to these issues.

[5.7ute]

Shawn, I dont think that my last post came out right. Those fuelling & temperature inaccuracies are there when most people are attempting to autove or automaf. The quickest work around is to get it close & use the trims to keep it there. Hence the "bad science" quips which you have recieved.
I personally still use semi closed loop from 2000rpm up where the cam doesnt mess with the o2 sensors. Why? because I cant get a good enough fit of the temperature model due to heatsoak giving erronous data. Our temperatures here can vary by over 30 degC in a day, so what works on a cold morning with corrections, can be out in the afternoon when it heats up.
Don't for a minute think that I am against your methods, I believe they have merit in many applications. Especially for the newbie tuner. BUT, & this is the main issue. Anytime airflow is calculated from o2 sensor readings, no matter if a wideband or narrowband sensor is used, any inaccuracies within the fuel or temperature model will be carried over to the airmass estimation tables. Maf or mafless. This is one of the reasons why I have spent so much time on injector characteristics. Get these right & any method will fall into line much faster.
Keep going, there will be a lot of use for your methods.

[WeathermanShawn]

Mick, I understand what you are saying..The MAF (LTFT) calibrated airflow, almost perfectly matches the SD (via wideband) airflow? When I log each of the appropriate DMA Airflow Pids..they line up very accurately. And my assertion is that if you are maintaining stoich during non-PE throttle conditions, and your WOT matches your Commanded AFR. In an auto primarily utilizing a MAF and in closed-loop..one can construct a highly accurate VE Table by using the EFILive VE.CALC. Pid.

Bottom line..you do not have to do an AUTOVE, followed by a MAF vs AFR Calibration..if you run a MAF closed-loop tune. It is primarily a method for beginners. As beginners advance, they can delve into some of the other methods to perfect their tune.

[joecar]

I say let everyone who is interested try it out for themselves, and then report back.

[joecar]

...
Don't you guys use Closed-Loop? Does anybody use a MAF on this forum? Perhaps I am the lone user of EFILive that uses this method.
...Shawn,

You're not wasting your time, don't be discouraged...

When Tycho Brahe and Johannes Kepler were trying to discover the mathematical equation(s)/model(s) of elliptical/orbital motion, they did not come up with the correct model until they spent many iterations of comparing each model with observed data... when a model disagreed they refined it or rewrote it and tried again...

Brahe maintained huge amounts of observed data but was never able to find the right model... Kepler did eventually find the right model using Brahe's detailed data (Kepler's Laws)... meanwhile in the background the authorities were enforcing the firmly established belief that the Earth was the center of the solar system (no equations provided)... :doh2:

[voda1]

I say let everyone who is interested try it out for themselves, and then report back.
I agree. Sounds like a practical/efficient way to tune. Looking forward to trying your method come spring.

[tinindian]

Shawn - Whatever you come up with - I'm all in. Thanks for taking the time to help guys like me.

Mark

[tinindian]

Thanks Man. Unfortunately I live in Iowa so my car is tucked away for the winter. But I'm certainly looking forward to reading your material and tuning with it in a couple months.

[TunasTwins]

Thank you for taking the time to put this together. I believe your system accomplishes what you set it out for: to get new tuners headed in the RIGHT direction. Often, the initial gratification of tuning is stretched out over several years. Yeah there may be some inaccuracies in the process but the final output (real world) WORKS. Your method isnt scaling the crap out of just the MAF or the injector constant to hit the correct PE AFR. And for Marcin, thank you! We always have to challenge new theories (or old ones). Thats what science is! BOTTOM LINE: Lets try this out for ourselves and see if we like the results, then report back. Thanks again.

[mr.prick]

Shawn,
One note you might want to add is to change the display of {B0101} to % Of Theoretical Maximum.

[redhardsupra]

This post is riddled with inaccuracies, so let me address each point separately.

Well, I think the same temperature biases exist when you are doing an AUTOVE Tune. If your ECT and IAT fluctuate during your tune..you will be off. Try it over several days. The BEN(s) are different, especially as your IAT varies.

MAF is bias-free. Since MAF measures the final result (the airflow) and not its components (pressure, volume, temp), there is no problem with temp estimation or mesurement.


There is probably a mathematical way to take a log run and standardize the values to a 'standard' temperature.
yes, that's what solving for absolute values of GMVE (as opposed to all the prevalent 'adjustment' methods) that I've been talking about for the past 2yrs is all about. Proper attribution is NOT an option, it is the very base of science.


I think where the point is being missed..closed-loop 'solves' those IAT and air density differences. They Trim accordingly. I have taken a nearly perfect SD and MAF open-loop tunes from 5500-1200 feet. Neither one gave any where nearly perfect fueling . It was only when I re-enabled closed-loop that the car performed perfectly.

I guess closed-loop thinking is just not welcomed or accepted on this forum. Probably the majority have aggressive camming, or have FI or Turbo applications.
CL for tuning is not favoured anymore. If you look back to 2005, very few people had widebands, so they did the best they could with stockers. The first time I tuned my car, was with narrowbands on the street. It worked fairly well. I then rented a dyno and I improved another 6hp. So both methods can result in similar results, however, the street/CL tune took me 5 months, as opposed to the dyno which took me 3 hrs.
OL is much better for observing YOUR changes, not changes coming from all the modifiers (whether they're fuel cutoffs, traction control, cat protection, spark, fuel trims, idle air trims, etc...) this is again proper attribution: you want to know if what you changed had a desired effect, or was it just a result of coincidence or changing conditions. You cant do that in CL by the very definition of CL. I have another name for tuning with CL: letting the ECU doing its job.

Only now do I appreciate the difficulties involved in introducing a method that is not widely accepted. See, I think the really smart people on this forum either run SD or Custom OS's. But, in my area the terrain and weather conditions change rapidly. I prefer closed-loop, because it Trims perfectly as IAT and air density changes. But, it seems to be an a tuning method that lacks respect on this forum.
Of course such a tuning method does not command respect--you claim that you're improving the tune, while all you've done it let the ECU do its job by trimming. What is YOUR contribution? Where is the novelty?


Nothing personal fellow members, but I am leaning toward backing off on this project. Anybody that wants to run closed-loop knows how to do it. But, probably 40-50% of beginners have great difficulties in mapping a VE Table, doing the laborious MAF Calibration. Then if they prefer closed-loop, they find all the Trims are just as 'wacky' as before. I know, I spent 2 months on those first two steps, and then realized I was going in circles.

Mick, I think that all airflow models have temperature biases. I think the way around it is to log when IAT are steady, or filter out IAT's that vary during a log run.

All I was trying to share is that a MAF produced Airflow Model..using EFILive's CALC.VE Pid can easily be cut and pasted to your VE Table. If you apply your LTFT's correction to the MAF Calibration Table prior to the cut and paste..you will have a tune that gives perfectly stable stoich and Commanded WOT AFR's.
so your contribution is to take the MAF airflow and use it as the data source on the VE table, right?


I'm leaning toward just letting the Tutorials staying as they are. I have probably put out enough ideas in this thread to get people thinking. But, I am getting the idea that it is not being readily accepted.

People are always welcomed to view my tune, or PM me if they have questions. If closed-loop tuning is viewed as 'heresy', I certainly have other things to do with my time. Marcin and others have worked for years on this..and I have yet to see a published Tutorial that accomplishes anything. You can talk about theory for years. It takes courage to put your name and ideas into a real Tutorial.

Sorry for the 'rant'. Perhaps I am just a little exhausted right now.

Here is my proposal. If I am officially asked to put together a draft Tutorial, I will do it. Whether TAQuickness, Joecar, Mr. Prick, or yourself can then massage, polish, and decide if it is applicable to publish..I will still do it.

I guess I am still befuddled why there is so much push-back on this concept. Don't you guys use Closed-Loop? Does anybody use a MAF on this forum? Perhaps I am the lone user of EFILive that uses this method.

Guys and Gals..I just do want to waste my time on this project if there is no widespread applicability.

Not mad, just tired.

..WeathermanShawn..I am still failing to see any novelty or benefit to your method. It's not any shorter because you still have to drive and scan and cover all the cells. It should actually take longer, because instead of taking precise measurements (WB), you're using broad lead/rich conditions (NB).
Have you at least made a custom pid that generates the new VE table for you, backcalculating the VE values from the MAF airflow?

not mad, just tired,
Marcin

[WeathermanShawn]

Marcin, as a scientist I believe you guilty of the following..you have a 'selective' reading flaw. You are not actually 'listening' to the words I have written. You are making conclusions that in some cases I have not made.

On the issue of maintaining tight control of IAT's during a run. You are missing my point. If you are sampling the same RPM/MAP data point with multiple IAT samples in a single log, you are just simply increasing the deviation of the CALC.VE %'s. Same principle whether doing SD, MAF otherwise. Try a log at 0C and one at 30C on the same log. You will just be increasing your data spread.

The benefit is exclusively for MAF-based auto's running closed-loop. You can still operate your vehicle any way you want. But, for this method you are having to do only one log run in order to produce a VE Table and MAF Airflow that matches and is accurate when operated in closed-loop. My wideband verifies it is accurate.

Marcin, the bottom line is that you are always welcomed to publish your own method on this site.

[joecar]

I'm trying to figure out how you are adding LTFTs to the MAF.
You can add them as percentage but paste & add will add them as whole numbers.
I made a calc_pid for paste & multiply.
Are you just adding them by hand with the Adjust: box?Shoemike,

You might add your calc pids to this thread so people can have them handy...

Thanks. :)

[DrkPhx]

I guess I am still befuddled why there is so much push-back on this concept. Don't you guys use Closed-Loop? Does anybody use a MAF on this forum? Perhaps I am the lone user of EFILive that uses this method.

You shouldn't surprised or befuddled. Hardly anyone runs CL MAF anymore besides stock or near stock mods. Even the majority of pro tuners will encourage most to run OL SD.

BTW - I still run Closed Loop MAF on my 98 TA. It's a pretty aggressive LS2 402 with 11.7 CR, large cam, etc. It's an A4 car with a 4700-5000 converter that sees quite a bit of street driving. Driveability is amazingly good considering the setup and it idles real well considering the cam.

[WeathermanShawn]

You shouldn't surprised or befuddled. Hardly anyone runs CL MAF anymore besides stock or near stock mods. Even the majority of pro tuners will encourage most to run OL SD.

BTW - I still run Closed Loop MAF on my 98 TA. It's a pretty aggressive LS2 402 with 11.7 CR, large cam, etc. It's an A4 car with a 4700-5000 converter that sees quite a bit of street driving. Driveability is amazingly good considering the setup and it idles real well considering the cam.

In tuning I believe there is a need for OL-SD tuning for a lot of aggressive applications, but the perception that somehow CL-MAF or CL-SD can not be of value is not correct. I do understand the airmass arguments of each, but I think what is neglected in the discussion, is that a tune that utilizes a correct Trim function can be superior to an inaccurate Open-Loop tune..

I do agree Closed-Loop tuning may not be popular. But, I still would bet that over 50% of people who purchase tuning software utilize it.

[mr.prick]

Shoemike,

You might add your calc pids to this thread so people can have them handy...

Thanks. :)
calc_pids(LTFT).txt (http://forum.efilive.com/attachment.php?attachmentid=5899&d=1264815758)

[LinearX]

I do understand the airmass arguments of each, but I think what is neglected in the discussion..is that a tune that utilizes a Trim function that is well-managed is superior to an badly-managed Open-loop tune.[/B][/I]

No offense, but that's kind of like saying a boat with a hole in the hull is gonna sink.

I read your document, and I didn't see anything that clearly stated where the properly calibrated MAF curve came from. I assume it was the vague references to the AutoMAF. If that is the case, I would think a beginner's guide would handle hold as much as possible and assume as little as possible. As one who is new to EFI, I would think a beginner's guide would be more inclusive.

Having talked to Marcin quite a bit over that past year and a half or so, I get to hear lots about his theories on tuning and the things that may be lacking before we're able to properly attribute calibrations to the correct place.

Kudos for sticking your neck out and taking a chance to write a guide like this.

[joecar]

...
Kudos for sticking your neck out and taking a chance to write a guide like this.++1.

[WeathermanShawn]

No offense, but that's kind of like saying a boat with a hole in the hull is gonna sink.

I read your document, and I didn't see anything that clearly stated where the properly calibrated MAF curve came from. I assume it was the vague references to the AutoMAF. If that is the case, I would think a beginner's guide would handle hold as much as possible and assume as little as possible. As one who is new to EFI, I would think a beginner's guide would be more inclusive.

Having talked to Marcin quite a bit over that past year and a half or so, I get to hear lots about his theories on tuning and the things that may be lacking before we're able to properly attribute calibrations to the correct place.

Kudos for sticking your neck out and taking a chance to write a guide like this.

Thanks LinearX and Joecar:

LinearX, you make an excellent point about the crux of the MAF Calibration Curve and where it comes from. The MAF is not necessarily superior (or inferior) to other methods of tuning. There are flaws in its design and I have seen MAF Frequencies that scatter at various RPM's and MAP's. Overall that is why I have at least said that a system than can successfully Trim is of value. Where closed-loop suffers the most is at low RPM, low MAP, and some Idle conditions. The O2's are slow to switch and give as accurate of Trims in those areas.

I am using the LTFT's to 'calibrate' the MAF..and then use my wideband to verify that both non-PE and PE AFR's match. There is more work to follow.

[mr.prick]

Shawn,
don't be too concerned about writing a tutorial for the newbie.
I say take all the info you can find and use it to get your point across.
Wrong or right this idea is interesting to me.

[Wolfie]

WeathermanShawn...

I don't really have anything to add, but after reading this section with great interest... over and over... I have to say.... I run ol with maf... the only reason I use ol is because I have my base afr set at 15.4. Anyway... Some of these posts remind me of a time long ago.... Back in the mid to late 70's I was offered a job by the service manager at our local Dodge Dealership because I used to just hang out there talking to a couple mechanics and the manager as well. My auto background at this point was just self taught, but the manager must have seen something there.... There were some damn goon mechanics there, me included, that were mostly up until that point, self taught gearheads. Well, we had a couple people start working there that just graduated from one of those tech schools. And guess what...
They knew the theory better than anyone else! They could talk the talk!
But...
They were lousy mechanics.
See.... that's all they could do is talk.
(Sorry for the bit of rant, but I am following what you do and think the theorists should keep their distance and let you be on with it!)

[WeathermanShawn]

Wolfie:

With a subject like this is that there is not always an absolute right or wrong.

Thanks for your comments.

[Gordy M]

Shawn,

Like many who mainly read these discussions, I hope you do not get discouraged in your write up. When I started reading your initial posts, logs, etc I quickly became about three days behind in the discussions from understanding what everyone is talking about. However, many of those following this discussion are like me and want to get basic tuning down on a mostly stock engine.

One item I noted is most of those who are commenting are the more experienced tuners and they have all made excellent observations. But remember, you are writing for the beginner and I, for one appreciate it.

By the way, about 90% of the people who I meet who have had tuning done, both good and bad, are running MAF, CL, and 1/3 of them have bought their own tuning software. Everyday new enthusiasts are buying EFILive and they all have to start somewhere.

[WeathermanShawn]

Hey, Gordy you are just the type of reader and tuning enthusiasts that I figured was out there.

I appreciate your encouragement and comments.

[cme265]

let me know if you want some F.I. logs/tuning practices, always down for a different way of making things work...and i'm a fan of the MAF!!! up to a certain point (which is what i'm running now)

[WHYTRYZ06]

way too much info, but good info.... im in OLSD and i can tune it in less than a day....im happy where im at

[Steve Bryant]

WeathermanShaw,
I would be glad to be a proofreader/editor/sounding board if you want some help. I was one of the Beta Testers for EFILive five years ago and was pretty active back then. I have a lot of ideas about developing a straight-forward approach to tuning that I would be glad to share with you and have developed some draft documents on the basics along with some diagrams.

One question that I have is this. Are you simultaneously determining a correction for speed density and mass air flow based on the LTFT values required for stoichiometric? This appears to be the gist that I am getting from what you have stated.

This might work, but here is my concern. As I understand it, the PCM when in normal MAF/CL operation uses the VE table as an initial injector pulse width manipulator during dynamic RPM/MAP changes and then washes out the SD calculation in favor of the MAF determined fueling. Also, at and above a predetermined cut-over point that is determined by the value of {B0120}, the PCM looks exclusively at MAF frequency only with standard GM operating systems.

So . . . if this assumption is true, you have to adjust one variable first, namely VE while in speed density only. Then the MAF can be adjusted to maintain stoic. I think that you may be trying to adjust two variables simultaneously.

If I am wrong that the PCM initially considers SD then tapers quickly to favor MAF and trim short and long term simultaneously for miscellaneous variables, then maybe one can tune both variables simultaneously.

All my best,

Steve

[WeathermanShawn]

let me know if you want some F.I. logs/tuning practices, always down for a different way of making things work...and i'm a fan of the MAF!!! up to a certain point (which is what i'm running now)

CME..Thanks for the offer. What would be interesting is a F.I. log up I-70W in the mountains (during summer). I would be curious to see if you logged BARO and how often it actually updates, and how that might affect density/fueling requirements.


way too much info, but good info.... im in OLSD and i can tune it in less than a day....im happy where im at

I think once you know tuning, it is easy to tune in a day. The trick is can you teach beginners in one day. Like I said OLSD has many successful applications. Tuning on the street, where ECT/IAT and BARO is constantly changing (elevation) makes open-loop tuning more challenging. This concept is for those that prefer closed-loop, but I understand your point of view.

[WeathermanShawn]

WeathermanShaw,
I would be glad to be a proofreader/editor/sounding board if you want some help.

One question that I have is this. Are you simultaneously determining a correction for speed density and mass air flow based on the LTFT values required for stoichiometric?

So . . . if this assumption is true, you have to adjust one variable first, namely VE while in speed density only. Then the MAF can be adjusted to maintain stoic. I think that you may be trying to adjust two variables simultaneously.

If I am wrong that the PCM initially considers SD then tapers quickly to favor MAF and trim short and long term simultaneously for miscellaneous variables, then maybe one can tune both variables simultaneously.

All my best,

Steve

Steve:

I am taking a known MAF Airflow, a known LTFT value, and then utilizing the use of EFILive's CALC.VE Pid and simultaneously mapping a VE Table. I am simply taking a known GM.CYLAIR value and 'reversing' the process to determine GM.DYNCYLAIR.
In each case each both DYNCYLAIR and CYLAIR Airflow models match, and your non-PE and PE AFR's are on target.

Constructing a VE Table via AFR's and BEN's laborious and inaccurate at times. Do a SD run in the early morning (cool IAT's) then do a evening run (hot temperatures). Do a SD run run on even terrain, then one where elevation changes. You will have different BENS according to what air density you logged your AFR's at.

In closed-loop the Trim function responded quicker and with more consistency in maintaining stoich and accurate PE AFR's for my application. I am tuning each variable simultaneously. I am logging MAF (g/s), LTFT and calculating the VE values.

[redhardsupra]

let's not get personal preferences get advertised as the policy, you already have n00bs drooling, because of your promises.

[WeathermanShawn]

let's not get personal preferences get advertised as the policy, you already have n00bs drooling, because of your promises.

Lets not let closed-mindedness or insults dictate the conversation.

Personal preference was the polite way of saying..I know other people have other equally and compelling methods. I trust readers ability to choose whatever method they prefer. This thread is predicated on presenting choices. I trust people's intelligence and common sense to make their own choice(s).

I was trying to be polite, not arrogant.. :)

[ckJoshZ28]

Greetings to the O.P. and all, I do not post much as I remain on the lower half of the learning curve, with a lack of experience to boot, however I feel I must voice my appreciation for the discussion within this thread. If it remains at the end of a week, all that has amounted is an interesting theory that may work for some but not all, than it is just that, an interesting theory that may work for some. Topics such as this one reaffirm my infatuation with the science behind electronically controlled fuel injection, and interest in reading and supporting those involved.

Keep up the great work, you are all influencing and teaching more people than you could know.

-Josh
('newbie tuner', 'bolt-on 98z28', and 'continuously EFI live edited')

[WeathermanShawn]

Greetings to the O.P. and all, I do not post much as I remain on the lower half of the learning curve, with a lack of experience to boot, however I feel I must voice my appreciation for the discussion within this thread. If it remains at the end of a week, all that has amounted is an interesting theory that may work for some but not all, than it is just that, an interesting theory that may work for some. Topics such as this one reaffirm my infatuation with the science behind electronically controlled fuel injection, and interest in reading and supporting those involved.

Keep up the great work, you are all influencing and teaching more people than you could know.

-Josh
('newbie tuner', 'bolt-on 98z28', and 'continuously EFI live edited')

Thanks.

Never hesitate to post regardless of experience.

[cme265]

i tried playing with the BARO settings, no matter what i did always updated to 105kpa, didnt seem to affect fueling so i thought it was for diagnostic purposes (this is while using MAF), finally got my 2bar map sensor in but ran out of decent weather/gas money to put it into S.D. and COS5, gonna give it a try when the roads dont have so much gravel on them (garage queen car). up I70w in the summer....damn you're a glutton for punishment...lol air should be pretty crappy here then (9000+ D.A. in the city)

[TunasTwins]

Thanks again for so much effort in writing all this up! Here's a log I took with my stock to-the-air filter 2005 Tahoe 4.8L. Its wifey's truck for my twin boys (1 years old!). Can you take a look if the map is setup correct? I want to take a longer cruise tonight if I can slip away. I'm REALLY excited about your process. I'll have to take my LM1 from my WS6 this weekend.

[WeathermanShawn]

Thanks again for so much effort in writing all this up! Here's a log I took with my stock to-the-air filter 2005 Tahoe 4.8L. Its wifey's truck for my twin boys (1 years old!). Can you take a look if the map is setup correct? I want to take a longer cruise tonight if I can slip away. I'm REALLY excited about your process. I'll have to take my LM1 from my WS6 this weekend.

Yea, from what I can see you have everything set-up and done properly. Obviously some of the RPM/MAP boundaries will always be a little more of a challenge..very little MAF flow and if you start stalling, etc., you will get some erroneous readings.

Sometimes it is 'fun' to display your VE Table in g/s vs % of Theoretical Maximum. Then do a MAP with your MAF Flow (g/s) using the same RPM/MAP boundary. I say that because sometimes at very little MAF flow small differences can make a % difference a little misleading. But, you are doing everything right..

Let us know how it goes. I am hoping at least people can utilize the technique initially, then go more advanced if they so desire.

[Steve Bryant]

Shawn,
I really like what you have done to date and I plan to play around with this concept myself.

Good Job!

Steve

[WeathermanShawn]

Shawn,
I really like what you have done to date and I plan to play around with this concept myself.

Good Job!

Steve

Thanks Steve..I will be looking forward to some of your tuning notes when you get more time off!:grin:

[mr.prick]

Here is the calc_pids for average LTFT and LTFTBEN from both banks
You use LTFTBEN the same as BEN. (paste & multiply)
calc_pids.txt (http://forum.efilive.com/attachment.php?attachmentid=5899&d=1264815758)

[tinindian]

Shawn,

Great work. This update is easier to understand. Keep it up!

Thanks.

[WeathermanShawn]

Shawn,

Great work. This update is easier to understand. Keep it up!

Thanks.

Thanks..

[mr.prick]

There is a little software bug in using the CALC.VE PID (engine displacement does not save easily). I will address that separately (by PM). I have worked around it, but I will let you know if there is a fix.



You can make a calc_pid to mimic it in the mean time. :)

[mr.prick]

VEpcm = {SAE.MAF.gps}*({SAE.IAT.C}+273.15)/((displacement()*61.024)*{SAE.RPM}*{SAE.MAP.kPa})* 6155274.24

Try replacing displacement() with your displacement in CC
It should still work for stock CI :confused:

[WeathermanShawn]

VEpcm = {SAE.MAF.gps}*({SAE.IAT.C}+273.15)/((displacement()*61.024)*{SAE.RPM}*{SAE.MAP.kPa})* 6155274.24

Try replacing displacement() with your displacement in CC
It should still work for stock CI :confused:

Thanks for the CALC.LTFTBEN PID(s).

It worked!

[acomp917]

WeathermanShawn,

I am new to the LS1, although I know a few things about tuning.

How can you tune AFR with adaptive spark engaged? When the timing changes... the AFR changes. From what I understand, a tuner has to "IRON" out the tune one simple(unaffected) table at a time.

EDIT: I think it is simple to maintain a consistant "HOT" engine temp. No problem here.
Also, how do you tune without taking the ECT into consideration? Or, why wouldn't you apply ECT into the applied corrections? thus negating the need to maintain a consistent ECT.

Wouldn't it be IMMEDIATELY better to separate the IFR/MAP/MAF into separate variables, then balance them as isolated entities? I know this was set forward as "simple" and I am moving into the area of readhardsupra. I'm just trying to stop the "new" talent from taking on TOO many variables at one time.

S

[WeathermanShawn]

Hi Welcome:

It is true the Adaptive Spark will momentarily pull timing down in the event of KR. If you are in closed-loop you will still Trim to 14.63 AFR regardless (non-PE) mode. In PE Mode, your Commanded Fuel will stay the same. It makes no difference in Closed-Loop. If a different spark value allows you to run a certain RPM at a lower MAP, your MAF Frequency will also lower..

Use the Adaptive Spark to prevent knock, and adjust your Timing tables accordingly. Your tune should be free of knock. Everything Trims to the same AFR value regardless of Spark. Its possible if you were constantly activating Knock, perhaps your Trim distribution would be different. My experience so far has been most that Adaptive Spark recovers very quickly..

The ECT component is a very interesting question. Obviously, the VE Table utilizes 'Charge Temperature' in its calculations and blends ECT and IAT. The CALC.VE Pid, uses MAF, RPM, and IAT. Apparently a MAF does not need an ECT to operate. But, fundamentally it poses a challenge in matching dynamic and cylinder air. You could try a calculated pid that would add ECT, but you might have real problems applying it in a MAF-Enabled Closed-Loop tune.

[acomp917]

Shawn,

Obviously, You DO understand tuning of the LSX... I am used to tuning a completely unknown combination. I always liked limiting the MANY problems to the minimum.

I will keep ALL of this in(my minimal) mind :) when I start my tuning. I am really amazed how well the LSx PCM controls the engine.

You seem to realize as well as I do, that this is not as difficult as others make it. My biggest problem is the departure from basic engine requirements. I'm slowly trying to eliminate variables by splitting the controller logic into isolated variables. I'm almost there, I will then need to develop equations that will apply needed variables to known tables.

S

[joecar]

...
In Closed-Loop, your non-PE AFR is ~14.63. In PE Mode your Commanded Fuel is determined by the richer of B0101 or B5001.
...
...
You seem to realize as well as I do, that this is not as difficult as others make it. My biggest problem is the departure from basic engine requirements. I'm slowly trying to eliminate variables by splitting the controller logic into isolated variables. I'm almost there, I will then need to develop equations that will apply needed variables to known tables.
You have to separate commanded AFR and airmass since they are determined independently of each other...

This is my understanding of how it works:

airmass is determined from either VE B0101 or MAF B5001 (regardless of OL, CL, SOL) as follows:
- above B0120: airmass is calculated from MAF exclusively;
- below B0120: airmass is calculated from VE (transient airflow/throttle) and/or MAF (steady state airflow/throttle);

fuelmass is calculated from airmass and commanded AFR;

commanded AFR is determined as follows:
- in CL: the AFR is stoich from B3601, trimmed to this by applying LTFT after the fuelmass calculation;
- in OL: from the richest of B3605, B3647(COS), B3618 (if PE has enabled), B3603 (if EPM has enabled), B3659 (if PPM has enabled); PE may be further modified by the PE modifier tables;
- in SOL: the AFR is the stoich cells in B3605 (in OL with B4206 enabled), or the stoich cells in B3647 (in OL), trimmed to this by applying STFT after the fuelmass calculation;

(Entering PE, EPM, PPM, COTP would mean exiting CL since the AFR would be significantly far from stoich.)


So you see that in PE mode the commanded AFR is determined by the richest AFR of B3605, B3647, B3618 (whichever of those is active), regardless of VE and MAF...
the measured AFR is influenced by the commanded AFR and VE and/or MAF.


Continuing on...

injector pulse width is calculated from fuelmass and IFR B4001, and is further modified by the other injector tables;

if VE and MAF are correct, regardless of the IFR and other injector tables, the measured AFR will equal the commanded AFR during steady commanded AFR (steady commanded AFR has nothing to do with steady/transient throttle/airflow);

for either VE or MAF, if the IFR and other injector tables are also correct, the measured AFR will also track the commanded AFR during transitions in commanded AFR [altho this is also influenced by the fuel dynamics (port wall wetting) tables];

I hope this helps...:)... I can see questions coming... :help2:

.

[acomp917]

Joe,

Most excellent! I like information like that... to the point. I have been reading for more than 3 weeks about all of this. I am new to EFI live.

If you don't mind, I would like to add your post to the intermediate area of my future wiki.

Thanks,
S

[joecar]

Thanks to both of you for reading that... :)

I have always gotten lost in long winded texts that waffle on, takes too much time and clouds/obscures the important points...

short/pointy have always been my favourite, as long as sufficient info is included (unlike most powerpoint presentations).

Yes, copy/paste as you require.

[acomp917]

Joe or anyone that can answer,

Could you tell me what these acronyms mean in GM EFI?

EPM, PPM, COTP

I made it over a couple hurdles in the last few hours and thought I'd take the easy path and bother someone else.

S

[ScarabEpic22]

PPM is probably pulses per mile (trans related most likely) and COTP is Catalytic Over-Temp Protection (causes a very rich condition, like 11.7:1 when active).

No idea on EPM though, Electronic Protection Module maybe?

[WeathermanShawn]

Latest Update..

..WeathermanShawn..

[Steve Bryant]

Shawn,
You've done a really good job with this tutorial. Few people can imagine just how much hard work and research goes into something like this. However, you will have learned a great deal in the end too.

I can't comment as to its accuracy, but I'm willing to try it for myself. Thanks so much for all your efforts!
:cheers:
Steve

[WeathermanShawn]

Thanks Steve..

Accuracy-wise, I think some of the lower RPM/MAP areas (low MAF Flow) tend to be less accurate. WOT, PE with MAF can have some scatter also. I have learned tuning is still a rather complicated procedure. To some extent you can simplify..but the complexity is an inherent part of tuning.

[acomp917]

Shawn,

Good job on the pub. :cheers:

OK!, at $20 an hour and 100 hours.............. are you willing to work for less? :)

I'm going to use your system for my very first attempt at tuning. I've had a productive day and will be tuning the .tun file as soon as I get a stable 01 or 02 tune to run on my 2000.

Thanks,
S

[LinearX]

Perhaps I have missed something along the way, so bear with me.

If this is being billed as a way for beginners to start down the tuning path, and you're assuming the engine has been modified to some degree, how can avoid doing a MAF calibration if you're going to be using it as your basis for calculating VE?

[WeathermanShawn]

No, it is my own personal tuning notes. Having started tuning about 1 1/2 years ago, I felt that tuning the VE Table (SD), the MAF (AFR), then Trims was a big chase if you were going back to MAF Closed-Loop. It is a technique of constructing a VE Table where dynamic and cylinder airflow match (MAF +/- LTFT's). The MAF Calibration is appling LTFT's to maintain stoich in non-PE mode, and have commanded AFR match your wideband AFR both at stoich and WOT/PE.

The technique allows VE, MAF, and Trims to be simultaneously tuned. It is accurate and does work. It is best to try whatever tuning method you like..log..and share. Every 2-3 months I review my logs and tune and if something does not work the way I want it..I change it.

[acomp917]

Shawn,

I appreciate your efforts and plan to use your system approach as my first effort to tune with EFI LIVE. I like the method of using a complete "system" in an effort to simplify as apposed to hashing separate efforts. It is worth a try.

I would now like to see if you understand the difference between SD and MAF.

SD- (BASICS) The system knows through air density parameters(map) what the air density is(a few advanced parameters- IAT, (sometimes manifold and combustion temp). The system must know the displacement of pump(per revolution). The system must know the RPMspeed. Basically the system calculates: how many breaths(rpm), how big they are(displacement), and how much oxygen is in each breath(map). This system is good for transition. I takes into consideration how much air is actually entering the engine (even a good amount of manifold emptying and stacking(during transition).

MAF- (BASICS) This system simply measures the amount of air entering the engine by calculating the amount of current it takes to maintain a given temperature in a heating element. The colder the air(at a given volume)... the more current, thus must be more air. The more air(at a given temp)... the more current, thus must be more air. Any combination of the above is still relevant. I just chose to maintain one constant in order to simplify the explanation.

NOW, for a LITTLE of the tricky stuff. (WITHOUT O2Sensors) The SD system air flow (calc) is solely dependent on the VE table in order to know how much air is actually filling the cylinder(because of cam dynamics and other influences) at a given RPM and MAP reading. Thus, without an accurate VE table the PCM CANNOT know what fuel mass to apply(without O2 feedback and AFR table(or equivalent)). That is why ANY change in engine dynamics require a SD system to be re-tuned.

A (properly calibrated) MAF system knows how much air is actually entering the engine. That is exactly it's purpose. (AGAIN) It's only drawback is that it does not understand instantaneous changes in (downstream) absolute pressure changes.

Final note, Take a look into alphaN systems(crude) and TauX (based on manifold wetting principles due to transitional pressure change(pressure of vaporization)). These are extreme ends of the types of system that are out there.

This is my understanding. Any criticism is welcome,
S

[acomp917]

Separate thought,

What does the GM system use for acceleration enrichment? I surely hope it is not an over rich VE then transition back to MAF. If that is the case, God help us. I know NO way to balance(tune) a transition/overfuel/transition back to required fuel situation. Without a rate of change table(easy to understand)ie. TPS/MAP(Tau, best).

Transition being from one table to another one.

Please, someone tell me there is an acceleration enrichment in there somewhere!!!


S

[WeathermanShawn]

Acomp917:

Thats a good description of the SD/MAF hybrid system.

When logging I like to always log both GM.CYLAIR.DMA (MAF) and GM.DYNCYLAIR.DMA (Speed density) Airflow in units of g/cyl. After your log you can alway lay them out on a Map using RPM/MAP as axis. 99% of the time, both are within ~5% of each other (on my tune).

It is good practice to participate in the actual logging process. It really is a good learning process. There are a few members on this board that log daily, and some that utilize CLSD quite successfully. It is a good way to apply theory into practical solutions.

[acomp917]

Shawn,

That info about logging both measured and theoretical air flow is good for me. I will use it.

The explanation of SD/MAF was not meant to represent a hybrid system. It was mean to show both methods of calculating air mass. Along with fuel mass calculations(with/without feedback(O2)) They will each operate independently and each will control an engine well. Many aftermarket systems use one or the other(mostly SD).

I will be posting the actual tuning methods... when I get there. I full flashed a 2002 tune into my 2000 silverado and now the battery (alternator) picture flashes on the dash lcd display. I'm not the first to have this problem. The original thread just stops... no conclusion. I wish people would understand the forum is about helping others and without conclusion, others are not helped.

I will try to repay the help I receive when I have the ability.

S

[WeathermanShawn]

Joecar has brought up an interesting point concerning B0120 RPM Threshold for Airflow Calculation and its role in the resulting LTFT correction(s). He has suggested that B0120 be set to 400 Rpms to insure that only the MAF airflow values are being applied. In the tune I am running, both MAF and VE Table Airflows are identical..so that issue would not have been as readily apparent.

Thanks Joecar that is good feedback. I will do some more testing.

[5.7ute]

Separate thought,

What does the GM system use for acceleration enrichment? I surely hope it is not an over rich VE then transition back to MAF. If that is the case, God help us. I know NO way to balance(tune) a transition/overfuel/transition back to required fuel situation. Without a rate of change table(easy to understand)ie. TPS/MAP(Tau, best).

Transition being from one table to another one.

Please, someone tell me there is an acceleration enrichment in there somewhere!!!


S
There is an acceleration enrichment algorithim which is apparently disabled if the maf is failed. Obviously wont be a problem here with Shawns method, but it could if you go to full time speed density.
We do have access to some of the transient fuelling tables which will enable you to tune the wall wetting model (tau). If they are not available for your OS post a thread in the cax file section & one of us working on these should be able to set one up for you.

[Steve Bryant]

Shawn,
I think that Joecar has a point here. I haven't wanted to rain on your parade, because you may really be on to to something and I could be wrong.

Here's what I think may be going on. As long as the MAF is fairly close to being calibrated and as long as the VE table is fairly close, it won't take much short or long term fuel trim to keep things at stoic. Further, if PE is set up right that will be fine too.

The PCM primarily is biased to reference the MAF (unless it is disabled). Even though you haven't done anything yet to exclude speed density/VE (like setting {B0120} to a very low value like 400 RPMs); you've calibrated your MAF to stoic using the LTFT corrections to alter the fueling equation values represented by the MAF table in {B5001}. Since the car mostly is running on your accurized MAF, it should run well unless the VE is really out of whack and even then only during transients like acceleration/deceleration.

This is what I think is happening . . . but I could be wrong. Whether I'm right or wrong, you've made me rethink a lot of things and I'm glad. I haven't fooled around with tuning much for at least four years. Now, I'm ready to come back, get rid of the rust on my brain and learn a lot more. I had really become saturated and I had way too much else going on in my life. Your thread and tutorial have helped inspire me to get more involved and I thank you for that.

All my best,

Steve

[redhardsupra]

http://www.smokinvette.com/corvetteforum/showthread.php?p=392020#post392020

Shawn, this sounds like the handholding/spoonfeeding you're after.

[WeathermanShawn]

The PCM primarily is biased to reference the MAF (unless it is disabled).

Steve

Steve, I think Joecar is absolutely correct about B0120 and its influence on LTFT's and ultimately how it affects airflow calculations. And I totally agree with your point. Here is ultimately the question. How much does the MAF control airflow calculations (and LTFT's) when it is not disabled? Its hard to get a quantified answer. Does it just look for a correction factor (VE) and if it is an acceptable limit, ignore it?

What is interesting is that the stock VE Tables are incredibly 'rich'. If your MAF fails (and they do), those values of airflow equate to a lot of additional fueling. And you are right, Trims may be totally capable of handling even a 'richer (higher airflow values) VE Table. Here is what we probably do agree on. The CALC.VE method does allow a MAF-enabled Closed-Loop tune to covert cylinder airflow into its dynamic airflow equivalent. So, they are identical. Now, here is the ultimate question. Do you want them identical? Is is better to have a 'richer' VE Table for transient fueling or MAF failure?


http://www.smokinvette.com/corvetteforum/showthread.php?p=392020#post392020

Shawn, this sounds like the handholding/spoonfeeding you're after.

Actually that sounds like a good idea. Have you taken it?

It might help you to learn how to teach others the GMVE method of tuning..:grin:..

[WeathermanShawn]

I hope to have the final version of this 'Tutorial' finished no later than February 15, 2010. The goal is to a tuner who is utilizing the MAF and staying Closed-Loop to properly and accurately construct a VE Table, MAF Calibration, and Trim simultaneously. Most can be accomplished on one tune run.

There may be a few minor additions. B0120 (RPM Threshold for Airflow Calculation) may be initially changed to 400 RPM's. B0120 has absolutely no influence on the actual CALC.VE values. That value is calculated totally from MAF, IAT, and RPM and is not dependent on B0120. The modification however may prevent any inadvertent stock VE values from influencing the initial LTFT correction, which is used in later steps.

Lastly, 5.7ute submitted an excellent suggestion for a new Calculated PID: CALC.NEW_VE={CALC.VE (http://calc.ve/)}*{CALC.LTFTBEN} which can then be pasted directly into the B0101 VE Table. That will save even another step. Separately 5.7ute has also graciously volunteered to evaluate my logs and tunes using several different parameters. Hopefully with time we can work a more refined CALC.VE formula that includes an ECT value.

If anybody sees anything major, please PM me or post constructively.

[redhardsupra]

The normal operation is MAF/SD hybrid. It seems like you're tuning only the MAF table. If you go back to the standard operation, MAF and SD airflow values are compared to each other for a 'sanity check.' If they don't agree (and they won't, since you're ignoring SD component), the ECU will probably fall back on it's 'backup' mode, which is SD. Which you did not tune. So as a results of your t00nin' you will end up running in a mode that haven't been touched.

Do you still think it's a good idea?


PS. here's an interesting observation about the MAF/SD collaboration:
http://www.hptuners.com/forum/showpost.php?p=204438&postcount=16

[WeathermanShawn]

The normal operation is MAF/SD hybrid. It seems like you're tuning only the MAF table. If you go back to the standard operation, MAF and SD airflow values are compared to each other for a 'sanity check.' If they don't agree (and they won't, since you're ignoring SD component), the ECU will probably fall back on it's 'backup' mode, which is SD. Which you did not tune. So as a results of your t00nin' you will end up running in a mode that haven't been touched.

Do you still think it's a good idea?

The CALC.VE formula is calculating airflow independently of the MAF/SD 'sanity check'. You can verify this by logging the CLYAIR.DMA and DYNCYLAIR.DMA. With B0120 at 400 RPM's, it will never fail into a SD backup mode. Your CALC.VE will be the same whether you choose 400 or 4000 RPM's for your B0120 Threshold.

The question of the LTFT correction and B0120 has been raised. But that has absolutely no influence on the CALC.VE airflow computation. The question is B0120 influence on LTFT's.

I will reiterate. The CALC.VE formula does not require a B0120 change. To run in Closed-Loop you simply need your LTFTBEN vs MAF Frequency to be 1.00 +/- 2%.

Whether you accomplish that with B0120 at 400 or 4000 RPM's is not that relevant. B0120 influence on the LTFT correction is the issue. Has not been with my tune, but I got mine down in two runs.

[joecar]

B0120 is set to 400 to restrict the source (airmass calculation) for LTFT-correction-to-MAF to be the MAF only (and not switching between MAF and VE).

[WeathermanShawn]

Sometimes it is quite difficult to know in a MAF-enabled car how much Trim function is coming from the VE Table and how much the MAF.

I did two log runs this morning. One with my regular VE Table, the other with a stock 2002 Camaro VE Table. I did reset the Trims prior to switching to the stock VE Table. I left B0120 at 4000 RPM's in each case.

By, the way I would never advised doing that. I could barely start the car (very rich). But, the CALC.VE % were virtually identical. CYLAIR.DMA and DYNCYLAIR.DMA were identical in run one, but very disproportionate in run two.

Trims were affected to some degree, but interestedly it still seemed like the MAF was doing the majority of the Trim function (except for idle). I did not make any MAF adjustments between runs. Is it possible that the VE Table makes an airflow correction fueling wise, but the actual LTFT function is controlled by the MAF?

[Mark300]

Hi Shawn,

Thank you for all you hard work and sharing you knowledge with us, as a private enthusiast and user of EFILive, I have really enjoyed reading and working through you concepts, with relative ease and success.

However I did pick up one problem, which I think I have resolved, but I thought I should check it with the forum to see if my thoughts are on the right path.

I set B0120 to 400rpm as the starting point, as I didn't want the VE table (was not calibrated and possibly out, since I have been fiddling from AUTO VE tutorial) influencing the MAF calibration. What I noticed though, was that you need to get the process done and then revert back to MAF 4000rpm as soon as possible. If I don't do this and drive around in traffic with MAF at 400RPM, the LTFL start to drift lean. I maybe incorrect in my assumption, but I felt this was due to, an increasing IAT and rapid throttle change (not entering PE, just normal pull off and gear change), with VE disable, the MAF had transient fuel problems causing lean, then rich every time I touched the throttle, because the MAF was delayed in picking up the sudden change. This caused the LTFT to compensate to lean. With out VE enabled, it seems to get worse as the day went on. Is this possible

Regards

Mark

[WeathermanShawn]

I am leaning toward leaving the RPM Threshold at 4000 RPM.

That is a good observation. I think it might involve the B4106 LTFT Update Filter. Perhaps the LTFT's are using a Closed-loop mode determined from just the cylinder air input when using MAF. In any case, I am finding similar results. Even running my stock VE, the most that Trims were effected were +/- 2-6%. Not as much as I would have thought, given the huge difference in dynamic vs cylinder air in my tune.

Try keeping B0120 at 4000, and let me know how it goes.

[RevGTO]

I'm not a noob, but I am dumb, so spoonfeeding - bring it on. I'm encouraged by the relative simplicity of your approach, Shawn. I've never managed to get around to doing AutoVE.

The proof of the pudding is in the eating. If at the end of the day your AFR's are as commanded and your LTFT's are in order, you've gotten your airflow tables pretty close to correct. Good work and I look forward to your finalized tutorial.

[WeathermanShawn]

I'm not a noob, but I am dumb, so spoonfeeding - bring it on. I'm encouraged by the relative simplicity of your approach, Shawn. I've never managed to get around to doing AutoVE.

The proof of the pudding is in the eating. If at the end of the day your AFR's are as commanded and your LTFT's are in order, you've gotten your airflow tables pretty close to correct. Good work and I look forward to your finalized tutorial.

:grin:..Thats a good one.

Agree. Sometimes even I am surprised that some experienced tuners will not accept your last point. This method is not changing the laws of physics or engineering. It is more the technique of 'simplicity' that some confuse with inferior. In reality you could take any type of tuning and with the right choice of Calculated Pids, eliminate some redundant steps and make it easier.

Sometimes simpler is smarter. Thanks for your comments.

[joecar]

...
If at the end of the day your afr's are as commanded and your ltft's are in order, you've gotten your airflow tables pretty close to correct. Good work and i look forward to your finalized tutorial.++1.

[TAQuickness]

...If at the end of the day your AFR's are as commanded and your LTFT's are in order, you've gotten your airflow tables pretty close to correct...

I disagree with this, here's why: WeathermanSean, WeathermanShaun, WeathermanShawn. There's only one right way to spell the man's [user]name, but if at the end of the day it sounds right, who cares?:doh2:

Shawn - Yes, my offer still stands, just send me a PM or email when you're ready. I think you're onto something good here.

While you may not find Marcin to be the most charming individual you ever met, he is right.

[WeathermanShawn]

I disagree with this, here's why: WeathermanSean, WeathermanShaun, WeathermanShawn. There's only one right way to spell the man's [user]name, but if at the end of the day it sounds right, who cares?:doh2:

Shawn - Yes, my offer still stands, just send me a PM or email when you're ready. I think you're onto something good here.

While you may not find Marcin to be the most charming individual you ever met, he is right.

Thanks TA:

I am used pretty used to my first name having multiple spellings.:grin: Thats O.K.

Where I could certainly use the help is in the procedural steps (select, cut, paste, etc) that you did so well in your Tutorials. Quite frankly to this day no one has done it better. And unfortunately the AUTOVE method for SD Tuning has been unfairly pitted at times vs this technique. I have tried to be clear that my application is specific to MAF Closed-Loop.

I will accept your offer and PM you the material in the next week. At this point I am spending more hours to get that last 5% right, so your offer is not only very gracious but appreciated.

On your last point..well, tuning is still somewhat of a 'team sport', so perhaps you guys can help those whose intellectual skills outweigh their people skills.:)

[TAQuickness]

I've heard all kinds of stuff about the AutoVE tutorial, good, bad, and ugly, none of it hurts my feelings.

I believe what RHS has been trying to say (Marcin correct me if I’m wrong), is that the tune is a system and must have accurate data throughout the calibration. The community as a whole focuses tuning effort on a select few tables, i.e. IFR, VE, and MAF, which completely ignores several pertinent factors in the tune. This in turn produces procedures and methods to tweak these three tables to compensate for bad calibration data, resulting in zero accurate data in a tune.

The argument, made by many towards Marcin, “if you know so much, why haven’t you produced anything?” is weak sauce.

[WeathermanShawn]

I totally understand and accept your point. Tuning involves a lot of 'moving targets', and you are right it must be considered as a system.

I still think there is a lot of wisdom in RevGTO's comment..

If at the end of the day your AFR's are as commanded and your LTFT's are in order, you've gotten your airflow tables pretty close to correct.

If we can get everyone to agree to that, we will call it a truce.:grin:

[joecar]

This is the nature of discussion, especially when the topic is a reverse-engineered system...


LOL, wouldn't it be great if GM released the inside info on the old PCM's (that will never happen... just slap me hard)..."so that's how/why it works"... :D

[acomp917]

Hello All,

I don't mean to reiterate the same thinking, although i have just gone through the report for a 12212156 and I must beg the differ. Assuming that you are not tuning a stock vehicle, you must:

Throw in a reasonable timing map.
Get rid of as many variables as possible. http://forum.efilive.com/showthread.php?t=13021
Make sure the torque limit and traction control are disabled.
Set all of the changed hardware parameters.
Get car to idle(somewhat).
Use WBO2 and some method of applying changes(I prefer filtered) to: VE/IFR/MAF

After getting things close, go to dyno(steady state if possible) and setup the timing table. Start all over with fine tuning the AFR.

What gets me about many of these posts is: They reflect government politics... "We know what were doing, don't ask for specifics, you would not understand them anyway".

I say, watch the WBO2, watch for knock, and don't pin it's ears back for too long until you can make sure the first 2 are OK. This is not a trip to the moon, it's just wasting gasoline. Like anything, the better you get, the less waste you will create.

My 02,
S

[5.7ute]

To this date I still have not seen any published material on the exact amount of airflow correction and resulting fueling adjustment when using the GM MAF/SD hybrid. You know it does it..but how much, and does anyone know the exact amount for every RPM and MAP.



Yep, but its top secret.:grin:
Seriously though Shawn, you have the tools at your fingertips to work this out.
Log {GM.DYNCYLAIR_DMA} & {GM.CYLAIR_DMA}. This will show you the airmass the PCM is seeing in both modes.
{GM.IBPWx},{GM.AFR}, {GM.INJFLOW},{GM.MANVAC}& {GM.VOLTS} + whatever conditions you want to log.RPM,MAP etc.
There is some tricky maths(for me anyway) but you can back calculate a fair bit from these pids. FI Airmass = (IBPWx-{B3701})*{GM.INJFLOW}*{GM.AFR}
If you want precision you need to make a calc pid for AFR,IFR,Airmass etc. This works quite well.
*CLC-00-001
G/cyl 0.0 2 0.6 "{GM.DYNCYLAIR}"

CALC.DYNCYLAIR F001 CLC-00-001 G/cyl Fuel "Calc Cylinder Airmass"
Do this for all the pids you need to get precision to 6 decimal places.
Any differences will soon become apparent & this process can be used for transient fuelling additions, offset calculations etc etc.

[redhardsupra]

I totally understand and accept your point. Tuning involves a lot of 'moving targets', and you are right it must be considered as a system.

I still think there is a lot of wisdom in RevGTO's comment..

If at the end of the day your AFR's are as commanded and your LTFT's are in order, you've gotten your airflow tables pretty close to correct.

If we can get everyone to agree to that, we will call it a truce.:grin:

no truce. In order to correctly assess the goodness of your AFR, you must start out by creating a metric that isn't averaging errors on both sides of the stoich. You do realize I hope that if you have a 1000 frames of -10% error and another 1000 frames of +10% error, your BEN will tell you it's perfect, right? Most errors tend to follow the Gaussian distribution, so averaging a large enough of a sample, will tend to result in a 0. That does not mean that your tune is anywhere near decent. Until you fix that, you're looking at meaningless results.

And as far as RevGTO's comments, you're doing it backwards. You can't justify the means with results, that's not how to you do science. You formulate a theory, you gather data, you see if the gathered data is inconclusive, proving, or disproving your theory. And the last part is a lot more involved than you think. Like I've mentioned in the previous paragraph, you must make sure your metrics make sense for the data you're working with. BEN is clearly wrong, so stop using it. Data analysis consists of not just looking at how well the data fits, but how are the errors distributed. If the errors are not distributed normally, if they have a pattern of their own, then your initial model is not a good fit, and you start from the beginning.

[RevGTO]

I think that Shawn is doing exactly what Marcin proposes: He has formulated a theory, tested it, and is in the process of trying to account for and compensate for all the variables that affect the system. But at a certain point, it becomes like climate change theory - you simply can't account for and factor in all the variables.

Let's get back to the brass tacks. We are involved in this because we have modified our engines' airflow with intakes, headers, cams, etc. As a result, our fueling is wildly off with the stock tune. While we may not be able to get it PERFECT, we do need to get it close.

Shawn's results speak for themselves. Reverse engineered or not, his fueling is reasonably accurate. Plus his method is simpler than previous approaches. It would be a mistake not to publish because of theoretical concerns about purity of method.

Until Marcin translates his knowledge of the system into a applicable tuning protocol, we have to do our best with other approaches, because we need to get our cars to run as well as they can. Please go ahead with refining your process and publish, Shawn.

[acomp917]

here I go again,

I refuse to let fisherman use the swingin bait to ruin what appears to be honest attempt to help others.

Sure there are dynamics in engine tuning. That should make it clear to the scientists that "absolutes'" when applied to transients are NEVER going to be perfect. After all, the engine is suppose to make a constant pull in order to accelerate a mass or maintain velocity. Any transient is just the tuners attempt to get it there.

MAKE NO MISTAKE! The MOST difficult tuning parameter to perfect(for average tuners) is "applied" timing(what the engine sees). There can be many(or few) variables. You must keep in mind that AFR is affected by timing. The only way to have PERFECT applied timing is to use a dyno(real TQ) or map cylinder pressure vs. crankshaft degrees(theoretic- max. pressure vs position(aft. TDC)). My recommendation is to apply a more aggressive timing (both slope and offset(learn this, it is used for many principles)) than GM uses. When you get familiar with timing you will notice it takes on the appearance of cam(contour)/compression ratio/fuel(offset)/vehicle use(slope) and to some degree vehicle weight and gear ratio(transient). These ALL apply to cylinder pressure(filling) and to a reasonable degree how long a given state is maintained.

When you get the timing setup(usually will not be the first), setting the fuel is easy. Map KR vs. (RPM, dyncylair), make sure you don't have knock. BAD knock will show on the plugs as aluminum deposits from the pistons. KR is VERY safe at the lower limits. Just remember that a modified engine might throw KR even if it is NOT experiencing detonation.

I plan on attempting to use some very old math skills to help interested users in the future. I know how engines and EFI work, now if I can just re-learn the math. This EFIL system is truely monumental(as far as my limited skills).

S

PS. RHS(aka Marcin) is a VERY technical mind. I think that his thought process has it's place. I just think he uses it egg members on. I wish he would reference created examples that attempted to show members how to apply his "hi" thinking to engine tuning.

[mr.prick]

You are acting like perfection can be achieved. :rolleyes:
If it could LTFTs/STFTs would not exist.
Remember that the LS1 controller is being used.
Maybe w/VVE perfection is obtainable but not here.

How about explaining why commanded EQ differs from what is defined by {B3601}.
I've logged a difference in commanded EQ as much as 0.003EQ during PE,
that's 0.04389AFR leaner than what {B3601}/{B3618} would command. :confused

I think there are a lot of things going on in the PCM/OS that most if not
all people do not take into account or even have access to while tuning.

[acomp917]

Mr. Prick,

DajaVu, Maybe I haven't been around long enough. :)

I had this exact reaction in the Lt1 forum years ago.


About that error: 0.04389AFR leaner

I don't know what we are gonna do!!! ;)

Now if some genus would tell me how to map DYNCYLAIR into a spark map... I would understand the missing link.

Best Wishes, No politics intended:rolleyes:
S

[mr.prick]

Mr. Prick,

DajaVu, Maybe I haven't been around long enough. :)

I had this exact reaction in the Lt1 forum years ago.


About that error: 0.04389AFR leaner

I don't know what we are gonna do!!! ;)

Yeah I know BFD it's just 0.04389AFR. :ranting:
But it's something to consider if you're striving for perfection. :angel_innocent:
:throw: The PCM won't even command what you want it to. :crash:

[WeathermanShawn]

Thanks for the support.

I still plan on updating the Draft Proposal on "A Beginners Guide To Tuning", CALC.VE Tuning Guide in the next week, before handing it off to TAQuickness for editing.

I personally like the concept of using BENS and Calculated PIDs. I think it greatly enhances the use of EFILive software, and makes tuning enjoyable. We all know where everybody stands on tuning philosophy, so I will let the readers ultimately determine what method(s) to use.

There is still be future work to do in incorporating the role of ECT in SD airflow calculations, but we can't let perfection get in the way of progress.

Look for future updates in the next week!

[redhardsupra]

PS. RHS(aka Marcin) is a VERY technical mind. I think that his thought process has it's place. I just think he uses it egg members on. I wish he would reference created examples that attempted to show members how to apply his "hi" thinking to engine tuning.



Until Marcin translates his knowledge of the system into a applicable tuning protocol, we have to do our best with other approaches, because we need to get our cars to run as well as they can.

Your complaints are noted. To me, after putting together 'three airmass model' all calibration became self-evident. Apparently you don't see it the same way. Now that I know there's a disconnect between my writing and perceived insight from reading it, I know there's more writing to be done. That's something I can definitely work with.

How about we cut a deal? I will write my stuff up in small, hopefully easily digestible installments. After each piece, YOU will comment, correct, ask for clarifications, expand on this, stop repeating yourself over there sort of collaborative editing. Once you're satisfied, I will move on to another section, until we're all satisfied.

Deal?

[tinindian]

This is awesome. I can't wait to see how this pans out.

[Steve Bryant]

Your complaints are noted. To me, after putting together 'three airmass model' all calibration became self-evident. Apparently you don't see it the same way. Now that I know there's a disconnect between my writing and perceived insight from reading it, I know there's more writing to be done. That's something I can definitely work with.

How about we cut a deal? I will write my stuff up in small, hopefully easily digestible installments. After each piece, YOU will comment, correct, ask for clarifications, expand on this, stop repeating yourself over there sort of collaborative editing. Once you're satisfied, I will move on to another section, until we're all satisfied.

Deal?

Marcin,
I think that this would be much appreciated by a number of people in the tuning community. Few folks have analized and studied the mathematical models and the interaction/interdependent nature of this stuff like you have. I'll be glad to give you feedback, and help in any way that I can.

Steve

[5.7ute]

Steve, Have you read this from Marcins site? http://redhardsupra.blogspot.com/2008/04/three-airmass-models.html
It is I believe the most pertinant to this discussion, & simplifies a lot of what he has stated earlier.

[WeathermanShawn]

TEMP= IAT+(ECT-IAT)*BIAS..where BIAS is a lookup table referenced against airflow..

Thats the one that makes life difficult!

[redhardsupra]

TEMP= IAT+(ECT-IAT)*BIAS..where BIAS is a lookup table referenced against airflow..

Thats the one that makes life difficult!

oh that's only the beginning of it. in and of itself, it's not that much of a pain in the...equation. however, you combine it with a 3d GMVE table to be solved at the same time, and you got a real problem on your hands. And if you're still bored, apply the lag filter to the temp estimator. That I haven't been able to solve for 2+yrs now :(

[5.7ute]

oh that's only the beginning of it. in and of itself, it's not that much of a pain in the...equation. however, you combine it with a 3d GMVE table to be solved at the same time, and you got a real problem on your hands. And if you're still bored, apply the lag filter to the temp estimator. That I haven't been able to solve for 2+yrs now :(

Dont forget slow reacting sensors, sensor heatsoak, airflow past the sensor etc etc.
Now, where did I put those O2 sensors again.

[redhardsupra]

Oh, I was just talking about the stuff I can control, then on top of it, you're absolutely right, you got all the 'natural' noise, limitations, and imprecisions. This is why I'm so anal about getting the stuff we can control correctly, because we already got plenty of noise to deal with.

[WeathermanShawn]

Its tough.

Might be interesting to be able to PID the actual Temp Bias Factor(s). I am not sure the Dynamic Air Temperature (PID) is applying the bias factors in its current form.

Now I can understand why temperatures have been problematic.

[5.7ute]

Its tough.

Might be interesting to be able to PID the actual Temp Bias Factor(s). I am not sure the Dynamic Air Temperature (PID) is applying the bias factors in its current form.

Now I can understand why temperatures have been problematic.

That lookup pid in the other thread will take care of the temp bias factor as long as the values match your tune. The lag filter will be much more complex to implement.

[redhardsupra]

Its tough.

Might be interesting to be able to PID the actual Temp Bias Factor(s). I am not sure the Dynamic Air Temperature (PID) is applying the bias factors in its current form.

Now I can understand why temperatures have been problematic.

you are right about the MAT DMA PID. Linear and I were bouncing off ideas the other night, and we realized that it would be much easier to figure out how they work if we could look at them separately as a lookup. feel free to generate more pressure on Ross/Paul here:
http://forum.efilive.com/showpost.php?p=115060&postcount=11


Shawn, dont take it the wrong way, but I don't think you can understand the uglyness of temp estimators, until you actually attempt to solve for all their components simultaneously. Holy crap it's convoluted. I wouldn't wish it on the worst of enemies. I spent few hundred dollars on math books before I was able to put a dent in it. I'm not gonna even mention the manhours.

[Steve Bryant]

Steve, Have you read this from Marcins site? http://redhardsupra.blogspot.com/2008/04/three-airmass-models.html
It is I believe the most pertinant to this discussion, & simplifies a lot of what he has stated earlier.

I'm reading it now. In fact, I've transferred it to a Word file so that I can print and study it. I've been reading/studing some of his other stuff in the past two weeks.

Marcin,
Once again, my hat is off to you sir for takling on some of the really heavy lifting.

Shawn,
My hat is off to you for taking on this tuitorial and having the courage to try some new stuff.

[5.7ute]

There is one small mistake in that write up. Where Marcin states

"This looks nice and simple as the scanner gives us IPW,"
This is showing to be incorrect, as the scanner gives us IBPW. Which is a sum of the fuelling portion of the pulsewidth as well as offset modifiers etc. This is all still being broken down & proven & but I am sure Marcin will correct this once the full IBPW equation is verified.

[WeathermanShawn]

Mick:I think I understand where you were going with this.

Something like this.

CALC.BLEND ="lookup({SAE.MAF}, 0.00,0.799805, 10.00,0.419922, 20.00,0.282715, 30.00,0.243652, 40.00,0.219727, 50.00,0.202637, 60.00,0.188477, 70.00,0.175781, 80.00,0.164551, 90.00,0.153809, 100.00,0.143555, 110.00,0.134277, 120.00,0.124512, 130.00,0.115234, 140.00,0.106445, 150.00,0.089844)"

% = {SAE.MAF.gps}*({SAE.IAT.C}+(({SAE.ECT}-{SAE.IAT})*{CALC.BLEND})+273.15)/((displacement()*61.024)*{SAE.RPM}*{SAE.MAP.kPa})* 212544

Maybe I will need some Tutorial help here. Can I enter a lookup Table directly into a Calculated Pid txt? This may get me closer.

Marcin, understand your point. I know it is very complicated.

Steve, thanks. I am just trying to get a better approximation of a CALC.VE using charge temperature. Sometimes with this GM PCM 'voodoo' you can't tell if just introducing MAF failure is a proper technique to isolate dynamic airflow. Who knows, with MAF enabled it might be a different calculation.

[joecar]

Good discussion...:cheers:

[5.7ute]

Mick:I think I understand where you were going with this.

Something like this.

CALC.BLEND ="lookup({SAE.MAF}, 0.00,0.799805, 10.00,0.419922, 20.00,0.282715, 30.00,0.243652, 40.00,0.219727, 50.00,0.202637, 60.00,0.188477, 70.00,0.175781, 80.00,0.164551, 90.00,0.153809, 100.00,0.143555, 110.00,0.134277, 120.00,0.124512, 130.00,0.115234, 140.00,0.106445, 150.00,0.089844)"

% = {SAE.MAF.gps}*({SAE.IAT.C}+(({SAE.ECT}-{SAE.IAT})*{CALC.BLEND})+273.15)/((displacement()*61.024)*{SAE.RPM}*{SAE.MAP.kPa})* 212544 Maybe I will need some Tutorial help here. Can I enter a lookup Table directly into a Calculated Pid txt? This may get me closer.



Yes, the calculated pids support the lookup function. What this pid will do is get the value from the SAE.MAF pid. Compare it to the values in red(The axis value from the tune file) & return the value after the comma (This is the actual value from the tune). This function does interpolate values so you should be fairly accurate.

[redhardsupra]

There is one small mistake in that write up. Where Marcin states

"This looks nice and simple as the scanner gives us IPW,"
This is showing to be incorrect, as the scanner gives us IBPW. Which is a sum of the fuelling portion of the pulsewidth as well as offset modifiers etc. This is all still being broken down & proven & but I am sure Marcin will correct this once the full IBPW equation is verified.

heh, the reason for it is much more prosaic: I was using HPT which doesn't have IBPW equivalent.

so when are you gonna send me the full formulation of IBPW and IPW? you've been teasing me for months now ;)

[5.7ute]

so when are you gonna send me the full formulation of IBPW and IPW? you've been teasing me for months now ;)

Soon I promise. Knowing is one thing, but proving with any real accuracy is being somewhat more difficult.:grin:

[WeathermanShawn]

Thanks for the Tutorial. Got it into my Calculated PIDS:

CALC.VE_BLEND = {SAE.MAF.gps}*({SAE.IAT.C}+(({SAE.ECT}-{SAE.IAT})*{CALC.BLEND})+273.15)/((displacement()*61.024)*{SAE.RPM}*{SAE.MAP.kPa})* 212544

Also, got that CALC.NEW_VE= CALC.VE*CALCLTFTBEN PID in. Saves a big step.

Thanks. I'll see where that takes me..:grin:

[5.7ute]

heh, the reason for it is much more prosaic: I was using HPT which doesn't have IBPW equivalent.



So HPTuners use the calculated value without offsets,adders etc in the scan tool?

[redhardsupra]

So HPTuners use the calculated value without offsets,adders etc in the scan tool?

that's the problem: without the DMA PIDs of it's components, you don't know which IPW is it really.

[DrkPhx]

Weather permitting, I'm going to give this a try and create a new VE and MAF table to compare against my existing ones to see how close they are.

[redhardsupra]

here's something new I wrote up, to hopefully clarify some issues you guys have been bringing up.

http://redhardsupra.blogspot.com/2010/02/maf-vs-sd-comparison.html

[WeathermanShawn]

On this end I have completed my work. We successfully created a Calculated Pid that will allow a tuner on one-two logging runs to successfully calibrate the MAF, VE Table, and Trims simultaneously.

It took a while to incorporate charge temperature in the PID, but if you are interested in a simple method that works, I hope to have the final tuning guide online by tomorrow. So far we have gotten a MAF-Closed Loop and SD Closed-Loop with 2% of each other (both VE and Trim values) and WOT AFR.

Thanks for your patience. I hope it helps, especially for beginners.:)

..Hopefully just these three pids..

[DrkPhx]

So just copy and paste the entire calc pid in the text file?

[DrkPhx]

hmm. I did something wrong when setting up the calc.pid. I received the following error report when opening up the scan tool (not connected to a vehicle). I added the information into the sae.generic file under EFIlive/7.5 on the C drive. Hopefully I didn't screw up too bad. Any tips? Can I just delete the added info?

Error report generated by EFILive at 20:00:39 on Feb 20, 2010

Error code: ERR_CONFIG/92
C:\Program Files\EFILive\V7.5\Configuration\sae_generic.txt(8 88): Units VEpcma not found. .

EFILive Version: 7.5.5 (Build 88)

Platform: Windows XP
Version: 5.1 (build 2600)
Processor type: Pentium 1862MHz

[DrkPhx]

Got it fixed. Forgot to add the units. The Calc VE table is coming up as invalid. I assume that shouldn't be a problem once I connect to the vehicle.

[DrkPhx]

It's okay now. Go figure. I assume I use the newly created Calc VE pid for the Calc VE Map.

[WeathermanShawn]

I have finalized the "Beginners Guide to Tuning."

[Steve Bryant]

Shawn,
I have just glanced over your final draft document and saved it for printing. I want to congratulate you and thank you for all of your hard work.

Highest regards,

Steve

[WeathermanShawn]

Thanks Steve..

Yours is next!:)

[RevGTO]

Thanks, Shawn. I've got the CALC.VE pid selection in place and am looking forward to logging a run, working the tables, and checking the results. Hoping for some decent weather soon ...

[ScarabEpic22]

Shawn, going to look over it now! Kinda wish I had a LS1 PCM vehicle to try it out on, can you start working on an E38/E67 version now? haha just kidding man, great work!

[joecar]

So is the displacement() function working for you/anyone...?

[WeathermanShawn]

Thanks guys.

You can use the EFILive CALC.VE PID to get you close. If you can get that GM.DYNAIRTMP_DMA into your own CALC. PID, (as described) it dramatically increases the accuracy, especially in low airflow situations.

As far as other platforms, 5.7Ute originally submitted the idea of including 'charge temperature' into the equation. He calculated it via look-up tables. So it may be possible to calculate the charge temperature for other platforms, but I am not sure. My laptop lagged a little with the look-up table scenario, but there is probably a way around it.

As Joecar stated, I believe the new software update corrected the engine displacement problem that had existed before. Before you had to manually input engine size (or work around it). Should be no problem now. I'll try it out here in the next few days.

[joecar]

I have an idea: replace {GM.DYNAIRTMP_DMA} with {GM.DYNAIRTMP_DMA.C}

i.e. add .C on the end of it.

[WeathermanShawn]

Great idea!

I will keep the editorial window open for technical revisions of this nature.

[5.7ute]

I have an idea: replace {GM.DYNAIRTMP_DMA} with {GM.DYNAIRTMP_DMA.C}

i.e. add .C on the end of it.


What does this do Joe? Change it to metric units?

[joecar]

Yes, it selects Metric units regardless of the default set under the PIDs tab.

[5.7ute]

You learn something new every day here. :cheers:

[joecar]

You learn something new every day here. :cheers:+1, x2, ditto here. :cheers:

[WeathermanShawn]

A few people have PM'd me concerning the CALC.VE_Table PID, and are having trouble configuring it.

I have attached my calc.pids.txt file. The only difference is that I have manually entered my my own engine displacement (in lieu of using the displacement pull-down).

Supposedly there is a fix in the latest software update..http://forum.efilive.com/showthread.php?t=13075&page=5.

If you get the PID up and working, there are great links to enhance your tuning knowledge by reading the following link.. http://forum.efilive.com/showthread.php?t=2990. (http://forum.efilive.com/showthread.php?t=2990)

[TAQuickness]

Your tutorial looks great Shawn.

PM on the way

[WeathermanShawn]

Thanks Andy:

I have been taking the last week or two to see if I have missed anything obvious. Testing a few points out over..

I read your PM..took it to heart. You made some great points.

I'll be in touch. :cheers:

[WeathermanShawn]

Guys and Gals:

I have taken this 'Tutorial' about as far as my talent can go. I have tested, re-tested, and it is extremely accurate in modeling the similarities in MAF airflow, and how EFILive's version of a VE Table is constructed using charge temperature.

Since I have always considered this nothing but a 'labor of love', I am sending the Guide to be professionally formatted, Titled, tweaked, etc. by TAQuickness who has authored the now infamous AUTOVE Tutorial.

As Andy has stated, I will forever 'own' the method no matter where I go in life. Other than wishing I had spent more time explaining filtering stoich and WOT..and knowing there are a few flaws in applying a LTFTBEN (especially WOT), I am convinced it is a very sound and accurate method to construct a "VE Table", calibrate the MAF, and tune Trims simultaneously.

If it is of use to the EFILive community and can stand the test of time, I will have considered it an accomplishment.

I am not going anywhere..but closure to this thread will help readers know it was not just a mental exercise.

Thanks..

..WeathermanShawn..

[tinindian]

Shawn - Thanks so much for the time & effort you've put into this project. I'm looking forward to tuning with your method as soon as this damn weather breaks. Cheers.

[Steve Bryant]

Shawn,
Thanks for all of the effort that has gone into your project. Do you know how something like this becomes verified and is added to the other tuitorials?

Thanks again,

Steve

[WeathermanShawn]

Steve:

Great question.

In this case, EFILive's MAF Based- CALC.VE 'formula' already existed. It just took some tinkering with EFILive's VE Table to demonstrate the effect of charge temperature of the calculations. In the Tune Tool if you change the VE Table units to g/cyl, and run a log with GM.DYNAIRTMP DMA logged, you can easily see that it is indeed the 'charge temperature' being used (+/- some IAT bias lag).

g/cyl = VE*MAP/charge temperature. From there it just took some math (not mine) to fit it into the formula.

Idea+math+test of time=Tutorial.:grin:. (and use of calculated pids)..

I would think that anything that meets the needs of a community (tuners), and if you can demonstrate a reasonable degree of 'proof' or applicability there will be interest. In this case, I have attempted to make it very user-specific..MAF-Closed-Loop. If nothing else, I learned a lot just doing it.

[redhardsupra]

i'm going to repeat myself: check your units.

VE is dimensionless, MAP is kPa, Temp is in K. so how come kPa/K gives you grams?

[WeathermanShawn]

Its really not pertinent to the conversation.

It is a quote from EFILive's VE Table. Address the issue with them. I used it for demonstrative purposes only. I think everybody knows that.

The air mass per cylinder can be determined from the VE table using the following formula:
g/cyl = VE*MAP/charge temperature
Ve is in g*K/kPa,
MAP is in kPa,
charge temperature is in degrees Kelvin.

It really has no bearing on the topic. If people are interested in the math, I think I saw Joecar's breakdown on the entire formula posted in a previous thread...http://forum.efilive.com/showthread.php?t=13059&page=5..

[WeathermanShawn]

An official Tutorial Proposal has been submitted:

Please link to this thread for further information..http://forum.efilive.com/showthread.php?t=13152

Thanks..

[joecar]

An official Tutorial Proposal has been submitted:

Please link to this thread for further information..http://forum.efilive.com/showthread.php?t=13152

Thanks..
Bump.

[Gelf VXR]

ok, i'm gonna be a science stickler again...
check your units, what does g*K/(sec*m^3*kPa) simplify to?

you do know that IAT != MAT and that cylinder airmass from MAF is already done for you in the form of CYLAIR, right? so then to solve for VE, all you need to do is start with CYLAIR=VOL*VE*MAP/(R*MAT), and rearrange to isolate VE so you end up in the form of
VE=CYLAIR*R*MAT/(VOL*MAP)

if you want dimensional analysis of it done, it's a bit convoluted, but it checks out clean. it's all in my 'how SD works' from four years ago.

Is this still available to download, the link doeskin work on the blog?

Is it stored on this forum?

[redhardsupra]

Is this still available to download, the link doeskin work on the blog?

Is it stored on this forum?

no, but it's stored on that forum ;)

http://www.hptuners.com/forum/showthread.php?18836-How-Speed-Density-Works-%28Article-I-found%29-True

[Gelf VXR]

no, but it's stored on that forum ;)

http://www.hptuners.com/forum/showthread.php?18836-How-Speed-Density-Works-%28Article-I-found%29-True

Thanks :)

[joecar]

Hey Marcin, how's it going :cheers: