94170015 MAP to MAF Patch:
Jan 21, 2009, 12:15 PM
#91
Evolved Member
iTrader: (22)
Join Date: Nov 2003
Location: Northern KY near Cincy
Posts: 2,408
Likes: 0
Received 6 Likes
on
6 Posts
I went throughthe scalings and found a couple errors on the linear MAP calcs. I think it was just a typo.
I also decided to recalculate the VE table. From my limited understanding of this table the curve should be raising rate.
With these changes drivability did improve but I am still getting way rich at a coast to stop. The ECU does recover much faster though. I think I am moving in the right direction.
I also decided to recalculate the VE table. From my limited understanding of this table the curve should be raising rate.
With these changes drivability did improve but I am still getting way rich at a coast to stop. The ECU does recover much faster though. I think I am moving in the right direction.
Jan 21, 2009, 02:27 PM
#92
I went throughthe scalings and found a couple errors on the linear MAP calcs. I think it was just a typo.
I also decided to recalculate the VE table. From my limited understanding of this table the curve should be raising rate.
With these changes drivability did improve but I am still getting way rich at a coast to stop. The ECU does recover much faster though. I think I am moving in the right direction.
I also decided to recalculate the VE table. From my limited understanding of this table the curve should be raising rate.
With these changes drivability did improve but I am still getting way rich at a coast to stop. The ECU does recover much faster though. I think I am moving in the right direction.
can you repost the values. its blurry!
Jan 22, 2009, 05:35 AM
#93
Evolved Member
iTrader: (22)
Join Date: Nov 2003
Location: Northern KY near Cincy
Posts: 2,408
Likes: 0
Received 6 Likes
on
6 Posts
MAP Calibration
0 0.3125 0.625 0.9375 1.25 1.5625 1.875 2.5 2.8125 3.125 3.4375 3.75 4.0625 4.375 4.6875 4.88281 4.98047
0 17 34 51 68 85 102 119 136 153 170 187 204 221 234 255 255
VE
0 773.438 800.781 824.219 851.562 875 898.438 824.219 949.219 976.562 1000 1023.44 1050.78 1074.22 1101.56 1148.44 8000
0 45 65 83 102 119 135 151 166 181 196 211 223 236 247 255 255
0 0.3125 0.625 0.9375 1.25 1.5625 1.875 2.5 2.8125 3.125 3.4375 3.75 4.0625 4.375 4.6875 4.88281 4.98047
0 17 34 51 68 85 102 119 136 153 170 187 204 221 234 255 255
VE
0 773.438 800.781 824.219 851.562 875 898.438 824.219 949.219 976.562 1000 1023.44 1050.78 1074.22 1101.56 1148.44 8000
0 45 65 83 102 119 135 151 166 181 196 211 223 236 247 255 255
Jan 22, 2009, 10:10 AM
#94
MAP Calibration
0 0.3125 0.625 0.9375 1.25 1.5625 1.875 2.5 2.8125 3.125 3.4375 3.75 4.0625 4.375 4.6875 4.88281 4.98047
0 17 34 51 68 85 102 119 136 153 170 187 204 221 234 255 255
VE
0 773.438 800.781 824.219 851.562 875 898.438 824.219 949.219 976.562 1000 1023.44 1050.78 1074.22 1101.56 1148.44 8000
0 45 65 83 102 119 135 151 166 181 196 211 223 236 247 255 255
0 0.3125 0.625 0.9375 1.25 1.5625 1.875 2.5 2.8125 3.125 3.4375 3.75 4.0625 4.375 4.6875 4.88281 4.98047
0 17 34 51 68 85 102 119 136 153 170 187 204 221 234 255 255
VE
0 773.438 800.781 824.219 851.562 875 898.438 824.219 949.219 976.562 1000 1023.44 1050.78 1074.22 1101.56 1148.44 8000
0 45 65 83 102 119 135 151 166 181 196 211 223 236 247 255 255
patch your rom's MUT table with 898c in MUT 08 and 898d in MUT 09, 8984 in MUT 0a and 8985 in MUT 0b. remember the old data/backup your rom if you want to change back/will not affect drivability.
throw this into the data.xml file in evoscan.
Code:
<DataListItem DataLog="N" Color="" Display="MAP EMULATED MAF" LogReference="MAP EMULATED MAF" RequestID="08"
RequestID2="09" Eval="6.29*x/64" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255"
ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
<DataListItem DataLog="N" Color="" Display="MAF2" LogReference="MAF2" RequestID="0a"
RequestID2="0b" Eval="6.29*x/64" Unit="unit" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="255"
ChartMin="0" ChartMax="255" ScalingFactor="1" Notes="" Priority="1" Visible="False" />
Jan 22, 2009, 10:36 AM
#95
My car has been working pretty damn good with the patch. I do go a little rich when initially idling down, and do still get lean idling blips from time to time but all and all at least it doesn't stall at every stop sign and light.
Still trying to understand the logging and where adjustin is best. Right now i'm just using evoredy's settings
Still trying to understand the logging and where adjustin is best. Right now i'm just using evoredy's settings
Jan 22, 2009, 09:04 PM
#96
Evolved Member
iTrader: (22)
Join Date: Nov 2003
Location: Northern KY near Cincy
Posts: 2,408
Likes: 0
Received 6 Likes
on
6 Posts
[QUOTE=evoredy;6599751]how are the logs coming? are you understanding how the logging takes place and what to look for? do you even care lol?QUOTE]
I have been logging as much as I can. Mostly though I have been watching my Zt2 and AVC-R RPM and Boost/Vacuum to monitor what is going on.
Thank you for giving me the much needed logging parameters for this patch. I am certain I will put it to great use. Stay tuned to get the results.
I have been logging as much as I can. Mostly though I have been watching my Zt2 and AVC-R RPM and Boost/Vacuum to monitor what is going on.
Thank you for giving me the much needed logging parameters for this patch. I am certain I will put it to great use. Stay tuned to get the results.
Jan 22, 2009, 10:07 PM
#98
Evolved Member
iTrader: (22)
Join Date: Nov 2003
Location: Northern KY near Cincy
Posts: 2,408
Likes: 0
Received 6 Likes
on
6 Posts
With my resolutions set where they are I am using the MAF for anyything over my base idle setting so an alarm isn't necessary. My goal with this patch is to stabilize my idle first, then I can focus on full SD.
I just need to get the thing to stop going to 10 AFR and wanting to stall on coast down.
It seems that as I add more to the VE units the better my idle becomes and the faster it stabilizes.
Jan 22, 2009, 10:18 PM
#99
With my resolutions set where they are I am using the MAF for anyything over my base idle setting so an alarm isn't necessary. My goal with this patch is to stabilize my idle first, then I can focus on full SD.
I just need to get the thing to stop going to 10 AFR and wanting to stall on coast down.
It seems that as I add more to the VE units the better my idle becomes and the faster it stabilizes.
I just need to get the thing to stop going to 10 AFR and wanting to stall on coast down.
It seems that as I add more to the VE units the better my idle becomes and the faster it stabilizes.
you can raise the offset and that will change how your VE table affects the MAF EMULATED value. lowering the value does the same, but i have noticed the MAF EMULATED value goes to 0 at 14PSI! this means fuel basically gets shut off and you go uber lean. i think its some kind of overflow or map/mdp/usdm/etc. cal issue. watch out for that when doing offset mods. watch out for it when raising the offset too, but i don't think it happens when you do that.
i tested the values from 0 to 4096 and 128 was a happy medium.
Jan 26, 2009, 07:48 AM
#100
Evolved Member
iTrader: (22)
Join Date: Nov 2003
Location: Northern KY near Cincy
Posts: 2,408
Likes: 0
Received 6 Likes
on
6 Posts
I have hit a point of diminished returns on the VE table when used for IDLE only.
I tested this by raising, testing, raising, testing etc. To get back to a idle to stall condition. I have determined that the curve for the VE table cannot be straight inctrasing from 0 to 255.
The curve actually needs to be more like a sideways "S" with the lower portion, i.e. 0 to about 900, needs to be a low increasing rate curve with valuse for VE below 100. Between the 850 and 975 the curve increases fast with VE values going from 48 to 170. Then curve slows to nearly horizontal from 975 to 1100 with VE values going from 170 to 255 at 1150 RPM.
My idle is set at 1000 RPM.
I also noticed that the MAFEMULATED values are only hitting 220 on a full throttle pull. Shouldn't they hit 255 to show that the regular MAF is being used? With that being said the MAF usually peaks out at about 14PSI so how can the MAFEMULATED ever be accurate on WOT pulls?
I also noticed that WOT pulls have lowered my AFR by nearly a full point in the +5K RPM range. This should not be happening if the MAFEMULATED were cottectly shutting down allowing only the true MAF to operate.
Where to go from here? ? ? ?
I tested this by raising, testing, raising, testing etc. To get back to a idle to stall condition. I have determined that the curve for the VE table cannot be straight inctrasing from 0 to 255.
The curve actually needs to be more like a sideways "S" with the lower portion, i.e. 0 to about 900, needs to be a low increasing rate curve with valuse for VE below 100. Between the 850 and 975 the curve increases fast with VE values going from 48 to 170. Then curve slows to nearly horizontal from 975 to 1100 with VE values going from 170 to 255 at 1150 RPM.
My idle is set at 1000 RPM.
I also noticed that the MAFEMULATED values are only hitting 220 on a full throttle pull. Shouldn't they hit 255 to show that the regular MAF is being used? With that being said the MAF usually peaks out at about 14PSI so how can the MAFEMULATED ever be accurate on WOT pulls?
I also noticed that WOT pulls have lowered my AFR by nearly a full point in the +5K RPM range. This should not be happening if the MAFEMULATED were cottectly shutting down allowing only the true MAF to operate.
Where to go from here? ? ? ?
Jan 26, 2009, 05:13 PM
#101
I have hit a point of diminished returns on the VE table when used for IDLE only.
I tested this by raising, testing, raising, testing etc. To get back to a idle to stall condition. I have determined that the curve for the VE table cannot be straight inctrasing from 0 to 255.
The curve actually needs to be more like a sideways "S" with the lower portion, i.e. 0 to about 900, needs to be a low increasing rate curve with valuse for VE below 100. Between the 850 and 975 the curve increases fast with VE values going from 48 to 170. Then curve slows to nearly horizontal from 975 to 1100 with VE values going from 170 to 255 at 1150 RPM.
My idle is set at 1000 RPM.
I also noticed that the MAFEMULATED values are only hitting 220 on a full throttle pull. Shouldn't they hit 255 to show that the regular MAF is being used? With that being said the MAF usually peaks out at about 14PSI so how can the MAFEMULATED ever be accurate on WOT pulls?
I also noticed that WOT pulls have lowered my AFR by nearly a full point in the +5K RPM range. This should not be happening if the MAFEMULATED were cottectly shutting down allowing only the true MAF to operate.
Where to go from here? ? ? ?
I tested this by raising, testing, raising, testing etc. To get back to a idle to stall condition. I have determined that the curve for the VE table cannot be straight inctrasing from 0 to 255.
The curve actually needs to be more like a sideways "S" with the lower portion, i.e. 0 to about 900, needs to be a low increasing rate curve with valuse for VE below 100. Between the 850 and 975 the curve increases fast with VE values going from 48 to 170. Then curve slows to nearly horizontal from 975 to 1100 with VE values going from 170 to 255 at 1150 RPM.
My idle is set at 1000 RPM.
I also noticed that the MAFEMULATED values are only hitting 220 on a full throttle pull. Shouldn't they hit 255 to show that the regular MAF is being used? With that being said the MAF usually peaks out at about 14PSI so how can the MAFEMULATED ever be accurate on WOT pulls?
I also noticed that WOT pulls have lowered my AFR by nearly a full point in the +5K RPM range. This should not be happening if the MAFEMULATED were cottectly shutting down allowing only the true MAF to operate.
Where to go from here? ? ? ?
have you logged the 2-byte values correctly? what's your evoscan scaling...nothing? do you have a 3bar? you aboslutely cannot use the stock 1bar for anything over a few psi for safety's sake.
the offset i have chosen is most compatible and safe for our stock 1bar map sensor. it may need to be lowered to get the numbers you want.
Jan 28, 2009, 09:47 PM
#102
Evolved Member
iTrader: (22)
Join Date: Nov 2003
Location: Northern KY near Cincy
Posts: 2,408
Likes: 0
Received 6 Likes
on
6 Posts
I found something very interesting.....
In the "Lean Spool Trailing Time" tables the RPM values exactly match whatever value I put in the VE MAP to MAF table RPM values.
Could this be causing an issue?
In the "Lean Spool Trailing Time" tables the RPM values exactly match whatever value I put in the VE MAP to MAF table RPM values.
Could this be causing an issue?
Feb 1, 2009, 02:47 PM
#103
Evoredy,
Interestingly, under low throttle and manifold pressure conditions, when you've just come from a high load to a low throttle, low RPM, low MAP situation, the ECU limits engine load based on a speed density lookup. It isn't a strong effect which is probably why I have problems with MAF over-reads on lift off, and why big turbo people can struggle also. The speed density lookup does use the MAP calibration table you're using.
For conversion to full speed density I think you'd need to do very little (if you had a MAP rather than MDP) to get to what mixmastermatt/Tuner@Swift had (rather than limit MAFSOURCEMAIN to your speed density variable you have to make it equal - just adding one nop will do that. However, in that code they also need to nop an instruction to force MAFSOURCEMAINxMAFMULTIPWARMUP to be set to the limit value that is also calculated in one of the routines you're changing (they haven't done this, but it will cause a miscalculation otherwise as it will still use MAF info if it is plugged in and go to default values based on baro, RPM and air temp if not plugged in. Studying VE from my logs I think you could calibrate the full engine range using the MAP calibration and the MAF Hz scaling curve.
Interestingly, under low throttle and manifold pressure conditions, when you've just come from a high load to a low throttle, low RPM, low MAP situation, the ECU limits engine load based on a speed density lookup. It isn't a strong effect which is probably why I have problems with MAF over-reads on lift off, and why big turbo people can struggle also. The speed density lookup does use the MAP calibration table you're using.
For conversion to full speed density I think you'd need to do very little (if you had a MAP rather than MDP) to get to what mixmastermatt/Tuner@Swift had (rather than limit MAFSOURCEMAIN to your speed density variable you have to make it equal - just adding one nop will do that. However, in that code they also need to nop an instruction to force MAFSOURCEMAINxMAFMULTIPWARMUP to be set to the limit value that is also calculated in one of the routines you're changing (they haven't done this, but it will cause a miscalculation otherwise as it will still use MAF info if it is plugged in and go to default values based on baro, RPM and air temp if not plugged in. Studying VE from my logs I think you could calibrate the full engine range using the MAP calibration and the MAF Hz scaling curve.
Last edited by jcsbanks; Feb 1, 2009 at 02:50 PM.
Feb 1, 2009, 09:03 PM
#104
Evoredy,
Interestingly, under low throttle and manifold pressure conditions, when you've just come from a high load to a low throttle, low RPM, low MAP situation, the ECU limits engine load based on a speed density lookup. It isn't a strong effect which is probably why I have problems with MAF over-reads on lift off, and why big turbo people can struggle also. The speed density lookup does use the MAP calibration table you're using.
For conversion to full speed density I think you'd need to do very little (if you had a MAP rather than MDP) to get to what mixmastermatt/Tuner@Swift had (rather than limit MAFSOURCEMAIN to your speed density variable you have to make it equal - just adding one nop will do that. However, in that code they also need to nop an instruction to force MAFSOURCEMAINxMAFMULTIPWARMUP to be set to the limit value that is also calculated in one of the routines you're changing (they haven't done this, but it will cause a miscalculation otherwise as it will still use MAF info if it is plugged in and go to default values based on baro, RPM and air temp if not plugged in. Studying VE from my logs I think you could calibrate the full engine range using the MAP calibration and the MAF Hz scaling curve.
Interestingly, under low throttle and manifold pressure conditions, when you've just come from a high load to a low throttle, low RPM, low MAP situation, the ECU limits engine load based on a speed density lookup. It isn't a strong effect which is probably why I have problems with MAF over-reads on lift off, and why big turbo people can struggle also. The speed density lookup does use the MAP calibration table you're using.
For conversion to full speed density I think you'd need to do very little (if you had a MAP rather than MDP) to get to what mixmastermatt/Tuner@Swift had (rather than limit MAFSOURCEMAIN to your speed density variable you have to make it equal - just adding one nop will do that. However, in that code they also need to nop an instruction to force MAFSOURCEMAINxMAFMULTIPWARMUP to be set to the limit value that is also calculated in one of the routines you're changing (they haven't done this, but it will cause a miscalculation otherwise as it will still use MAF info if it is plugged in and go to default values based on baro, RPM and air temp if not plugged in. Studying VE from my logs I think you could calibrate the full engine range using the MAP calibration and the MAF Hz scaling curve.
yes you are right about the sensor and funny that you should post this. i have been limited with the 1bar for a while though until now. over this weekend, i installed the motorola/freescale mpxh6400 4bar map sensor in the the stock MDP/MAP housing/o-ring sealed the nozzle and filled the sucker with JBweld/and wired it (like the omnipower guys lol)and i think i got the scaling right in evoscan based on some posts on other forums: 0.23496*x-14.5 / seems close according to my boost gauge at least. it still needs work/high boost test.
the idle control has gotten amazing and now i have lots of room to play around with. i'll mod the code and see what happens/are you talking about the 1132A and 11356 areas? i'm rusty on sh2 code as i haven't read the manual lol/when i get time i'll read. this patch seems like option b on the other SD thread right? or was that a/whatever lol. i finally got my diff in and am driving again thank god.
94170015:
Code:
ROM:000112DC ; =============== S U B R O U T I N E ======================================= ROM:000112DC ROM:000112DC ; Attributes: noreturn ROM:000112DC ROM:000112DC mafsource_2: ; CODE XREF: maf_related+6p ROM:000112DC sts.l pr, @-r15 ROM:000112DE mov.l r14, @-r15 ROM:000112E0 mov r15, r14 ROM:000112E2 mov.l r1, @-r15 ROM:000112E4 mov.l r2, @-r15 ROM:000112E6 mov.l r8, @-r15 ROM:000112E8 mov.l @(h'CC,pc), r4 ; [000113B8] = rpm_axis ROM:000112EA mov.l @(h'C8,pc), r10 ; [000113B4] = preptable ROM:000112EC jsr @r10 ; preptable ROM:000112EE nop ROM:000112F0 mov.l @(h'C8,pc), r4 ; [000113BC] = ve_table ROM:000112F2 mov.l @(h'D0,pc), r10 ; [000113C4] = tablemable ROM:000112F4 jsr @r10 ; tablemable ROM:000112F6 nop ROM:000112F8 extu.w r0, r1 ROM:000112FA nop ROM:000112FC nop ROM:000112FE mov.l @(h'C0,pc), r4 ; [000113C0] = map_axis ROM:00011300 mov.l @(h'B0,pc), r10 ; [000113B4] = preptable ROM:00011302 jsr @r10 ; preptable ROM:00011304 nop ROM:00011306 nop ROM:00011308 mov.l @(h'BC,pc), r4 ; [000113C8] = map_cal ROM:0001130A mov.l @(h'B8,pc), r10 ; [000113C4] = tablemable ROM:0001130C jsr @r10 ; tablemable ROM:0001130E nop ROM:00011310 mov r0, r2 ROM:00011312 mov.l @(h'BC,pc), r4 ; [000113D0] = temp_comp_0 ROM:00011314 mov.l @(h'B4,pc), r10 ; [000113CC] = reqfromtable ROM:00011316 jsr @r10 ; reqfromtable ROM:00011318 nop ROM:0001131A mulu r0, r2 ROM:0001131C sts macl, r0 ROM:0001131E shlr2 r0 ROM:00011320 shlr2 r0 ROM:00011322 mulu r0, r1 ROM:00011324 sts macl, r0 ROM:00011326 nop ROM:00011328 shlr8 r0 ROM:0001132A mov.w @(h'3C,pc), r10 ; [0001136A] = h'80 ROM:0001132C add r10, r0 ROM:0001132E nop ROM:00011330 nop ROM:00011332 nop ROM:00011334 nop ROM:00011336 nop ROM:00011338 nop ROM:0001133A nop ROM:0001133C nop ROM:0001133E mov.l @(h'2AC,pc), r10 ; [000115EC] = mafsource1 ROM:00011340 mov.w r0, @r10 ROM:00011342 mov.l @(h'9C,pc), r10 ; [000113E0] = maf_mult_warmup ROM:00011344 mov.w @r10, r10 ROM:00011346 extu.w r10, r10 ROM:00011348 mov.l @(h'2A0,pc), r4 ; [000115EC] = mafsource1 ROM:0001134A mov.w @r4, r4 ROM:0001134C extu.w r4, r4 ROM:0001134E mov r10, r5 ROM:00011350 mov.l @(h'90,pc), r10 ; [000113E4] = r4xr5 ROM:00011352 jsr @r10 ; r4xr5 ROM:00011354 nop ROM:00011356 mov.l @(h'288,pc), r11 ; [000115E0] = mafs1xmafmult ROM:00011358 mov.w r0, @r11 ROM:0001135A mov.l @r15+, r8 ROM:0001135C mov.l @r15+, r2 ROM:0001135E mov.l @r15+, r1 ROM:00011360 mov.l @r15+, r14 ROM:00011362 lds.l @r15+, pr ROM:00011364 rts ROM:00011366 nop ROM:00011366 ; End of function mafsource_2
Feb 2, 2009, 01:23 AM
#105
I'm not talking about the code that you posted above, but the code that uses your mafsource1 and mafs1xmafmult.
You will see in the MAF interrupt routine (MAFLONG) that MAFSOURCEMAIN and MAFSOURCEMAINxMAFMULT are compared with mafsource1 and mafs1xmafmult. If they are higher, they are limited to mafsource1 and mafslxmafmult (this is what you are using now). If you remove the conditional branches (bf - one for each comparison, they are a few hundred bytes apart in the code) and put a nop for each instead then you will change the flow of the code from a limiter to making the variables get overwritten anyway: MAFSOURCEMAIN=mafsource1 and MAFSOURCEMAINxMAFMULT=mafs1xmafmult and you have full SD.
Bez only replaced MAFSOURCEMAIN, which is why I think he had the cold start problems he reported - (MAFSOURCEMAINxMAFMULT is calculated from MAFSOURCEMAIN before he overwrites it with mafsource1, so when the MAF sensor is unplugged he'll get funny values).
MAFSOURCEMAIN becomes load.
MAFSOURCEMAINxMAFMULT is used to calculate IPW.
You will see in the MAF interrupt routine (MAFLONG) that MAFSOURCEMAIN and MAFSOURCEMAINxMAFMULT are compared with mafsource1 and mafs1xmafmult. If they are higher, they are limited to mafsource1 and mafslxmafmult (this is what you are using now). If you remove the conditional branches (bf - one for each comparison, they are a few hundred bytes apart in the code) and put a nop for each instead then you will change the flow of the code from a limiter to making the variables get overwritten anyway: MAFSOURCEMAIN=mafsource1 and MAFSOURCEMAINxMAFMULT=mafs1xmafmult and you have full SD.
Bez only replaced MAFSOURCEMAIN, which is why I think he had the cold start problems he reported - (MAFSOURCEMAINxMAFMULT is calculated from MAFSOURCEMAIN before he overwrites it with mafsource1, so when the MAF sensor is unplugged he'll get funny values).
MAFSOURCEMAIN becomes load.
MAFSOURCEMAINxMAFMULT is used to calculate IPW.
Last edited by jcsbanks; Feb 2, 2009 at 02:04 AM.