I decided to get another log in warmer weather. Turns out the the result is different. Load fuel and load timing have almost the exact same values as in the previous run, but load boost runs about 10 load units lower in this run. Turns out that the boost also was about 0.5 psi lower in this new run.

Now I'm beginning to understand why its been such a challenge to do ECU-based boost control. The load value used by the ECU to control boost seems to follow a different path than the other load values depending on weather conditions.

 

Some changes to the ROM are need also. The changes to the ROM can be accomplished using ECUFlash. Its going to take me some time to write up instructions.

 

Nice work mrfred. If loadboost runs 10 lower in higher temperature, I wonder if it is a mechanism to keep the engine output up on a standard car where it would be able to boost higher? The Bosch stuff does this, and it will do other odd stuff like increase boost to keep the engine output up even if it is knocking!

I wonder if the various duty and boost desired engine load are used in these various circumstances?

 

Sure seems like Mitsubishi is up to something like that for the boost control. Seems foolish to me as you suggest.

I was able to find the RAM variable for BDEL and log BDEL also. The "target load" in the plots is that logged BDEL with BCLO added to it in Excel. Seems to be invariant within this temperature range.

I am tempted to change the load variable in the boost control subroutine to one of the others so that boost is more invariant. Still need to do more logging before I try it though. I want to get at least one cool weather log and one or two 4th gear logs.

 

you need to be careful doing that - as each memory address gets initialized in different parts of the code - so you could be using "yesterdays" load value or even worse and invalid load value...

 

I'm still a newb at hacking assembly code, so I'm not sure what you mean by initializing the memory address. The multipurpose RAM variable (FFFF69CA in the USDM IX ROM) always gets updated just before it is used. Otherwise, my experience so far is that single purpose RAM variables like load FFFF6B42 are used throughout the code with no special preparation except perhaps during startup.

I've also already successfully played some tricks with switching out RAM variables. The fuel and timing lookup both use the multipurpose RAM variable for reading load. For both lookups, I switched out the multipurpose variable for an unused RAM address (and updated the load table with the same RAM address) so that I could read those load variables. Its working perfectly.

 

say XXX gets updated in the timing routine, but you change the fuel routine to use it as well then the fuel routine needs to run after the timing routine - otherwise you are using and old value of XXX.

remember its just on big loop in the end...

 

Yeah, I see your point there. I'd probably end up using one of the global load variables rather than one specific to the fuel or timing lookups.

 

Necro bump

What variables did you end up using to log the numbers to enter in the BDEL tables? I am currently using 6B48 and 6B49 in MUT8C and MUT8D respectively. I noticed a differene between this load and the 2byteload. The 2byteload is higher.

 

It depends on how you've got boost control setup. If you haven't done my "boost control mods", then the ECU adjusts boost according to FFFF6B48 (load boost) that you are logging. My boost control mods thread explains how to change the load variable for boost control to the "load fuel" variable. If you've done that, then you'd want to be logging FFFF6B42 which is the 2-byte load that everyone logs for an Evo 9.

There can indeed be a pretty sizable difference between load fuel and load boost. That's the reason why I created the "boost control mod". The topic of the various 2-byte loads was just ressurrected a few days ago in tephra's 2-byte loads thread.

 

I've been switching the load the ecu-boost follows to the normal 2byte load and it makes the boost much much more stable, repeatable and easier to tune.

btw welcome back mrfred.

 

Does that mean that you are entering the 2byteload that we all log in the BDEL minus BCLO? For example, for the 9 you are using the data from logging the 2 byte load this way:

2 byte load high bit = 27458
2 byte load low bit = 27459

After you log this 2byteload do you deduct BCLO from it and enter the number in the BDEL?

 

Yup.

 

Thanks! I won't have as much time as BC, but hope to keep contributing.

 

Although I have a different ROM id (evo 8 96530006) - so the adressess do not match - my 2bload is way lower than the load calculated by Evoscan. Sometime even 30 points. When taking this 2byte laod and the ignition - the pretty much match the the ignition table. So I assume this could be the right load for ignition. However - for fueling - the real afr are not matching the afr in the table - but this can be another issue (lean spool etc.).

Just to have an idea to compare - can you please also post the calculated loads together with the various 2byte loads. This way may be I can get an idea which 2byte load I am actually logging