Has anyone found a charge temp solution?

[redhardsupra]

The 'use small IAT,ECT ranges to dial it in' idea makes no sense to me. The entire reason to have the temperature estimator is to be able to correctly account for all conditions.

The bigger point here is chasing after what I call 'proper attribution.' You are chasing after VE and Bias at the same time, using the same method: making changes to the inputs of the airmass model, by observing changes in the resulting fueling. Given a change, how do you attribute how much of it is due to the change in VE, and how much of it to change to Bias? Which input change was it that made the correct change, and not just for one condition, but for them all? How do you arrive at such a conclusion?

[S2H]

the small IAT/ECT ranges is your Control for dialing in VE...
then you dial in Bias using a wide variety of data... the more data the better.

GM does it in a controlled environment...which we dont have access to..so we have to control as much as we can.

by moving the boas it directly effects the VE...
so we make a small change in the bias...save it...check the VE in a controled set of variables..., once VE is redialed in for that small set of variables...we save it.. and then drive and log(making sure to not change anything) and just logging lots and lots of data...
when you feel you have enough data, you make another change to the Bias...

as you get closer to the right values, you will see less and less changes in varying IAT's...

its not something you can do with a log in the morning and a log at night right now because you cant yet meld together 2 logs...
but in the future, when we might be able to do that.. you could do a morning run for the cold side and a night run for the warm side and do a giant single log to use for data to fill the chart...


obviously if you are getting 5% lean in hotter temps and 5% rich in colder temps then you need to change the Bias...

and like I said...
in order

Make log...
look at data and make changes to Bias...(only change Bias...)
drive again to correct VE(Only VE changes this time)
drive again and log new data for Bias

3 parts...
1) log only
2) bias change only
3) VE change only


problem is that if you change the Bias..it changes the VE...
all I'm saying to do is to correct the VE after you change the bias...not at the same time...


theres no good way to do it... but there's also no reason to leave it alone and have drastic swings in fuel

and again...it really doesnt matter what values are in the VE table...its all theoretical anyways...
fueling richer in cold and leaner in hot... increase bias values in that cell
fueling leaner in cold and richer when hot, then decrease the values in the bias table

[Higgs Boson]

So in a carb car the correction is non existant which means it would be like setting the bias table to the highest setting all the way across, right? I mean getting leaner when cold makes sense as that is what a carb car does, right?

Could you set the bias table to the highest setting all the way across and tune your VE table on the hottest day possible and then tune the bias table down on cooler days (or a winter day)?

I mean, really, how much is it going to lean out if you tune the VE table on a 105 degree day outside and then you go to the track at night and it's 85?

For an open loop car that doesn't get driven in the winter, should a different philosophy be taken when setting up the bias table?

IAT varies a lot more than ECT.... My car for instance runs 190-196 no matter how hot it is outside. It seems like if I am going to have a table to account for temp swings, I would want it to look at the temp that swings.....IAT. So really, the bias table isn't IAT vs ECT, it's just an IAT weight table, how much do you want to involve the IAT sensor in fueling correction, right?


Oh and one other thing, would you want to change your VE table every time? Can you not just tune your VE, then save a log at a given temperature, do another one when it's hotter or cooler out and then adjust your bias table accordingly? Keep saving logs and adjusting bias table until the logs all come out the same? That way you can hold your airflow maps constant.

[redhardsupra]

quick heuristic: 15C error in temp estimation will cause ~5% of error in fueling. so instead of 14.7 you will hit 14.0 or 15.4

[erics_02_z06]

So to summarize: mock up a histogram mirroring the Bias table and tweak it accordingly to what AFR%error tells you to do.

Let's think about it for a second. What does this method achieve?

Bias is a part of the temperature estimator. Temperature, in combination with VE and MAP is used to create airmass. That would only work, if your VE is a known quantity. But it isn't. You need VE to calibrate Bias, and you need Bias to calibrate VE. It's a vicious circle.

