Leave the MAF alone?

[johnsZ06]

The thread over on "Tech" got me thinking. Does anyone tune just the VE and leave the stock MAF settings alone?

I kind of agree that if a MAF is calibrated it should report exactly how much air flows through it regardless of the type of intake you are running. I understand reversion can screw with these readings but besides that, should it's calibration be messed with? Why not just tune the VE and forget the MAF?

I'm sure has been beat to death but humor me will you, my memory isn't what it used to be. :D

[SSpdDmon]

I got to thinking the same thing at one point. There's a guy not too far from me who has a flowbench he could stick my MAF on and give me a calibration curve since my SLP MAF/SLP Lid combo isn't stock. I almost thought about doing that...just don't want to spend the money on it.

Aside from that, I think it'd be a little hard to calibrate the VE while the MAF is active. From what I've read and what I've observed in practice, it's almost like there's a swing factor that we can't see. In other words, if the VE calculation results become more distant from the MAF calculation, it's almost like there's some factor that will try and lean towards the side it thinks is more right. I don't know if that makes sense...but, I know I've tried changing the VE while the MAF was active and saw some weird results (almost like they were the opposite of what I was trying to accomplish).

I was hoping the guys on here who wrote our software would jump into this discussion to possibly shed some more light on the subject... ;) :)

[johnsZ06]

I got to thinking the same thing at one point. There's a guy not too far from me who has a flowbench he could stick my MAF on and give me a calibration curve since my SLP MAF/SLP Lid combo isn't stock. I almost thought about doing that...just don't want to spend the money on it.

Aside from that, I think it'd be a little hard to calibrate the VE while the MAF is active. From what I've read and what I've observed in practice, it's almost like there's a swing factor that we can't see. In other words, if the VE calculation results become more distant from the MAF calculation, it's almost like there's some factor that will try and lean towards the side it thinks is more right. I don't know if that makes sense...but, I know I've tried changing the VE while the MAF was active and saw some weird results (almost like they were the opposite of what I was trying to accomplish).

I was hoping the guys on here who wrote our software would jump into this discussion to possibly shed some more light on the subject... ;) :)

I noticed the same thing when trying to tune VE with the MAF connected. It seemed as if I was going the wrong way which I thought was strange, but then I just blammed it on not knowing what I was doing. :bash:

I might play around with this idea some more this weekend just to see what kind of results I get. After all, that is one reason I bought the software - so I can tinker! :)


About having some of the software guys chiming in, I think they already did in the Flash Scan software where they make the following statement...


This table should only be modified to suit a specific MAF sensor's characteristics.
Though it can be, this should not be used to adjust overall fuelling.

[Doc]

That guy in the LS1tech thread is a tool. I don't have to get into an esoteric physics debate to know what works for me. I use the RR, an LC-1 and the track/dyno know that I get the proven results.

That guy essentially has said "You suck and your method sucks," without offering any real proven information because he "Doesn't want to give away all that hard earned knowledge." Whatever.

Look at me, I've got a 5gas analyzer and I Know how the software was engineered. You rubes with your cheap widebands and VE tuning are all fakers.

So I guess we should all line up and bow down to LS1Bi-curious?

:master:

[johnsZ06]

That guy in the LS1tech thread is a tool. I don't have to get into an esoteric physics debate to know what works for me. I use the RR, an LC-1 and the track/dyno know that I get the proven results.

That guy essentially has said "You suck and your method sucks," without offering any real proven information because he "Doesn't want to give away all that hard earned knowledge." Whatever.

Look at me, I've got a 5gas analyzer and I Know how the software was engineered. You rubes with your cheap widebands and VE tuning are all fakers.

So I guess we should all line up and bow down to LS1Bi-curious?

:master:

hehe...yeah, tool is putting it nicely. He was pulling crap out of his arse. I will say this, he did get me to think about the current way I'm tuning.

[Redline Motorsports]

I kind of agree that if GM has the MAF transfer function setup to report that a given hrtz equals a given lbs/minute then changing that scale would provide a false value. From a tuning standpoint whatever gets the fuel dialed in............works. If the VE table (or what I refer to as the base fuel table) is properly calibrated, with MAF disconnected, then re-enabling the MAF and scaling to match the commanded numbers would most certainly disturb the MAFS reporting accuracy...............but the cars tuned.

