Disassembly question
But tell her that you have to make a post on EvoM with some data first. 
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
I finally obtained a log. See below. The "airflow" value is nearly flat across the entire WOT pull for a wide range of MAF Hz values. I think I may have been wrong about the output value on the "MAF scaling" table. Instead of it being an "airflow rate" value, I think it is some sort of "airflow per unit something". I suspect the something is Hz, but I suppose could be RPM. Seems more likely to be Hz.
This means that the actual airflow calculation is done somewhere else in the code that we have not seen.
This means that the actual airflow calculation is done somewhere else in the code that we have not seen.
That blue line that you call 2-byte airflow in the legend is the 2-byte of that variable that we have been talking about? The 2-byte of Mut 28?
If so, that sucks....there has to be a variable somewhere that has the full resolution for mass airflow. The ECU has to be calculating it for fueling, for one. I know the ECU has a variable for logging over OBD for mass airflow.
About the MAF scaling table, it is my understanding that it is Hz versus L/Hz. The curve is the L/Hz calibration for the MAF.
Eric
If so, that sucks....there has to be a variable somewhere that has the full resolution for mass airflow. The ECU has to be calculating it for fueling, for one. I know the ECU has a variable for logging over OBD for mass airflow.
About the MAF scaling table, it is my understanding that it is Hz versus L/Hz. The curve is the L/Hz calibration for the MAF.
Eric
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
That blue line that you call 2-byte airflow in the legend is the 2-byte of that variable that we have been talking about? The 2-byte of Mut 28?
If so, that sucks....there has to be a variable somewhere that has the full resolution for mass airflow. The ECU has to be calculating it for fueling, for one. I know the ECU has a variable for logging over OBD-II for mass airflow.
About the MAF scaling table, it is my understanding that it is Hz versus L/Hz. The curve is the L/Hz calibration for the MAF.
Eric
If so, that sucks....there has to be a variable somewhere that has the full resolution for mass airflow. The ECU has to be calculating it for fueling, for one. I know the ECU has a variable for logging over OBD-II for mass airflow.
About the MAF scaling table, it is my understanding that it is Hz versus L/Hz. The curve is the L/Hz calibration for the MAF.
Eric
L/Hz makes sense. There must be another subroutine where L/Hz is multiplied by Hz (and probably some other factors) L/s.
Interesting about the ODB-II mass airflow. Might be a good way to look for the correct subroutine.
Yeah, but according to tephra and Bez, trying to disassemble the OBD routines is near impossible. I just asked about it again in the AktiveMatrix thread about it.
But, yes, using OBD as a logging protocol through LogWorks or any OBD logger/scanner, you can log mass airflow in g/s. The conversion is x*.01, so I am assuming that the max is around 650 g/s, which is over 85 lb/min, well beyond what we would ever need. I used this when I was correlating load to a g/rev value. So, I know the ECU has it somewhere.
Eric
But, yes, using OBD as a logging protocol through LogWorks or any OBD logger/scanner, you can log mass airflow in g/s. The conversion is x*.01, so I am assuming that the max is around 650 g/s, which is over 85 lb/min, well beyond what we would ever need. I used this when I was correlating load to a g/rev value. So, I know the ECU has it somewhere.
Eric
Looking at your graph more, I see that you got the same result logging 2-byte as I did from just logging the 1-byte MUT 28. That variable clips at the same point as load hits 160, where the 1-byte load would clip.
Maybe the ECU is just calculating mass airflow all from the load variables (g/rev) and myultiply by RPM somewhere to get a mass airflow per time, if needed.
Eric
Maybe the ECU is just calculating mass airflow all from the load variables (g/rev) and myultiply by RPM somewhere to get a mass airflow per time, if needed.
Eric
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
Looking at your graph more, I see that you got the same result logging 2-byte as I did from just logging the 1-byte MUT 28. That variable clips at the same point as load hits 160, where the 1-byte load would clip.
Maybe the ECU is just calculating mass airflow all from the load variables (g/rev) and myultiply by RPM somewhere to get a mass airflow per time, if needed.
Eric
Maybe the ECU is just calculating mass airflow all from the load variables (g/rev) and myultiply by RPM somewhere to get a mass airflow per time, if needed.
Eric
Yeah, you're right. I'll have to go back over my MAF scaling spreadsheet to see if my calculations of mass airflow from MAF Hz matches this routine at all. Maybe we are looking at the wrong variable in this code or this just isn't the right routine.
After all, if you have an airflow in Hz (like our 2-byte airflow) and multiply it by the respective L/Hz value (our maf scaling), then you now have a L/s value. Notice that the fact that the Maf scaling only goes to 1610 Hz doesn't matter, since the 2-byte Hz is still climbing...it simply uses the last L/Hz value from the maf scaling table. That's our volumetric airflow per time. Now, all we need to do is multiply that by air density, which can be found from baro and ait from PV=nRT. If you use units of g/L for your air density, then when you multiply g/L by L/s, then you have g/s. That's the mass airflow that we are looking for.
Since I'm not that good with disassembly, even though you commented, is this what this part of code looks like it is doing? I'll look over your comments again and see if I can make sense of it again.
There should be:
1. 2-byte airflow (Hz) mutliplied by corresponding maf scaling value (L/Hz) (last value if over 1610 Hz) --> L/s
2. This L/s value multiplied by air density (g/L) --> g/s
Eric
After all, if you have an airflow in Hz (like our 2-byte airflow) and multiply it by the respective L/Hz value (our maf scaling), then you now have a L/s value. Notice that the fact that the Maf scaling only goes to 1610 Hz doesn't matter, since the 2-byte Hz is still climbing...it simply uses the last L/Hz value from the maf scaling table. That's our volumetric airflow per time. Now, all we need to do is multiply that by air density, which can be found from baro and ait from PV=nRT. If you use units of g/L for your air density, then when you multiply g/L by L/s, then you have g/s. That's the mass airflow that we are looking for.
Since I'm not that good with disassembly, even though you commented, is this what this part of code looks like it is doing? I'll look over your comments again and see if I can make sense of it again.
There should be:
1. 2-byte airflow (Hz) mutliplied by corresponding maf scaling value (L/Hz) (last value if over 1610 Hz) --> L/s
2. This L/s value multiplied by air density (g/L) --> g/s
Eric
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
#1 in your list is definitely not performed.
#2 in your list may be performed. There is some sort of correction applied to the L/Hz value based on barometric pressure and intake air temp.
Somewhere further along in the code, the base injector pulse (final RAM variable in the subroutine) must get multiplied by MAF Hz (or something like that). I looked briefly last night for something like that, but didn't have time to put a real effort into it.
#2 in your list may be performed. There is some sort of correction applied to the L/Hz value based on barometric pressure and intake air temp.
Somewhere further along in the code, the base injector pulse (final RAM variable in the subroutine) must get multiplied by MAF Hz (or something like that). I looked briefly last night for something like that, but didn't have time to put a real effort into it.
mrfred,
Do you know what I think this is? I think that variable is correcting the maf scaling table from L/Hz to g/Hz. So, the mass airflow is just that variable multiplied by the 2-byte Hz. So, if you see something that has that variable being multiplied by the 2-byte airflow, that would be what I am looking for.
Does this make any sense?
Eric
Do you know what I think this is? I think that variable is correcting the maf scaling table from L/Hz to g/Hz. So, the mass airflow is just that variable multiplied by the 2-byte Hz. So, if you see something that has that variable being multiplied by the 2-byte airflow, that would be what I am looking for.
Does this make any sense?
Eric
Last edited by l2r99gst; Apr 10, 2008 at 08:06 AM.
Yeah, I'm pretty sure that is what happening. If I look at your comments:
This is taking the maf scaling and addind the maf adder (140 decimal...I mentioned this in the maf scaling thread), multiplying the maf compensation that you found and multiplying by air density that it calculated/looked up from the tables you found.
So, that variable that you are calling corrected_airflow seems to be a correction to the maf scaling values to change them from L/hz to g/Hz. I don't see this being multiplied back by 2-byte Hz anywhere to get g/s, but who knows where the ECU is doing all the rest of this. At then end, it looks like it uses the injector scaling, probably to get ready to calculate the mass of fuel needed.
So, if I am correct in this interpretation, then in your data that you logged, you should be able to multiply that logged variable (corrected_airflow) by your 2-byte Hz and get a mass airflow. If we can find a variable that has this done, we can elimitate this step, but that would be a good test to see if this is right.
Can you do me a favor and post the raw data that you logged from the chart above? You can send it in PM if you wish. I want to see how closely a graph of 2-byte airflow * this new variable (corrected_airflow) compares to my mass airflow calculations from load (2byte load/95*RPM/60).
Eric
Code:
ROM:00017F0E jsr @r10 ; sub_68A ; r4*r5/r6 -> r0 ROM:00017F10 nop ; (MAF_scale + 0x8C)*(MAF_comp*air_dens_corr)/0x4000 -> r0 ROM:00017F10 ; airflow_raw*MAF_comp*air_dens_corr/0x4000 -> r0 ROM:00017F10 ; corrected_airflow -> r0 ROM:00017F12 mov.l @(h'98,pc), r11 ; [00017FAC] = unk_FFFF6C74 ROM:00017F14 mov.w r0, @r11 ; corrected_airflow -> FFFF6C74
This is taking the maf scaling and addind the maf adder (140 decimal...I mentioned this in the maf scaling thread), multiplying the maf compensation that you found and multiplying by air density that it calculated/looked up from the tables you found.
So, that variable that you are calling corrected_airflow seems to be a correction to the maf scaling values to change them from L/hz to g/Hz. I don't see this being multiplied back by 2-byte Hz anywhere to get g/s, but who knows where the ECU is doing all the rest of this. At then end, it looks like it uses the injector scaling, probably to get ready to calculate the mass of fuel needed.
So, if I am correct in this interpretation, then in your data that you logged, you should be able to multiply that logged variable (corrected_airflow) by your 2-byte Hz and get a mass airflow. If we can find a variable that has this done, we can elimitate this step, but that would be a good test to see if this is right.
Can you do me a favor and post the raw data that you logged from the chart above? You can send it in PM if you wish. I want to see how closely a graph of 2-byte airflow * this new variable (corrected_airflow) compares to my mass airflow calculations from load (2byte load/95*RPM/60).
Eric
Last edited by l2r99gst; Apr 10, 2008 at 08:45 AM.
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
...
So, if I am correct in this interpretation, then in your data that you logged, you should be able to multiply that logged variable (corrected_airflow) by your 2-byte Hz and get a mass airflow. If we can find a variable that has this done, we can elimitate this step, but that would be a good test to see if this is right.
Can you do me a favor and post the raw data that you logged from the chart above? You can send it in PM if you wish. I want to see how closely a graph of 2-byte airflow * this new variable (corrected_airflow) compares to my mass airflow calculations from load (2byte load/95*RPM/60).
Eric
So, if I am correct in this interpretation, then in your data that you logged, you should be able to multiply that logged variable (corrected_airflow) by your 2-byte Hz and get a mass airflow. If we can find a variable that has this done, we can elimitate this step, but that would be a good test to see if this is right.
Can you do me a favor and post the raw data that you logged from the chart above? You can send it in PM if you wish. I want to see how closely a graph of 2-byte airflow * this new variable (corrected_airflow) compares to my mass airflow calculations from load (2byte load/95*RPM/60).
Eric
I'll attach the file here later today.
What's kinda screwy about this whole thing is that the MAF Hz variable we are looking at is calculated from load. Its exactly the opposite of what I expected, and it seems to me that somewhere in the code there has to be some calculation that generates load from the MAF signal. I'm getting a little of the subject here though.
What's kinda screwy about this whole thing is that the MAF Hz variable we are looking at is calculated from load. Its exactly the opposite of what I expected, and it seems to me that somewhere in the code there has to be some calculation that generates load from the MAF signal. I'm getting a little of the subject here though.
His post is as follows:
Posting tons of disassembly probably not a good idea here - but I'll try to clear things how it works.
1. Recorded MAF pulses per RPM period value..
2.Some smoothings done.
4.SOme filtering done (the value and the previous value are compared -if the difference too high the newly recoreded value is discarded)
5. The maximum allowed mafperrpm(RPM) got from table and compared to value that got. Trimmed if bigger. The result called MAF_SOURCE_MAIN in my disasms...
6. The first load is got by multiplying MAF_SOURCE_MAIN by mafsize (mafsize is available in ecuflash definitions -its actually engine's size).
Then the all LOADS got ....First is ~MAFHZ/RPM*mafsize.
Second ~MAF/RPM*mafsize*BAROMETR
Final Load ~MAF/RPM*mafsize*BAROMETR *Air_temp_density
Airtemp_density got from table based on MAF air tempetature readings.
In routines that gets timing values from table or fuel the procedure GET_LOAD is used wich selects load according on the sensor's functionality- if all ok the third load is used ....If air temperature sensor is down than the second load is used...
To get MAF_HZ, MAF_SOURCE MAIN is then back multiplied by RPM ..
Then Maf_filtering table is used , them maf smoothing , than maf (scaled and smoothed) is barometr and airtemp compensated and a value Air Mass is got (trimmed available through MUT 28)...
1. Recorded MAF pulses per RPM period value..
2.Some smoothings done.
4.SOme filtering done (the value and the previous value are compared -if the difference too high the newly recoreded value is discarded)
5. The maximum allowed mafperrpm(RPM) got from table and compared to value that got. Trimmed if bigger. The result called MAF_SOURCE_MAIN in my disasms...
6. The first load is got by multiplying MAF_SOURCE_MAIN by mafsize (mafsize is available in ecuflash definitions -its actually engine's size).
Then the all LOADS got ....First is ~MAFHZ/RPM*mafsize.
Second ~MAF/RPM*mafsize*BAROMETR
Final Load ~MAF/RPM*mafsize*BAROMETR *Air_temp_density
Airtemp_density got from table based on MAF air tempetature readings.
In routines that gets timing values from table or fuel the procedure GET_LOAD is used wich selects load according on the sensor's functionality- if all ok the third load is used ....If air temperature sensor is down than the second load is used...
To get MAF_HZ, MAF_SOURCE MAIN is then back multiplied by RPM ..
Then Maf_filtering table is used , them maf smoothing , than maf (scaled and smoothed) is barometr and airtemp compensated and a value Air Mass is got (trimmed available through MUT 28)...
I think maybe we need to look at the the disassembly section that Bez is referring here about load to find a variable with mass airflow already calculated.
Eric
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
I've looked at that same routine that Bez mentions where load is calced from MAF Hz. I was in agreement with Bez until I tried logging a few of the RAM variables in that subroutine to verify my understanding. None of the values matched up with what I was expecting based on Bez' interpretation. I'll have to take another look when I get a chance.
OK, cool. Let me know what you find when you get around to it.
I would imagine that it would follow basically what Bez is saying, though. I would imagine that it would be what I mentioned previously, but probably broken down to several steps. But, overall, there should be something that:
1. records maf sginal (Hz)
2. multiplies by the maf scaling and/or smoothing and/or compensation tables. This should result in a L/s value.
3. Then this value should be multiplied by an air density value. This value most should be found using baro and ait. This should result in mass airflow, g/s.
There may or may not be a variable that holds #3, though, since load, to my understanding is a g/rev value. So, load should be #3 divided by RPM.
From what Bez is saying, it looks like the MAF Hz are divided by RPM right away, so my #3 may not be in a variable. But, anyway, let me know what you find. I would be very interested.
Eric
I would imagine that it would follow basically what Bez is saying, though. I would imagine that it would be what I mentioned previously, but probably broken down to several steps. But, overall, there should be something that:
1. records maf sginal (Hz)
2. multiplies by the maf scaling and/or smoothing and/or compensation tables. This should result in a L/s value.
3. Then this value should be multiplied by an air density value. This value most should be found using baro and ait. This should result in mass airflow, g/s.
There may or may not be a variable that holds #3, though, since load, to my understanding is a g/rev value. So, load should be #3 divided by RPM.
From what Bez is saying, it looks like the MAF Hz are divided by RPM right away, so my #3 may not be in a variable. But, anyway, let me know what you find. I would be very interested.
Eric
Thread
Thread Starter
Forum
Replies
Last Post
jcsbanks
ECU Flash
9
Apr 23, 2009 07:25 AM
jcsbanks
ECU Flash
20
Feb 14, 2007 09:48 AM