For the more enginering-minded, the entire SD calibration process is described with:

AFRwb*IFR*IPW=GMVE*MAP/TEMP

I am a little confused. For a given RPM (to look up the VE value), MAP, IAT, ECT, IFR, IPW, AFRwb, can't we solve for the correct correction factor using this equation? Can't we log all of these variable and then solve? I guess we would need to log g/cyl to know what bias is being used. But if we know the bias being used, and we know the AFR error, can't we relate an error in bias to the AFR error. Granted, other factors are causing error as well, but we are all assuming the bias is the primary cause.

so using something like 0 = GMVE*MAP/(TEMP*IFR*IPW), where Temp= 273+ IAT + (ECT-IAT)*Factor

Whe know everything but FACTOR. So we solve for Factor. We just need to know what g/cyl would relate to the cells we used. So we would need to log at large set of data for different g/cyl Actually, maybe I'm way off here, but it was a thought. I'll be honest, I don't even know what dynamic airflow is, so I could be way off....



You cannot solve this equation if you have two unknowns, because it's an underdetermined equation. This has nothing to do with tuning, that's just math.

So dear SoundEngineer, your idea of holding VE constant, adjusting Bias, then swap, rinse, repeat approach yields nothing better than endless running in circles.

Love,
--Marcin

[erics_02_z06]

I am a little confused. For a given RPM (to look up the VE value), MAP, IAT, ECT, IFR, IPW, AFRwb, can't we solve for the correct correction factor using this equation? Can't we log all of these variable and then solve? I guess we would need to log g/cyl to know what bias is being used. But if we know the bias being used, and we know the AFR error, can't we relate an error in bias to the AFR error. Granted, other factors are causing error as well, but we are all assuming the bias is the primary cause.

so using something like 0 = GMVE*MAP/(TEMP*IFR*IPW), where Temp= 273+ IAT + (ECT-IAT)*Factor

Whe know everything but FACTOR. So we solve for Factor. We just need to know what g/cyl would relate to the cells we used. So we would need to log at large set of data for different g/cyl Actually, maybe I'm way off here, but it was a thought. I'll be honest, I don't even know what dynamic airflow is, so I could be way off....

[LinearX]

I am a little confused. For a given RPM (to look up the VE value), MAP, IAT, ECT, IFR, IPW, AFRwb, can't we solve for the correct correction factor using this equation? Can't we log all of these variable and then solve? I guess we would need to log g/cyl to know what bias is being used. But if we know the bias being used, and we know the AFR error, can't we relate an error in bias to the AFR error. Granted, other factors are causing error as well, but we are all assuming the bias is the primary cause.

One of the other factors that tends to get ignored is inherent noise in the system. The sensors are as precise as the OEM is willing to spend for, but there is still noise in the system that can and will affect the final values for GMVE.

so using something like 0 = GMVE*MAP/(TEMP*IFR*IPW), where Temp= 273+ IAT + (ECT-IAT)*Factor

Whe know everything but FACTOR. So we solve for Factor. We just need to know what g/cyl would relate to the cells we used. So we would need to log at large set of data for different g/cyl Actually, maybe I'm way off here, but it was a thought. I'll be honest, I don't even know what dynamic airflow is, so I could be way off....

There is a reason that setting the entire formula to zero will not work. You have to variables to solve for, not just one. You'd have to solve for GMVE and Factor. The problem is that those two variables are in a circular relationship.

If you look at the Bias table, the value is based on airflow, which is determined by GMVE. The equation for solving for GMVE includes TEMP, which is ultimately determined by the bias factor.

Now, if you choose to set Factor or GMVE to one value to solve for the other, then all you're doing is pushing all of the error correction to one table or the other.

[nikon1999]

And a solution for us with a 98/99? Just upgrade our os?

[erics_02_z06]

so GMVE isn't just the VE value from our tables for a given map and RPM? Also, I have an 02 z06 to make sure we are all on the same page.