What does this really screw up?? How often do you tune with lbs/minute values??

Good topic!

Howard

[johnsZ06]

It seems to me that fudging with the MAF is equivelant to fudging with the IFR table in order to correct for fueling, which IMO is not the right way to do it although you can obtain the same results.

What I plan to do is build a map that logs VE as a percentage, which is calculated of course, against the intake manifold pressure (MAP) and log a histogram while leaving my MAF plugged in and see how that compares to my current VE table.

Theoretically speaking, I should be able to plug those values into the current VE table and have my Ltrims close to zero.


BTW, I compared my current tune MAF table and noticed the values were much higher than the MAF used on the LS2 which I'm sure flows more air. I know this can't be right.

[redhardsupra]

It seems to me that fudging with the MAF is equivelant to fudging with the IFR table in order to correct for fueling, which IMO is not the right way to do it although you can obtain the same results.

YES! you got it!

ultimately the point of the PCM is to calculate the pulse width, whether it uses the MAF lookups or SD calcs.

IPW=airflow*RPM*IFR*AFRwb (MAF)
or
IPW=VE*MAP*CYLVOL/(IPW*AFRwb*R*TEMP) (VE based SD)
or
IPW=GMVE*MAP/(IPW*AFRwb*TEMP) (GMVE based SD)

so you can get the same IPW number by dicking with MAF, IFR, AFRwb, TEMP, MAP, VE or GMVE.

the HUGE problem is that while you can make it work for singular numbers, it's very difficult to get it to be right all the time, given the tables we got. IFR is not linear. AFRwb is twitchy at best, TEMP is highly non-linear and modeled based on a bias table which should change if we mod things. then you take all these non-linear components and combine them into a IPW calculation. do you really think the result of that is gonna be anywhere near as simple as he claims?

these days, VE and GMVE have become the 2d replacement fudge table for the former 1d IFR fudge table ;)

this is a much more complicated model than people think. this dude just wants to mess with OLFA and VE, which effectively is accounting for ECT, MAP and RPM. still not accounting for IAT, IFR, and air density in general.

no math, no soup for him, whoever said that in that thread oughtta get a beer.

[johnsZ06]

YES! you got it!



I got something? Oh Hell, there goes the neighborhood! :eek:

[Doc]

I'll have a Guiness, Brilliant!

Seriously, this sad, tired, argument LS1curious presents had me second guessing my navel lint a few years ago. Then March 12, 2006 I got my Road Runner and that thing opened my eyes and flushed all of his types of agruments down the toilet. For those without a RR I don't see how his "way" would be any more successful than the accetped AutoVE/MAF tuning method expoused on this board and as exhibited by Jeff's (SSpdmon) failed experiment trying to employ his methods.

If you can get the vehicle to produce the desired A/F on a lowly WB throughout the various states, ECT, IAT, load values and be "so smooth your momma could drive it," then I don't care how you do it.

It just so happens that there are quite a few folks on this board using this product that have been able to reproduce the same desired results time and time again. All I see on Tech for the most part are confused HPT users with very inconsistent results.

Note the OP in that thread was a HPT user trying to find out how to tune his MAF.

[redhardsupra]

If you can get the vehicle to produce the desired A/F on a lowly WB throughout the various states, ECT, IAT, load values and be "so smooth your momma could drive it," then I don't care how you do it.

well, kinda, maybe, but not really ;)
I've been building my fueling model long enough that by now I know the final function is so damn complex and nonlinear that I'd be really amazed if there were multiple, sufficiently different approaches to achieving consistent fueling across the full range of driving conditions. ultimately no matter what model we come up with, we're gonna have to convert it into the simple lookup tables that the pcm works from too, so we're going to lose some resolution at the end as well.

i guess the only thing i can see from this guy's post is that we dont really know how the SD calcs are done. i derived my own, which seem to work pretty damn well, and i got some new stuff coming up that's really going to enhance the precision, but we never really saw what is the equation to come up with the final pulse width.

