I've been slowly working my way through the boost control code in the ROM to try to get a better handle on boost control. My eventual goal is to be able to convert the routine into a direct boost control routine rather than the current indirect boost control routine.

In going through the code, I realized that there are like 6 or 7 load variables that are used throughout the ROM code. In particular, the load variable used for boost control is not the same as the load variable used for fuel/timing control. I went ahead and logged the raw load variables in a WOT 3rd gear run to get a feel for the difference between the two variables. They are shown below.

On a more interesting note, it seems that there may be a mistake in the boost error correction table definition in the ECUFlash ROM definition. More on that later. :-)

 

Thank you for your continued contribution on this topic. The community has certainly benefited from your tireless efforts.

Interesting finding you have, here. Even found a bug in Mitsu's code? That's hilarious.

One thing I was thinking of that may be handy is the ability to log the correction (upward or downward) so that you aren't stuck turning off correction altogether or guessing how your logged load/WGDC was achieved.

Ideally, as you said, it would be best to have a direct boost control routine instead...based on the inputs from a handy JDM MAP sensor.

 

So is the conventional 2 Byte Load that everyone logs the black line in this example? That would make sense, as fuel & timing adjustments based on 2 Byte are usually dead on.

But it looks like boost control uses a slightly lower value than what we log as 2 Byte. Am I correct?

 

Not a bug in Mitsu's code, but perhaps a mistake in how ECUFlash scales the TBEC table data. Not sure yet though. Hope to have time this evening to work this out.

 

Yes, the black line is the 2-byte load that everyone is logging.

The boost control load does run lower than 2-byte load for fuel/timing during aggressive driving. However, it appears that in the ROM code, the ECU may be using the higher of the two values. Still need to work that out.

 

Nice going and keep up the good work!!

 

I had a feeling about that. I've seen some odd things on some Evo's tuning for ecu-boost control.

You have PM

 

PM'ed you back. :-)

 

Turns out that this is correct. I figured out how to make the boost control use the load for fuel/timing. I need to try to determine if there would be any unwanted side effects of doing this. Off the top of my head, I don't see what problem it would cause, but I still need to look a bit.

 

I'm really looking forward to these results. If you need some help testing just shoot me a PM.

 

mmm fuel/timing load is the main one obviously

 

I have some interesting news for all the USDM Evo 9 folks. Seems that the two-byte load we've been logging for about a year now (FFFF6B42) is definitely not the load used for ignition advance lookup, and it may not be the load used for AFR lookup either. I just spent the better part of the morning going through the spark and AFR code, and here's what I found:

1) Spark lookup uses FFFF6B46 when the IAT > 25C, and can use either FFFF6B46 or FFFF6B48 (load boost) when the IAT <= 25C (there is a flag that chooses, and I haven't figured out that flag yet). Some sort of offset is also added whichever value is choosen. Haven't tried to decipher the logic that controls this offset yet.

2) AFR lookup uses either FFFF6B42 or FFFF6B48. There are two flags used to make the decision. I don't know these flags yet.

My initial comparisons of FFFF6B46 and FFFF6B48 show them to be virtually identical, so my conclusion at this point is that we are better off using FFFF6B48 (load boost) to represent load. However, I want to do some more comparisons of FFFF6B46 and FFFF6B48 to see how much they differ.

 

Any ideas or even guesses as to why the stock rom is coded in this way with so many different load variables.

 

(NOTE: The RAM addresses mentioned here are only for an Evo IX.) I finally had some time to make some good progress here. Along with being able to log any of the load variables used by the ECU (FFFF6B42, FFFF6B48, etc.), I am now able to log the exact load values that are used in the lookup tables for timing, fuel, boost (WGDC), MIVEC, etc.

Boost and MIVEC always use FFFF6B48. Timing can use FFFF6B46 or FFFF6B48 while fuel can use either FFFF6B42 or FFFF6B48. Looking at the ROM code, its not so obvious to tell which values get used for fuel and timing, so I made some changes to the ROM to enable logging of the actual load values used for fuel and timing. The first figure below suggests that that for normal daily driving, all the load values are essentially identical. For WOT runs, there can be a split though. As can be seen in the secod figure, fuel follows FFFF6B42 while timing and boost follow FFFF6B48. In this run, the split didn't exceed more than 10 load units, so the difference is still pretty small.

Based on what I've seen thus far, I think it makes more sense to use FFFF6B48 because Boost, MIVEC, and timing all track this variable whereas only fuel tracks with FFFF6B42 (which is the value that everyone is using now). And without a doubt, using FFFF6B48 will definitely make it easier tune the ECU boost control system. Sometime over the next week or so, I'll be posting the RAM address for this load variable for the various USDM Evo 8s. That's it for now.

 

Do you have the code that we would put in our data.xml file to fix evoscan or is it not that easy to fix?