[erics_02_z06]

Now, if you choose to set Factor or GMVE to one value to solve for the other, then all you're doing is pushing all of the error correction to one table or the other.

Ok, if we do choose to assume our VE is correct (when we know its not becuase it was tuned with the charge temp for a certain set of conditions), what is the consequence of putting all of the responsibility of correction on the Bias table? Will it not work? Not work well?

[redhardsupra]

I am a little confused. For a given RPM (to look up the VE value), MAP, IAT, ECT, IFR, IPW, AFRwb, can't we solve for the correct correction factor using this equation?

If you want to isolate TEMP, then expand it to the BIAS factor containing form, and then solve for BIAS be me guest. However, just to give you a preview of what's gonna happen:
1. you will have a huge discrepancies in your BIAS numbers
2. to figure out what function would the BIAS curve from the table take on, if you're smart, you'll go with an exponential decay formula, and then you'll realize you have 3 curve-describing parameters to solve for, instead of 1 that you had initially, making it harder not easier comparing to what you've started with
3. if you figure out how to solve that (good luck, that takes some serious math intuition) you are still screwed preemptively because you did this:

Granted, other factors are causing error as well, but we are all assuming the bias is the primary cause.

so using something like 0 = GMVE*MAP/(TEMP*IFR*IPW), where Temp= 273+ IAT + (ECT-IAT)*Factor

I'm not sure how you arrived at this, just at the first glance, you've completely lost AFRwb somewhere. Then in order to end up with a 0 on one end you must subtract the entire 'airmass from fuel' part, and you have no subtraction, but you have division, so that means you're not supposed to have zero but one on the left side.

This is nothing new, I've beaten this to death 3 yrs ago. there's plenty of reading material on it:
http://redhardsupra.blogspot.com/200...-modeling.html
http://redhardsupra.blogspot.com/200...ng-part-2.html
http://redhardsupra.blogspot.com/200...important.html
http://redhardsupra.blogspot.com/200...ss-models.html

there's no need to waste your time on stuff i've wasted my time on. happy reading!

[Bluecat]

Whe know everything but FACTOR. So we solve for Factor.

That's not true, we don't know everything but the factor. Any VE number that your using is bad data because even if you tuned it to that number, you tuned it with a incorrect bias table.

It's just not that simple, and thats why we all always argue about this. Trying to look at it as a formula with two unknowns, RHS is right. There is no solution. But that is the same reason no one came up with a good answer to the equation ve stuff trying to beat it with stait up math.

The same issue resides in both the bias and the equation ve. At any givin point, there are multiple unknown variables that prevent you from simply solving. But in both cases all the variables relate to each other. If you don't look at trying to fit just one point but an entire data set, there is an answer that fits the data set with the least amount of error over the largest range.

It is solvable like this. Take a large enough data set, hopefully from many logs from many different conditions. For every data point we know after applying the afr error, that to make the command afr match the observed afr the end result of the all the math needs to be X g/cly (CAM)

For every frame of every log we know the IAT, ECT, RPM, MAP, and what the CAM should have been for that frame to make the command afr match the observed afr. Then its a matter of what GMVE and MAT (read Bias table) make for the best fit over the whole data set.

I can't solve that with math the correct way. Somewhere, some simultanious equation math guru stud probally can. I can't, and apparently anyone else that has looked at the problem can't.

But I can do it like I did the eq ve and beat it to death with raw hp, er ghz anyway. What soundengineer was doing by hand was exactly what my eq program does. Make a change, reevalutate, make another change... Its ugly, very ugly from a math stand point but it works.

And this is way simpler that the eqve stuff, there is only one variable to step up and down is the bias. The ve table is what is generated to test for average error.