Paul, pretty please, post something, i dont care if it's straight assembly, i can figure it out ;)

[ViolatorTA]

Don't take this the wrong way. I too have been an avid SD guy myself and have seen too many variables with my tune to drive me nuts but still push foward towards getting something accurate and meaningfull. This is why I read everything I can find and try to come up with something.

Here is a few things. RHS has figured IPW is the key. So what exactly does the PCM look at to determine the IPW "IT" wants to see and send. Not another model but the designed model. No-one knows what that model is. From everything I've been reading into acroos anything I can find on the net(not forums or blogs) the GM PCM looks at all the items listed by RHS but also looks at MAF values and O2 values. Maybe this system was never meant to be a SD system at all and VE tables are set to keep the car running in case of a MAF failure. {Just rambling here but anything said could be completely meaningless or have even one small point.}

From what I understand the GM system uses the MAF calcs as the final determining factor for calculating air density GM MAF do use a heated wire signal. Who's to say that isn't part of the charge temp calculator?

I know that with my current VE table, if I run with MAF and O2's(closed loop) my IPW's are stable as could be. High,low and average values. Once I run in SD(open loop, no MAF, no O2's sensors.Just a WB reading) my IPW's are all over the place. Especially down low where they range from .55 to 1.87. or even higher up where 4.03 is low to 4.93 high. Much larger swings than in closed loop.

Don't know if this could be MAF or O2's on line so those will be the next tests. A log with MAF online, O2's off and MAF offline, O2's on.

[SSpdDmon]

What if we did the reverse of the normal process. If the MAF was the only factor and we eliminate the VE by dropping that 4,000rpm mark down to 400rpm (B0120 I think), shouldn't commanded match observed then??

[johnsZ06]

What if we did the reverse of the normal process. If the MAF was the only factor and we eliminate the VE by dropping that 4,000rpm mark down to 400rpm (B0120 I think), shouldn't commanded match observed then??

Well, I tried setting the MAF back to it's stock values and tune the VE. Let me just say this, it won't work! :bash: I'm sure most of you already know that! lol

I would have to have VE values way in excess of 100% to get the trims just vaguely in line and when I did this, the engine ran like crap. What an exercise in futility!

I messed with it for a couple of hours and then loaded my stock tune. My car is much happier now.

I sure would like to know what the deal is with the code and what black magic is going on behind the scenes. This is really a black art!

[Doc]

What if we did the reverse of the normal process. If the MAF was the only factor and we eliminate the VE by dropping that 4,000rpm mark down to 400rpm (B0120 I think), shouldn't commanded match observed then??

That's the thing tho and I think you already know this Jeff but for the newbs, below 4k the pcm is blending the MAF and VE because there is no steady state of flow going accross the MAF sensor wires-turbulence.

John, there really is no Black art and, you don't need a 50k dollar 5 gas analyzer or really know the exact how's or why's of the exact interactions of the algorithms GM used. Basic EFI theory still applies here and can be monitored well enough with a wideband O2 and the scanner.

The RR gives you an insight in realtime how one little thing can afffect everything. There are plenty of ways to arrive at the same solution.

[dfe1]

All I see on Tech for the most part are confused HPT users with very inconsistent results.

You've got it. There are more assholes and clerk typists on LS1tech than you can count. I think my dog knows more about tuning than some of them.

[Black02SS]

:muahaha::muahaha::muahaha::muahaha::muahaha:

:cheers:
You've got it. There are more assholes and clerk typists on LS1tech than you can count. I think my dog knows more about tuning than some of them.

[ViolatorTA]

Are we sure we have the right tables in Live or HPT to that matter.

Here we have a description of MAP failure and fueling will be TPS and predetermined MAP values.

http://img.photobucket.com/albums/v696/Violatorno1/Desc2.jpg

Here we have a description of open loop that as highlighted states that fueling will be TPS and MAP or MAF values.

http://img.photobucket.com/albums/v696/Violatorno1/Desc1.jpg


Maybe what we have is wrong and rpm/map based instead of TPS/MAP based.

Ad to that, LS1's use cold wire MAF's if that means anything along with the MAF measures ambient air temp and uses IAT as a comparison factor. I havn't read into exactly what yet.

[redhardsupra]

damn it, we need code, i can only figure out that much oogling data :(

[Doc]

You go to the head of the class for actually reading Mitchel's(GM's) version of Open Loop fueling...

Read it again tho...No longer is fueling based on (NB)O2 readings, and as you read, Open Loop is determined by TPS, MAP and or if still online the MAF, (hence OLMAF operation) with this caveat... In a normal stock GM OS the actual commanded fueling value is determined by the richer of PE vs. RPM {B3618}or Commanded fueling when in Open Loop based on ECT vs. MAP {B3605} both of which are lower in resolution, (meaning in the real world you have less cells to manipulate over various driving conditions) than EFI Live's Custom OS's in which Commanded Open Loop fueling is RPM vs. MAP {B3649}. It doesn't take long to see the obvious benefit to the Custom OS's.

So, just to review, you have to start with knowing what the pcm is commanding first. Then recalibrate the aforementioned sensor's tables in the tune with known good, filtered WBO2 data.

Now the dirty little secret (that becomes painfully apparant with the RR) is that the pcm averages out all of the data from the various tables to arrive at it's final commanded fuel calculations and this is what drives the high priests bonkers. What the actual algorithm is I don't know, with the RR I can follow the game pieces on the game of LIFE, er LIVE to get my actual fueling to match my commanded thru trial and error very quickly.

Without the RR, it could take an eternity for a rube like me to figure out for each very different combo that is out there with a slide rule, so to speak. Kelly Johnson, (for those of you in Rio Linda, SR-71 Blackbird father) er, Marcin, will do it I am sure of it.

Time for more Shiraz, cheers!







Are we sure we have the right tables in Live or HPT to that matter.

Here we have a description of MAP failure and fueling will be TPS and predetermined MAP values.

http://img.photobucket.com/albums/v696/Violatorno1/Desc2.jpg

Here we have a description of open loop that as highlighted states that fueling will be TPS and MAP or MAF values.

http://img.photobucket.com/albums/v696/Violatorno1/Desc1.jpg


Maybe what we have is wrong and rpm/map based instead of TPS/MAP based.

Ad to that, LS1's use cold wire MAF's if that means anything along with the MAF measures ambient air temp and uses IAT as a comparison factor. I havn't read into exactly what yet.

[ViolatorTA]

need to find out if this was implemented in the ls1 based pcm's. This is right up your alley rhs.

http://delphi.com/pdf/techpapers/1999-01-0206.PDF

[Doc]

Even better! I have read this before as well. This is exactly what I have been talking about and what RHS wants.


need to find out if this was implemented in the ls1 based pcm's. This is right up your alley rhs.

http://delphi.com/pdf/techpapers/1999-01-0206.PDF

[redhardsupra]

oh i havent seen this one, come to pappa.... ;)

