Speed Density Implementation Discussion
Thread Starter
Joined: Feb 2007
Posts: 9,486
Likes: 67
From: Melbourne, Australia
well I have been looking at the ROM deciding on how to actually take over the MAF signal... its pretty damn well integrated - which sux!
I guess I will have to "convert" my SD g/rev value to a MAF signal, and push that back into the top of the MAF stuff... hopefully it filters through fine
Still the maths is doing my head in... :|
I guess I will have to "convert" my SD g/rev value to a MAF signal, and push that back into the top of the MAF stuff... hopefully it filters through fine
Still the maths is doing my head in... :|
Evolved Member
Joined: Aug 2007
Posts: 569
Likes: 1
From: UK
im using a 7 manifold has the map or mdp sensor fitting but no iat ,,got a gm/delphi temp sensor definitely 3/8 npt .
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
I've been thinking more about this, looking a lot at disasm again.
1. Bez's method involves a few lookups to find:
MAP value from MAP voltage (table is virtually 1:1 as JDM MAP is vac at 0V and linear)
VE from RPM (needs lower at lower RPM)
Density compensation from air temp (table is flat)
He then takes the MAP value, multiplies it by VE and density and scales it before putting it into one of the MAFSOURCE variables.
After that the ECU smooths it and multiplies it so it becomes load, after that it applies baro and temp compensations to produce the other compensated load values. Of note, in the fuel subroutine, the ECU also applies compensations to the (simulated) MAF signal again (based on water temp, vehicle speed and linearization for the sensor itself) to calcuate the fuel load.
I think Bez's method seems good because all the logging and tuning is as before, you can log things to work out your VE table, or just go drive and scale it until your wideband is giving what it gave before you removed the MAF. The other corrections could be zeroed out to avoid applying them a few times and to sort the quirks of a MAF sensor that isn't there.
2. The other option entirely is to simply put in the MAP in kPa into all the load values. Having looked at the ECU, the main problem here is closed loop control where it seems to force the table lookup to 14.7 (AFRMAP of 128) when running closed loop even if the fuel table contains other values, I will look into this further to confirm, but I don't think changing the fuel cells in areas that run closed loop will presently make any difference, and they would need to be about halved to idle without VE comp. Otherwise we could effectively convert the table to a map of IPWs otherwise, and the range of adjustment is sufficient to allow us to code the range of VEs in there. If you know your boost you know your load and your fuel and timing lookups. There is already a table to trim ignition based on air temp, we would just need a similar one for fuel and we would be good to go like a standalone. Anyone think of any other problems with this method?
1. Bez's method involves a few lookups to find:
MAP value from MAP voltage (table is virtually 1:1 as JDM MAP is vac at 0V and linear)
VE from RPM (needs lower at lower RPM)
Density compensation from air temp (table is flat)
He then takes the MAP value, multiplies it by VE and density and scales it before putting it into one of the MAFSOURCE variables.
After that the ECU smooths it and multiplies it so it becomes load, after that it applies baro and temp compensations to produce the other compensated load values. Of note, in the fuel subroutine, the ECU also applies compensations to the (simulated) MAF signal again (based on water temp, vehicle speed and linearization for the sensor itself) to calcuate the fuel load.
I think Bez's method seems good because all the logging and tuning is as before, you can log things to work out your VE table, or just go drive and scale it until your wideband is giving what it gave before you removed the MAF. The other corrections could be zeroed out to avoid applying them a few times and to sort the quirks of a MAF sensor that isn't there.
2. The other option entirely is to simply put in the MAP in kPa into all the load values. Having looked at the ECU, the main problem here is closed loop control where it seems to force the table lookup to 14.7 (AFRMAP of 128) when running closed loop even if the fuel table contains other values, I will look into this further to confirm, but I don't think changing the fuel cells in areas that run closed loop will presently make any difference, and they would need to be about halved to idle without VE comp. Otherwise we could effectively convert the table to a map of IPWs otherwise, and the range of adjustment is sufficient to allow us to code the range of VEs in there. If you know your boost you know your load and your fuel and timing lookups. There is already a table to trim ignition based on air temp, we would just need a similar one for fuel and we would be good to go like a standalone. Anyone think of any other problems with this method?
Either method would work, but I always liked #1 better myself. I like to think in terms of mass airflow for the axes rather than pressure, for various reasons I have given previously.
The latter method will be heavily dependent on the separate temperature correction table, to account for different air masses at different temperatures at the same boost levels (ie day to night, or summer to winter). This table would most likely have to be a 3-D table. VE would be a compensation for both, but once ironed out, should stay the same unless new mods are added. I already have a preliminary VE curve for my car from mass airflow logs I have done.
The former method will not have to rely on a separate temp correction table...perhaps only for safety at extremely high temps, for an ignition trim. But, no 3-D map would be needed like in the latter example.
Since the ECU seems to be already doing the first method, I would think it would be best to follow suit and do it this way. Of course, this is just my opinion, and someone used to current stand alones may like #2 better.
Eric
The latter method will be heavily dependent on the separate temperature correction table, to account for different air masses at different temperatures at the same boost levels (ie day to night, or summer to winter). This table would most likely have to be a 3-D table. VE would be a compensation for both, but once ironed out, should stay the same unless new mods are added. I already have a preliminary VE curve for my car from mass airflow logs I have done.
The former method will not have to rely on a separate temp correction table...perhaps only for safety at extremely high temps, for an ignition trim. But, no 3-D map would be needed like in the latter example.
Since the ECU seems to be already doing the first method, I would think it would be best to follow suit and do it this way. Of course, this is just my opinion, and someone used to current stand alones may like #2 better.
Eric
Last edited by l2r99gst; Nov 13, 2008 at 09:27 AM.
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
I've re-read the thread again, and having used both types of systems I still can't decide either!
We know the VE method can work on the stock ECU, but I'd feel happier if we:
1. Tidied up the load values so they were all the same for boost/fuel/timing/VVT
2. Zero out any remaining MAF correction tables that are still lurking
Personally, I would be scaling my VE and injector scaling/latency so that load=kPa at peak torque and the WB AFR = fuel map+1.0 (1.0 being the lean spool adjustment) if the inlet manifold temp was 25C.
The temperature scaling is often about 50-60% of that suggested by the ideal gas laws (ie about 6% rather than the theoretical 10% for 30C change from 25C), because most people let the engine run slightly leaner and more advanced at low temps, and let it run richer and less advanced at high temps.
Bez is using a subtractor from estimated MAF/engine rotation to accommodate lower VE at idle. He also uses RPM to lookup VE.
Looking at many VE maps, I think the greatest % change in a VE map is usually due to MAP with a smaller contribution from RPM.
Options for VE maps:
1. MAP 2d
2. RPM 2d & subtractor (as Bez)
3. RPM 2d & Map 2d
4. MAP vs RPM 3d
5. MAP * RPM 2d
Any of these could work!
1 would leave a slightly lumpy fuel map to accomodate the increase VE in the midrange, probably only 10%
2 works for mixmastermatt/Tuner@Swift
3 might be odd to think about to start with
4 is big to adjust unless you have live tuning and a nice editor/good logs
5 works really well as I chose this method before, have a point for idle, few for cruise, part throttle boost, peak torque, high RPM.
We know the VE method can work on the stock ECU, but I'd feel happier if we:
1. Tidied up the load values so they were all the same for boost/fuel/timing/VVT
2. Zero out any remaining MAF correction tables that are still lurking
Personally, I would be scaling my VE and injector scaling/latency so that load=kPa at peak torque and the WB AFR = fuel map+1.0 (1.0 being the lean spool adjustment) if the inlet manifold temp was 25C.
The temperature scaling is often about 50-60% of that suggested by the ideal gas laws (ie about 6% rather than the theoretical 10% for 30C change from 25C), because most people let the engine run slightly leaner and more advanced at low temps, and let it run richer and less advanced at high temps.
Bez is using a subtractor from estimated MAF/engine rotation to accommodate lower VE at idle. He also uses RPM to lookup VE.
Looking at many VE maps, I think the greatest % change in a VE map is usually due to MAP with a smaller contribution from RPM.
Options for VE maps:
1. MAP 2d
2. RPM 2d & subtractor (as Bez)
3. RPM 2d & Map 2d
4. MAP vs RPM 3d
5. MAP * RPM 2d
Any of these could work!
1 would leave a slightly lumpy fuel map to accomodate the increase VE in the midrange, probably only 10%
2 works for mixmastermatt/Tuner@Swift
3 might be odd to think about to start with
4 is big to adjust unless you have live tuning and a nice editor/good logs
5 works really well as I chose this method before, have a point for idle, few for cruise, part throttle boost, peak torque, high RPM.
When I calculate my VE from mass air logs, I use this equation:
VE=n(lb/min)*10.73*T(*R)*3456
__________________________
P(psia)*29*Cid*RPM
I do agree with your that MAP and RPM are involved, but to me, it's more RPM dependent. One you're 100% throttle, then the VE curve is going to follow your RPM curve, since your mass airflow should be proportional to your map pressure (with respect to a constant T).
I did some logging with a very slow computer, so my data wasn't synched very well, especially at boost ramp-up, but I got something like this:
If I calculated VE at cruise, with this method, it was about 50-60%. But, that is expected, since the throttle plate is almost closed and you're not getting the true airflow of the engine. Perhaps that is what Bez was doing with his subtractor? Taking into account non-WOT conditions of idle and cruise?
We just have to agree on a way to do it and do it. : ) As long as we are all on the same page and understand what is going on and what needs to be changed for tuning purposes. But, now that you have listed how Bez does it, that is how I would like it done as well. It makes the most sense to me.
VE=n(lb/min)*10.73*T(*R)*3456
__________________________
P(psia)*29*Cid*RPM
I do agree with your that MAP and RPM are involved, but to me, it's more RPM dependent. One you're 100% throttle, then the VE curve is going to follow your RPM curve, since your mass airflow should be proportional to your map pressure (with respect to a constant T).
I did some logging with a very slow computer, so my data wasn't synched very well, especially at boost ramp-up, but I got something like this:
Code:
cutout open lb/min RPM *R psia VE 14.9 3026 525.7 23.34 1.162 23.6 3503 526.3 38.2 .973 25.5 4020 526.1 36.65 .954 28 4520 526.5 36.64 .933 31.2 4989 527.4 36.56 .946 33.5 5490 529 36.27 .933 36.2 6029 530.9 35.94 .930 37.5 6506 533.1 36.33 .886 38.7 7038 538 34.76 .892 cutout closed 11.7 3003 525.5 20.79 1.032 21.8 3527 526.3 35.47 .961 25.5 4020 526.5 36.46 .960 27.9 4536 526.9 36.46 .931 30.3 5028 528 35.94 .928 32.9 5490 529.6 35.47 .938 34.7 6029 532.3 35.05 .916 36 6522 534.5 34.71 .891 36.2 6890 537.3 34.29 .863
We just have to agree on a way to do it and do it. : ) As long as we are all on the same page and understand what is going on and what needs to be changed for tuning purposes. But, now that you have listed how Bez does it, that is how I would like it done as well. It makes the most sense to me.
Last edited by l2r99gst; Nov 13, 2008 at 10:29 AM.
I've been thinking more about this, looking a lot at disasm again.
1. Bez's method involves a few lookups to find:
MAP value from MAP voltage (table is virtually 1:1 as JDM MAP is vac at 0V and linear)
VE from RPM (needs lower at lower RPM)
Density compensation from air temp (table is flat)
He then takes the MAP value, multiplies it by VE and density and scales it before putting it into one of the MAFSOURCE variables.
After that the ECU smooths it and multiplies it so it becomes load, after that it applies baro and temp compensations to produce the other compensated load values. Of note, in the fuel subroutine, the ECU also applies compensations to the (simulated) MAF signal again (based on water temp, vehicle speed and linearization for the sensor itself) to calcuate the fuel load.
I think Bez's method seems good because all the logging and tuning is as before, you can log things to work out your VE table, or just go drive and scale it until your wideband is giving what it gave before you removed the MAF. The other corrections could be zeroed out to avoid applying them a few times and to sort the quirks of a MAF sensor that isn't there.
2. The other option entirely is to simply put in the MAP in kPa into all the load values. Having looked at the ECU, the main problem here is closed loop control where it seems to force the table lookup to 14.7 (AFRMAP of 128) when running closed loop even if the fuel table contains other values, I will look into this further to confirm, but I don't think changing the fuel cells in areas that run closed loop will presently make any difference, and they would need to be about halved to idle without VE comp. Otherwise we could effectively convert the table to a map of IPWs otherwise, and the range of adjustment is sufficient to allow us to code the range of VEs in there. If you know your boost you know your load and your fuel and timing lookups. There is already a table to trim ignition based on air temp, we would just need a similar one for fuel and we would be good to go like a standalone. Anyone think of any other problems with this method?
1. Bez's method involves a few lookups to find:
MAP value from MAP voltage (table is virtually 1:1 as JDM MAP is vac at 0V and linear)
VE from RPM (needs lower at lower RPM)
Density compensation from air temp (table is flat)
He then takes the MAP value, multiplies it by VE and density and scales it before putting it into one of the MAFSOURCE variables.
After that the ECU smooths it and multiplies it so it becomes load, after that it applies baro and temp compensations to produce the other compensated load values. Of note, in the fuel subroutine, the ECU also applies compensations to the (simulated) MAF signal again (based on water temp, vehicle speed and linearization for the sensor itself) to calcuate the fuel load.
I think Bez's method seems good because all the logging and tuning is as before, you can log things to work out your VE table, or just go drive and scale it until your wideband is giving what it gave before you removed the MAF. The other corrections could be zeroed out to avoid applying them a few times and to sort the quirks of a MAF sensor that isn't there.
2. The other option entirely is to simply put in the MAP in kPa into all the load values. Having looked at the ECU, the main problem here is closed loop control where it seems to force the table lookup to 14.7 (AFRMAP of 128) when running closed loop even if the fuel table contains other values, I will look into this further to confirm, but I don't think changing the fuel cells in areas that run closed loop will presently make any difference, and they would need to be about halved to idle without VE comp. Otherwise we could effectively convert the table to a map of IPWs otherwise, and the range of adjustment is sufficient to allow us to code the range of VEs in there. If you know your boost you know your load and your fuel and timing lookups. There is already a table to trim ignition based on air temp, we would just need a similar one for fuel and we would be good to go like a standalone. Anyone think of any other problems with this method?
on a different note, bez's old logs/charts looked very good and showed that this patch could effectively emulate the maf. that was 1+ years ago.
at this point, you would have to scale the emulated output a hair higher to create a cal/ve/offset setup, then rescale back down when acutally removing the maf. is that right? also, do you think every car going to be different in the scalings? very simple method indeed. removing all the 'quirks' might clean up the tuning quite a bit too...
[pulled from AktiveMatrix.com]
...crap wrong one
here it is...
Last edited by evoredy; Nov 13, 2008 at 10:29 AM.
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
...
2. The other option entirely is to simply put in the MAP in kPa into all the load values. Having looked at the ECU, the main problem here is closed loop control where it seems to force the table lookup to 14.7 (AFRMAP of 128) when running closed loop even if the fuel table contains other values, I will look into this further to confirm, but I don't think changing the fuel cells in areas that run closed loop will presently make any difference, and they would need to be about halved to idle without VE comp. Otherwise we could effectively convert the table to a map of IPWs otherwise, and the range of adjustment is sufficient to allow us to code the range of VEs in there. If you know your boost you know your load and your fuel and timing lookups. There is already a table to trim ignition based on air temp, we would just need a similar one for fuel and we would be good to go like a standalone. Anyone think of any other problems with this method?
2. The other option entirely is to simply put in the MAP in kPa into all the load values. Having looked at the ECU, the main problem here is closed loop control where it seems to force the table lookup to 14.7 (AFRMAP of 128) when running closed loop even if the fuel table contains other values, I will look into this further to confirm, but I don't think changing the fuel cells in areas that run closed loop will presently make any difference, and they would need to be about halved to idle without VE comp. Otherwise we could effectively convert the table to a map of IPWs otherwise, and the range of adjustment is sufficient to allow us to code the range of VEs in there. If you know your boost you know your load and your fuel and timing lookups. There is already a table to trim ignition based on air temp, we would just need a similar one for fuel and we would be good to go like a standalone. Anyone think of any other problems with this method?
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
Eric, nice data (as always!) thanks. It was interesting you found 50-60% VE at cruise, I would expect say 30-40% at idle, this is what I mean about the largest VE differences being due to MAP, you only have 8% difference due to RPM. Anyway, Bez has VE lookup from an RPM map, but also effectively from the MAP calibration if you use it as a VE lookup from MAP. Using both would remove the need for the subtractor since the lower VE at lower MAPs could be properly scaled rather than trying to make the gradient/intercept system and trying to enforce linearity upon it?
evoredy, I looked at your thread, but have always felt I wanted to get rid of the MAF entirely rather than use speed density as a limiter. I think I would just aim to get the MAF and MAP sourced values the same before switching entirely to MAP.
mrfred, that is very interesting. I will go read your threads on it.
evoredy, I looked at your thread, but have always felt I wanted to get rid of the MAF entirely rather than use speed density as a limiter. I think I would just aim to get the MAF and MAP sourced values the same before switching entirely to MAP.
mrfred, that is very interesting. I will go read your threads on it.
Evolved Member
Joined: Mar 2008
Posts: 730
Likes: 3
From: Lattitude 48.38°, Longitude 17.58°, Altitude 146m = Slovakia, for common dude
I am kind of newbie here, so maybe I am overseeing some important issues still.
But what about taking Z27W 4G15 or 4G19 JDM ECU and disassembling it? The only difference to EVO is the engine itself and it is MAP based, otherwise it has MIVEC, Turbo, but I am pretty sure that the the code would be helpful.
Basically if you are interested in the MAP controlled Mitsu ECU (non-MIVEC, non-Turbo, plain 4G15/4G18) I can provide this ROM to you.
But what about taking Z27W 4G15 or 4G19 JDM ECU and disassembling it? The only difference to EVO is the engine itself and it is MAP based, otherwise it has MIVEC, Turbo, but I am pretty sure that the the code would be helpful.
Basically if you are interested in the MAP controlled Mitsu ECU (non-MIVEC, non-Turbo, plain 4G15/4G18) I can provide this ROM to you.
There are three of them.
First is used when EGR is enabled,
Second is used when Periphery0 bit 5 is enabled
Third is used in all other cases
Code:
ROM:00000FAA 0: Unknown ROM:00000FAA 1: Rear O2 ROM:00000FAA 2: PEDR Pin14 ROM:00000FAA 3: Immobilizer ROM:00000FAA 4: PJR4 ROM:00000FAA 5: Unknown ROM:00000FAA 6: Front O2 ROM:00000FAA 7: Knock Sensor ROM:00000FAA 8: Unknown ROM:00000FAA 9: Unknown ROM:00000FAA 10: Unknown ROM:00000FAA 11: Unknown ROM:00000FAA 12: EGR Solenoid ROM:00000FAA 13: Unknown ROM:00000FAA 14: Unknown ROM:00000FAA 15: Unknown ROM:00000FAA Periphery_0
Load is calculated as MUT_1D/MUT_15
Code:
ROM:000341BA GET_OBD_CALCULATED_LOAD: ; CODE XREF: sub_32F58+1DAp ROM:000341BA ; PROCESS_MODE_01_OBD_REQUEST+160p ROM:000341BA ; DATA XREF: ... ROM:000341BA sts.l pr, @-r15 ROM:000341BC mov.l r14, @-r15 ROM:000341BE mov r15, r14 ROM:000341C0 mov.l @(h'B0,pc), r10 ; [00034274] = Barometric_Pressure ROM:000341C2 mov.w @r10, r10 ROM:000341C4 extu.w r10, r10 ROM:000341C6 mov.l @(h'A8,pc), r4 ; [00034270] = Absolute_Intake_Manifold_Pressure ROM:000341C8 mov.w @r4, r4 ROM:000341CA extu.w r4, r4 ROM:000341CC mov.w @(h'60,pc), r5 ; [00034230] = h'100 ROM:000341CE mov r10, r6 ROM:000341D0 mov.l @(h'98,pc), r10 ; [0003426C] = sub_5D0 ROM:000341D2 jsr @r10 ; sub_5D0 ROM:000341D4 nop ROM:000341D6 extu.w r0, r4 ROM:000341D8 mov.l @(h'8C,pc), r10 ; [00034268] = LIMIT_R4_TO_255_INTO_R0 ROM:000341DA jsr @r10 ; LIMIT_R4_TO_255_INTO_R0 ROM:000341DC nop ROM:000341DE extu.w r0, r0 ; Intake_Manifold_Pressure * 256 / Barometric_Pressure ROM:000341E0 mov.l @r15+, r14 ROM:000341E2 lds.l @r15+, pr ROM:000341E4 rts ROM:000341E6 nop
Last edited by acamus; Nov 13, 2008 at 10:27 PM.
To bring this thread back to life, I have 5 customer cars here now that are all itching for speed density. In fact I've even installed the needed map sensors and have IAT sensors ready to go (just waiting on Mr. Fred's help in patching the ROMs). I could do an extensive amount of testing on a variety of ROMs plus 2 are MIVECs.
Where are you as far as working patches? I saw that Bez is basically down with it so I'm hoping you've carried the torch.
Thx
Where are you as far as working patches? I saw that Bez is basically down with it so I'm hoping you've carried the torch.
Thx
