SD - first test success
Thread Starter
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
SD - first test success
First test is a success without even having to change my first values, it drives and cold/warm starts like stock, closed loop trims are good, throttle response fine without changing any acceleration enrichment settings. It is freezing with snow on the ground so I have not done a test with boost to fine tune the tables, but this I expect will be the easy bit as it is closed loop and transients that are hard to get right with SD. It is easily good enough to go around my farmyard 60 ft "roundabout" with the awesome S-AYC holding the tail out 
See the attached screen grab of my new Ecuflash tables. I did not make any changes to a stock ECU other than what you can see, so do not be overwhelmed. My work over the last few months on understanding all the ECU routines has been so that I can hit just a few key targets and do everything I want without huge changes. This way it should be bug free and easily transferred (once tested a bit more!) to lots of other ECUs, perhaps as a Tephra patch? The only two tables that are user configurable are the SD RPM VE (which is an old table that I just changed the values in) and a new SD MAP sensor calibration table which is actually looking after most of my VE calibration. I have, in the end, replicated the OEM airflow and load values based on Evoscan's excellent map tracing logging which I used to produce a MAP vs RPM vs VE display, from which I concluded the above settings, which so far, just work.
For the coders:
The four values of 0009 are NOPs to get the stock ECU to:
Replace MAFSOURCEMAIN and MAFSOURCEMAINxMAFMULTIP with the calculated values
Remove load limits
Remove MAF sensor unplugged error (still to do a MAT into IAT change in software, and disable the baro unplugged error)
The DA56 changes a table lookup to an axis lookup. The E273 loads r2 with 0x73 (calc explained below).
29E4 is a space I found nearby to put the map axis for the SD MAP sensor calibration table. FFFF6ABC is the raw MAP sensor value, which is used to interpolate the top row of the SD MAP sensor calibration table. FFFF699C (and the 699C reference with the FFFF not shown) is the result of this interpolation which is used to lookup the bottom row of the SD MAP sensor calibration table.
The calculation with two worked examples:
FIRST WORKED EXAMPLE:
MAP = 121kPa, RPM below 5500:
MAP lookup for 121 kPa is 121/1.334 = 91 (1.334 is the JDM MAP scaling from raw to kPa absolute)
RPM lookup is 100% = 128
r2 multiplier of 0x73 = 115
MAFSOURCEMAIN = 91*128*115/0x4000*8=654
From this the ECU calculates load:
Load = MAFSOURCEMAIN*0.596 = 1157*0.596 = 390
Load is scaled in the ECU as 10/32 so load is 690*10/32 = 121
Note how my choice of 0x73 as a multiplier result in load=MAP(kPa) when the RPM VE is 100% and when the MAP lookup is 1:1. On a near standard car above 120kPa and below 5500 RPM this is pretty near, but I still have to do the actual boost testing when the snow melts.
SECOND WORKED EXAMPLE (abbreviated):
MAP = 31kPa, lookup 24, RPM VE again 100%
Load = 24/1.334*128*0x73/0x4000*8*0.596*10/32=24
Other thoughts:
If the baro sensor remains in the inlet tract it will pull down the load at high RPM. So the RPM VE map will have to be adjusted less at high RPM if the baro sensor is still present.
See the attached screen grab of my new Ecuflash tables. I did not make any changes to a stock ECU other than what you can see, so do not be overwhelmed. My work over the last few months on understanding all the ECU routines has been so that I can hit just a few key targets and do everything I want without huge changes. This way it should be bug free and easily transferred (once tested a bit more!) to lots of other ECUs, perhaps as a Tephra patch? The only two tables that are user configurable are the SD RPM VE (which is an old table that I just changed the values in) and a new SD MAP sensor calibration table which is actually looking after most of my VE calibration. I have, in the end, replicated the OEM airflow and load values based on Evoscan's excellent map tracing logging which I used to produce a MAP vs RPM vs VE display, from which I concluded the above settings, which so far, just work.
For the coders:
The four values of 0009 are NOPs to get the stock ECU to:
Replace MAFSOURCEMAIN and MAFSOURCEMAINxMAFMULTIP with the calculated values
Remove load limits
Remove MAF sensor unplugged error (still to do a MAT into IAT change in software, and disable the baro unplugged error)
The DA56 changes a table lookup to an axis lookup. The E273 loads r2 with 0x73 (calc explained below).
29E4 is a space I found nearby to put the map axis for the SD MAP sensor calibration table. FFFF6ABC is the raw MAP sensor value, which is used to interpolate the top row of the SD MAP sensor calibration table. FFFF699C (and the 699C reference with the FFFF not shown) is the result of this interpolation which is used to lookup the bottom row of the SD MAP sensor calibration table.
The calculation with two worked examples:
FIRST WORKED EXAMPLE:
MAP = 121kPa, RPM below 5500:
MAP lookup for 121 kPa is 121/1.334 = 91 (1.334 is the JDM MAP scaling from raw to kPa absolute)
RPM lookup is 100% = 128
r2 multiplier of 0x73 = 115
MAFSOURCEMAIN = 91*128*115/0x4000*8=654
From this the ECU calculates load:
Load = MAFSOURCEMAIN*0.596 = 1157*0.596 = 390
Load is scaled in the ECU as 10/32 so load is 690*10/32 = 121
Note how my choice of 0x73 as a multiplier result in load=MAP(kPa) when the RPM VE is 100% and when the MAP lookup is 1:1. On a near standard car above 120kPa and below 5500 RPM this is pretty near, but I still have to do the actual boost testing when the snow melts.
SECOND WORKED EXAMPLE (abbreviated):
MAP = 31kPa, lookup 24, RPM VE again 100%
Load = 24/1.334*128*0x73/0x4000*8*0.596*10/32=24
Other thoughts:
If the baro sensor remains in the inlet tract it will pull down the load at high RPM. So the RPM VE map will have to be adjusted less at high RPM if the baro sensor is still present.
Good stuff!
Trending Topics
John,
Just so I understand and what we were discussing in the other thread....you left your fuel and timing maps alone, correct? So, the axes stayed as load vs RPM, but the load calculation is just coming from map rather than maf?
If so, then that's great, but I thought you said that you were going to change the axes to be map vs RPM instead of load vs RPM. I hope I misunderstood this and you are keeping the axes as load vs RPM.
Just so I understand and what we were discussing in the other thread....you left your fuel and timing maps alone, correct? So, the axes stayed as load vs RPM, but the load calculation is just coming from map rather than maf?
If so, then that's great, but I thought you said that you were going to change the axes to be map vs RPM instead of load vs RPM. I hope I misunderstood this and you are keeping the axes as load vs RPM.