[ViolatorTA]

I'll keep looking and posting what I can find.

[redhardsupra]

Don't take this the wrong way.
not until you start making claims with no backup ;)

RHS has figured IPW is the key. i havent figured out shit, that's just what PCM is there for;)

So what exactly does the PCM look at to determine the IPW "IT" wants to see and send. Not another model but the designed model. No-one knows what that model is. From everything I've been reading into acroos anything I can find on the net(not forums or blogs) the GM PCM looks at all the items listed by RHS but also looks at MAF values and O2 values. I hope so, that's why we have MAF and closed loop operation ;) the trick here is to know HOW it takes them into account, what kinds of discrepancy is allowed as nosily signal and what is actually considered junk.

Maybe this system was never meant to be a SD system at all and VE tables are set to keep the car running in case of a MAF failure.

From what I understand the GM system uses the MAF calcs as the final determining factor for calculating air density GM MAF do use a heated wire signal. Who's to say that isn't part of the charge temp calculator?

i dont believe that because if it did, then the car would be extremely flaky in full SD (as in no more MAF, physically). between MAP, IAT, and ECT, it should be able to figure out the air density.


I know that with my current VE table, if I run with MAF and O2's(closed loop) my IPW's are stable as could be. High,low and average values. Once I run in SD(open loop, no MAF, no O2's sensors.Just a WB reading) my IPW's are all over the place. Especially down low where they range from .55 to 1.87. or even higher up where 4.03 is low to 4.93 high. Much larger swings than in closed loop.

Don't know if this could be MAF or O2's on line so those will be the next tests. A log with MAF online, O2's off and MAF offline, O2's on. MAF has the magical property of automatically being able accounting for air density. That's pretty much much its greatest strength. other than that it's crap in the way of airflow, it's spot metering a large area of flow, it's another piece of plastic contributing to heat soak, etc.
SD on the other hand is a bunch of sensor data, so it's less reliable (more crap to break), every sensor has its resolution, ultimately multiplying out the errors.

the hard part of SD is the modeling. that's my latest research, and lemme tell you, it's friggin huge and very complex. however, because i worked it all out myself from scratch, i fully understand the simple version of the process, now i can just go in and fill in the details. Bias I think i can do now, although i haven't tested it yet, maybe after this weekend i'll know more. then IFR. then IPW, the full model with short pulse modifiers and voltage offsets. once you put it all together, it should work alright.

I'd make a small bet that the swings at idle you're seeing are a result of the temperatures changing more and quicker than usual. if you're sitting at a light heatsoaking and then you romp on it, you have a very large temp swing happening quickly, and changing as it goes too.

if you got two logs for the idleing problems with no other changes but MAF vs SD, i'd love to see them, they might have a clue onto something i've been thinking of for a while now.

[joecar]

Any more Delphi white papers...?

[Treurentner]

Hi Joecar & Marcin,

you should read this:


On the Validity of Mean Value Engine Models (http://delphi.com/pdf/techpapers/2000-01-1261.pdf)
During Transient Operation SAE (http://delphi.com/pdf/techpapers/2000-01-1261.pdf) 2000-01-1261

if you didn´t already :)

Marco

[ViolatorTA]

Problem is having logs in both cases with the proper PIDS selected. You tell me what you want PID's you want logged and from what state, cold or fully warm or from cold to warm up, and I'd be more than happy to log it for you.

[ViolatorTA]

Joe, I'm finding these papers by sheer luck with different searches. Seems once you find one and try to go to the main page for a list you get forbidden page errors.

[joecar]

Joe, I'm finding these papers by sheer luck with different searches. Seems once you find one and try to go to the main page for a list you get forbidden page errors.That's what I'm getting... me-> :bash: <-their website

[joecar]

Hi Joecar & Marcin,

you should read this:


On the Validity of Mean Value Engine Models (http://delphi.com/pdf/techpapers/2000-01-1261.pdf)
During Transient Operation SAE (http://delphi.com/pdf/techpapers/2000-01-1261.pdf) 2000-01-1261

if you didn´t already :)

MarcoMarco, I haven't seen that, thanks. :)

[shallow bay]

Any more Delphi white papers...?
http://delphi.com/news/techpapers/

[joecar]

Thanks. :)

[ViolatorTA]

How's that code comming along RHS?

[joecar]

How's that code comming along RHS?I don't think he's got it yet, LS1curious has to sift thru it for a few weeks to extract just the relevant parts...

[redhardsupra]

How's that code comming along RHS?
no code, but 112 pages of thesis is...must finish soon...

[joecar]

no code, but 112 pages of thesis is...must finish soon...Get back to work mate, you'll be finished soon enough...

after you finish, your head will feel like it got unclamped from a vise...
:cheers::cheers::cheers::cheers::cheers::cheers:

[ViolatorTA]

Here's an interesting read.

http://findarticles.com/p/articles/mi_m3165/is_2000_Oct/ai_68324509

10 engineers over 3 years :Eyecrazy:

"That environment is troublesome because software requirements are ever more complex. If printed out, the software code necessary for a typical V-6 powertrain control module today would fill 5,000 sheets of paper (about 50 lines of code per page). The next generation powertrain control module will require about 10,000 sheets." :Eyecrazy: :bawl:

[joecar]

Yes, code is getting bigger in all areas... a good code editor provides code browsing features to make it possible for humans to navigate/edit/debug 500,000+ lines of code.