Question, ECU load determining accuracy
Actually I have seen the same thing.. there are just some areas that become real quirky with large jumps in timing if you "Skip" load cells that you've progressively smoothed.. which is probably the reason you see some blocks of timing on some tunes.
Originally Posted by dan l
You guys REALLY need to quit looking at MAF Hz values. It is meaningless. Your using the biggest part of a three part formula. Your going to get a lot further faster if you just unclick the MAF Hz in your logger.
If you want to see if your moving more lbs/min of air watch your injector pulsewidth (without changing your fuel tables). If your have more IPW your moving more air.
We need to know the grams/rev value in the ecu. It needs to be found. This is THE most important part of working with the stock ECU. Knowing this value is about all I need to know to tune my DSM. I'll be picking up an EVO 9 this weekend so hopefully that will speed my process of helping out.
In the meantime, what I used to do in my DSM before we found the grams/rev value is the timing lookup that you guys hate. For now, I'm sticking with my 1 deg timing retard per 3 counts of knock value. That is ***-U-ME ing an octane value of 255.
That brings me to another point. I'm gonna want to write come code to do some usefull things like reset the octane value every time you start the car. Anybody have the opcodes for the SH2 processor that the evo uses?
If you want to see if your moving more lbs/min of air watch your injector pulsewidth (without changing your fuel tables). If your have more IPW your moving more air.
We need to know the grams/rev value in the ecu. It needs to be found. This is THE most important part of working with the stock ECU. Knowing this value is about all I need to know to tune my DSM. I'll be picking up an EVO 9 this weekend so hopefully that will speed my process of helping out.
In the meantime, what I used to do in my DSM before we found the grams/rev value is the timing lookup that you guys hate. For now, I'm sticking with my 1 deg timing retard per 3 counts of knock value. That is ***-U-ME ing an octane value of 255.
That brings me to another point. I'm gonna want to write come code to do some usefull things like reset the octane value every time you start the car. Anybody have the opcodes for the SH2 processor that the evo uses?
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
IDA Pro how-to from an IDA newbie who just started on it... select SH4B processor. Find the jump vector from the first 2 or 4 bytes of the ECU, move your cursor there and hit C. This will map out all the subroutines and data sections.
It is interesting to start from the headers to each map - eg 03 00 FF FF 69 6C FF 69 6E 13 then it runs into the map. The &H13 (decimal 19) is the row length - number of RPM values in each row. The 03 00 means 3d map, the other 2 x 4 byte addresses refer to RAM locations.
In IDA you can click the header to maps like the 03 above and you'll see data cross references to other parts of the ROM. These are then used as indirect references for subroutines.
It is interesting to start from the headers to each map - eg 03 00 FF FF 69 6C FF 69 6E 13 then it runs into the map. The &H13 (decimal 19) is the row length - number of RPM values in each row. The 03 00 means 3d map, the other 2 x 4 byte addresses refer to RAM locations.
In IDA you can click the header to maps like the 03 above and you'll see data cross references to other parts of the ROM. These are then used as indirect references for subroutines.
Originally Posted by C6C6CH3vo
What stinks is my W/M controller not only uses boost but also uses that frequency to route VDC to my pump. At 1602 my pump will only run 90% max no matter what the boost.
Is it my imagination or does anyone else notice Ecu becomes a little picky in areas where load changes fast per rpm unless timing values aren't flat (redundant adjcent values)?
Is it my imagination or does anyone else notice Ecu becomes a little picky in areas where load changes fast per rpm unless timing values aren't flat (redundant adjcent values)?
Originally Posted by jcsbanks
IDA Pro how-to from an IDA newbie who just started on it... select SH4B processor. Find the jump vector from the first 2 or 4 bytes of the ECU, move your cursor there and hit C. This will map out all the subroutines and data sections.
It is interesting to start from the headers to each map - eg 03 00 FF FF 69 6C FF 69 6E 13 then it runs into the map. The &H13 (decimal 19) is the row length - number of RPM values in each row. The 03 00 means 3d map, the other 2 x 4 byte addresses refer to RAM locations.
In IDA you can click the header to maps like the 03 above and you'll see data cross references to other parts of the ROM. These are then used as indirect references for subroutines.
It is interesting to start from the headers to each map - eg 03 00 FF FF 69 6C FF 69 6E 13 then it runs into the map. The &H13 (decimal 19) is the row length - number of RPM values in each row. The 03 00 means 3d map, the other 2 x 4 byte addresses refer to RAM locations.
In IDA you can click the header to maps like the 03 above and you'll see data cross references to other parts of the ROM. These are then used as indirect references for subroutines.
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
IDEA for value that may be proportional to load, inspired by comments about IPW by dan l IIRC:
(Injector pulse width-lag time)/AFR map lookup
Assuming no crazy temperature corrections, you could also look up your 14.4V injector lag time and so use a constant - it would be near enough I think.
Comments?
(Injector pulse width-lag time)/AFR map lookup
Assuming no crazy temperature corrections, you could also look up your 14.4V injector lag time and so use a constant - it would be near enough I think.
Comments?
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
AFRMAP Request ID is 32
At 14.4V, my injector lag is 0.46ms (note JDM injectors are different - see your ECU map).
Load = 2550*(IPW-0.46)/AFRMAP
...seems to work on mine from closed loop through peak boost to high revs in terms of matching ignition timing.
At 14.4V, my injector lag is 0.46ms (note JDM injectors are different - see your ECU map).
Load = 2550*(IPW-0.46)/AFRMAP
...seems to work on mine from closed loop through peak boost to high revs in terms of matching ignition timing.
I should rewrite my Evoscan log analyzer to add this data if the AFRMap column exists.. This way you can enter the value, and it "Should" generate the values for load sites..
Can you attempt to correlate the Baro/air temp sensor values in such a way to be useful if they change drastically? I do think as it stands it might be enough to help.. are you using the Raw data for the AFRMap, or the translated value?
Can you attempt to correlate the Baro/air temp sensor values in such a way to be useful if they change drastically? I do think as it stands it might be enough to help.. are you using the Raw data for the AFRMap, or the translated value?
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
I wrote this to Colby:
Hi Colby,
I know you are busy. A few of us are trying to disassemble sections of the Evo code using IDA Pro. We are in particular looking for the code that communicates with the MUT tools. In the DSMs there is apparently a table that translates the requestIDs that Evoscan uses into register or RAM addresses. I'm sure there will be something similar in the Evo, and if we can find it we can get logging of other data, like load etc. We could also insert bits of code to show flags and intercepts etc to break down the code to start making modifications to it.
So, my questions are:
1. Can you tell us what sort of method the Evo ECU uses to communicate down the diagnostic port?
2. What registers does it use to read and write? Serial, direct access?
Then we can start looking for the interesting code.
With your permission I would share your reply of course.
Cheers,
John Banks
Hi Colby,
I know you are busy. A few of us are trying to disassemble sections of the Evo code using IDA Pro. We are in particular looking for the code that communicates with the MUT tools. In the DSMs there is apparently a table that translates the requestIDs that Evoscan uses into register or RAM addresses. I'm sure there will be something similar in the Evo, and if we can find it we can get logging of other data, like load etc. We could also insert bits of code to show flags and intercepts etc to break down the code to start making modifications to it.
So, my questions are:
1. Can you tell us what sort of method the Evo ECU uses to communicate down the diagnostic port?
2. What registers does it use to read and write? Serial, direct access?
Then we can start looking for the interesting code.
With your permission I would share your reply of course.
Cheers,
John Banks
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
Originally Posted by MalibuJack
I should rewrite my Evoscan log analyzer to add this data if the AFRMap column exists.. This way you can enter the value, and it "Should" generate the values for load sites..
Can you attempt to correlate the Baro/air temp sensor values in such a way to be useful if they change drastically? I do think as it stands it might be enough to help.. are you using the Raw data for the AFRMap, or the translated value?
Can you attempt to correlate the Baro/air temp sensor values in such a way to be useful if they change drastically? I do think as it stands it might be enough to help.. are you using the Raw data for the AFRMap, or the translated value?
I know the AFRMAP value is AFTER the JDM lean spool stuff has been applied and not just the raw lookup from the map. I think also it has already been bilinearly interpolated, so it is probably quite close to a multiplier it uses with load to get IPW (once inj lag is added on).
I think we want to know if once mass airflow has been calculated using baro/IAT/maf Hz, whether it then applies a further correction based on say baro and IAT to the fuelling, and whether it does this within the load calcuation...
okay, can you e-mail me or PM me a log (on aktivematrix) with your afrmap value in it? I don't feel like doing any logging on my car right now.. I'll use that file to create my log tool.. I'll base it on my log analyzer but add more features..
Originally Posted by jcsbanks
Bump, anyone else tried this yet? Anyone see any problems with it except for when large fuel trims are operating in closed loop or during warm up?
jcsbanks,
I thought about this before, too, but I don't think this would work. It will work for a range, assuming your AFR is constant.
Let me give an example to explain, though:
Let's take a hypothetical situation where a car has a 100% VE from 4000-7000RPM. The turbo is fully spooled at 4000RPM, and holds boost constant in the same range. Let's say that your fuel map lookup values are getting slighlty leaner at each 1000 RPM, like 11.5, 11.7, 11.8, 12.0, etc.
If we logged this car, we would get a flat mass airflow/rev from 4000-7000 (since the 100 % VE and constant boost). The flat mass airflow/rev would indicate to me a flat load line also, but using your formula of IPW/AFR lookup value, in this case the load would be increasing (depending on the exact lookup value). If we logged injector pulsewidth in this case, it would be a stair step down, each step at the next increasing ARF lookup. Using your forumla, that would decrease the load (smaller injector pulsewidth over larger AFRMAP), with the numerator getting smaller and the denominator gettign larger.
Of course, this is assuming that load is directly proportional to mass airflow/rev in the first place, which in my experience with DSMs, it is.
I think we just need to log or find the mass airflow and then we can come up with a pretty exact formula for load. IPW corresponds directly with mass airflow/rev only at a constant AFR.
What do you think?
Eric
jcsbanks,
Thinking about this a little more, I think your formula will work with a minor modification.
To keep with the example above, to keep the numerator and demoninator going in the same direction, we can modify your forumla as follow:
absolute value of (Constant*IPW/(1-AFRMAP value))
or just use a large enough number so you don't need the absolute value, like 100 - AFRMAP value.
This value should exactly correspond with a mass airflow/rev. Try it out and let me know what you get.
What do you think?
Eric
Thinking about this a little more, I think your formula will work with a minor modification.
To keep with the example above, to keep the numerator and demoninator going in the same direction, we can modify your forumla as follow:
absolute value of (Constant*IPW/(1-AFRMAP value))
or just use a large enough number so you don't need the absolute value, like 100 - AFRMAP value.
This value should exactly correspond with a mass airflow/rev. Try it out and let me know what you get.
What do you think?
Eric