Example: Lets say the data set had 50 frames that where all at 50kpa/2000rpm. Start with any bias number and solve for GMVE. Compare the results and you can get an % error for that point in the ve table. Now move the bias number up or down a little and solve for gmve again. Did the % error get better or worse? the result will tell you to move the bias the other way, or keep stepping the way your going. Slow and painfull. But with the computer doing the work, the right program can spit out a ve and bias table that is the best fit for the data set in 30 seconds or less.

Now I know what RHS's complaits will be. 1. Where you look up in the bias table (the g/sec) changes if you change the gmve number. And he'd be right. Another reason solving it math wise causes brain cramps. But as longs as your making small steps in the bias numbers, over thousands of recompares it will just filter that problem out. 2. Injector numbers such as the offset/spa effect the over all accarcy and hence the results. Again he'd be correct. But we'll never be perfect 100% all of the time, not possible. But the realization of that shouldn't keep us from make a solution that is as close as we can get it.

All this talking about it has got me wound up. I don't have the time to spend on this, but I may write a program to do this over the next little bit just to prove it can be done.

[redhardsupra]

Ok, if we do choose to assume our VE is correct (when we know its not becuase it was tuned with the charge temp for a certain set of conditions), what is the consequence of putting all of the responsibility of correction on the Bias table? Will it not work? Not work well?

this is the problem of dumping ALL responsibility in ONE table. it is functionally not any different from IFR hacks, or PE hacks. I'd like to avoid these sort of approaches like the plague.

[LinearX]

Ok, if we do choose to assume our VE is correct (when we know its not becuase it was tuned with the charge temp for a certain set of conditions), what is the consequence of putting all of the responsibility of correction on the Bias table? Will it not work? Not work well?

If you want to do that, you can save yourself a lot of heartache by disabling the complex modeling for temp and just let the ECM use IAT for its TEMP value.

[redhardsupra]

If you want to do that, you can save yourself a lot of heartache by disabling the complex modeling for temp and just let the ECM use IAT for its TEMP value.

go ahead, Ford'ize your Z06, let's see how dirty you'll feel

[Bluecat]

go ahead, Ford'ize your Z06, let's see how dirty you'll feel

Lol

[LinearX]

go ahead, Ford'ize your Z06, let's see how dirty you'll feel

Hell naw! I still want the "Tuned with Matlab" sticker on my car!

[Higgs Boson]

If you want to do that, you can save yourself a lot of heartache by disabling the complex modeling for temp and just let the ECM use IAT for its TEMP value.

Would that be the same as moving the numbers to 0?

[erics_02_z06]

That's not true, we don't know everything but the factor. Any VE number that your using is bad data because even if you tuned it to that number, you tuned it with a incorrect bias table.

yeah, I realized that driving to work today. So the pragmatic solution is that we just tune for say 85 ambient, when we actually drive in the range of 70-100, hopefully our swings wont be from 0-7 they will be -3.5 - +3.5 ( I know it won't be so linear, but better than nothing). So, I guess I am saying we should zero our Ve's at a moderate temp (most of us tune our ve's when life allows, so its at night, or middle of the day on a weekend) .

[erics_02_z06]

I'm not sure how you arrived at this, just at the first glance, you've completely lost AFRwb somewhere. Then in order to end up with a 0 on one end you must subtract the entire 'airmass from fuel' part, and you have no subtraction, but you have division, so that means you're not supposed to have zero but one on the left side.

I screwed up, I thought AFRwb was error for some reason

Ok, I won't wast my time. I want to read the links, but I have a ton to do at work today....

But here is the thing...if there is a solution, but its just hard to arrive at...we can use matlab

I used this all the time to solve under determined systems (or what ever they are called) when I was in school. It was solving for 3-4 unknowns at once in heat transfer problems I was working on ( I have an engineering degree, but sound like an idiot becuase I ditched engineering years ago for sales )
http://www.mathworks.com/access/help...qcurvefit.html


Anyways, I bet I'm still pretty handy in matlab...so I'll make a trade, you take the time to call me and write me emails explaining what needs to be solved, and I'll set up a routine in matlab to see if we can tackle this....any takers?