Dennis, I haven't forgotten about you. Just been pulled in all kinds of directions all week. Hard enough explaining all this to folks but I'm stuck trying to teach a guy in France who doesnt speak english as a first lamguage how to use this....
Printable View
Dennis, I haven't forgotten about you. Just been pulled in all kinds of directions all week. Hard enough explaining all this to folks but I'm stuck trying to teach a guy in France who doesnt speak english as a first lamguage how to use this....
No worries. I am nothing if not patient.
DG
I have to explain the difference between Mitsubishi version of air flow vs OBD2 definition of air mass. The ECU calculates both.
The tables you see listed above are what the ECU uses during the IPW calculation. This single sub has over 300 lines of code and there's still a chunk of it I don't understand. When I started typing this equation out in an email to you, I only got about 1/8th of the way thru it before I realized that's TMI.
What you are looking for is the ECUs interpretation of air mass or the OBD2 side of the equation which is much simpler to explain. I don't foresee any distractions tonight so let me get back into this when I'm home with my disassembly in front of me instead of going all out from memory.
The tricky part is, the ECU uses different levels of this calculation throuout the various table axises. Some use compensated load, some use uncomp load, some use the whole 2 byte word value, some get clipped and resolution expanded to fit into a 2 byte value... It's tricky. I'm guessing the one you care about is the load value used in the fuel and timing table axis correct?
Yeah. The calculation that gets me the load axis on any load based table - ignition and fuel for sure.
DG
Okay, finally at my computer.
The OBD2_Load (air mass) calculation starts with this.
Remember Air_Count is the MAF Pulses Per RPM.Quote:
Originally Posted by Greg E
Then there are the air density factors.
First it takes the barometric pressure compensation which is a single multiplier value. If barometric pressure is 100.45kpa, the multiplier is 1. As barometric pressure increases above that, the multiplier increases as well. Less pressure, the compensation value becomes a fraction. I don't know why they didn't code it as a table look up. Would have been simpler to code... Maybe this would be a great future Chrome Mod to give the user the ability to edit the baro comp.
Next, we have the Air Temp correction. This value is a table look up shown here.
http://i.imgur.com/gqAXN.jpg
Again, this is another multiplier value. From this table, if the AITs are 73 degF, the correction factor is 1.
So the final equation looks like this:
Load_OBD2 = (MAF Pulses Per Second/RPM) * MAF_Size * BaroComp * AITComp / 65536
That's basically it. The Load axis you see in the fuel and timing tables both use this air mass value.
That's it?
That seems awfully simple...
That's engine RPM right, not camshaft RPM?
Ok then... differences... AEM has a longer measurement window (4 cam revs, so 8 crank revs) but it could be shortened to 1 cam rev. So what? Need to think that through. Shorter window means faster response, less smoothing. May change max airflow the AEM can see. Can probably change VMAF_flow_max to bring it back then...
Hm. This is RPM based which means I can work out the actual time window vs RPM at the breakpoints... So what?
OEM compensates for temp and baro before becoming LOAD. So does AEM. Can probably duplicate the OEM comp tables in AEM. Breakpoints won't be the same but slope and intercept can be. It'll be interesting to see where that lines up.
The cell contents in the ignition map are just degrees advance in both systems so those should line up. What are the cell contents in the fuel map? Is it a straight injector pulsewidth or is there postprocessing?
Thanks a lot for this; this is going to open a whole bunch of doors (and pose almost as many questions)
DG
That it is. Show you the code. Very simple. :)
Some tables use uncompensated load. Most don't. I tried to label the ones that aren't in V2 in the table description.
Probably because anytime you have hard coded math it runs in less cpu cycles as opposed to math based upon lookup tables. My guess is that they hard coded the value everywhere it is used which would suggest Mitsu felt that this was very sensitive...Quote:
Originally Posted by Greg E
Maybe.Quote:
Originally Posted by 99 vr4
More opt to believe they did this because the baro sensor is the same in all their cars and the AIT sensors vary. They coded a table lookup so it could be edited for the various types of AIT sensors.
Yeah what he said... LolQuote:
Originally Posted by Greg E
But... What if they had to change the baro sensor due to an unforseen issue...
Normally when programming, you would define a library of static variables for these types of things. But for highly sensitive calculations, you hard code values in the math due to cpu cycle overhead. The pro is less cpu overhead and faster calculations. The con is IF it changes, you have to touch more code. Normally accepted code protocol dictates that UNLESS you need the speed OR you don't have the ROM space, you ALWAYS define a static variable. This would translate vis the compiler in machine code to a 1d lookup, normally an address space like the ROM calibration ID.
The one thing I have learned about Mitsubishi code is that they do everything for a highly calculated reason. Very much ISO 9000. If a value is used more than once in a different area of code, they would have defined a static, unless something else dictates otherwise. These are not super fast CPU's, and code optimization tests may have determined that this was one area that a small change had a large effect.