Yep. There goes the ROM ID neighbourhood.

Inside, it's very similar to 59580004. My RAX3 auto-generation script works off about fifteen ROM-specific items. All fifteen of them match, between 52680002 and 59580004.

Rich

 

Hey Richard,

Wanted to say 59580004/5 with TephraMod3 tested and running great!

The new WGDC correction strategy works GREAT: http://datazap.me/u/razorlab/seth-do...1&zoom=136-430

I have one question though. Do you have a setting on how long after boost is dropping before Correction can come back in? If you notice in the log above, it lags a little bit behind the boost drop. Anyway to make it a tiny bit more sensitive as far as how fast it ramps back up?

 

Brilliant, thanks. Original post updated to reflect this.


Oh yeah, look at that. It's good how it avoids messing around with correction at all during spool. Also good in that example how it only dials in +8% on the second WOT, versus +9.5% on the first.


That's purely down to the error correction interval. The EC system does exactly what it always did... checks periodically to see if it needs to tweak WGDC up or down. If your interval is on "1" already, it's about as responsive as it gets.


Note that it's not exactly a matter of how long after boost is dropping. The change is simply that it won't ADD to EC if boost is rising. So dropping or steady boost is fair game.

And its idea of the DELTA boost is simply the current PSIA level versus the PSIA it saw at the last periodic interval check.


[edit]So looking at your first datazap WOT example, and working back from the first upward correction, the RAX "Smarter EC" patch would have seen these PSIA values...

Interval 1 : 36.27 psi
Interval 2 : 39.46 psi = Rising, so no +EC allowed
Interval 3 : 39.65 psi = Rising, so no +EC allowed
Interval 4 : 38.88 psi = Not rising, so +EC allowed

In the log, we see that PSIA peaked at 39.94 psi in between Intervals 2 and 3. But the EC mechanism wasn't checking as often as our log resolution "ticks", so it just saw the above.


I'm running an interval of "1" these days, with quite aggressive upward EC values... because I wrote the magic patch that stops the EC mechanism from overdoing things. As soon as it's turned a boost curve upwards, it stops poking at it!


Cheers,

Rich

 

Hi Bryan.

Should "wgdccorr" not return to 0% upon throttle-off? It's staying -ve in your datazap sample.

I'm concerned that my "Smarter EC" patch might be prohibiting "wgdccorr" from returning to zero on throttle-off when the manifold is below barometric pressure.

Take a look at "wgdccorr" seemingly stuck at -4.5% between test #1 and #2.

And stuck at -2.0% between test #2 and #3.



I'm not sure it's working exactly as I'd like. I thought EC should always be able to return to the zero line when throttle is closed...?

Or am I mistaken here?


If this is an omission on my part, it's not going to increase risk; The patch errs on the side of caution (ie. prevents the ECU from increasing EC in certain situations), so if it's got a quirk, it's only going to result in lower boost the next throttle-on.

Thoughts?


[edit]In all my own-car testing to date, wgdccorr snaps to 0% the instant my throttle backs off... but perhaps that's because my tables are set up differently, and/or perhaps my boost levels interact differently with the table settings.

Rich

 

Rich,

Here are some more examples.

http://datazap.me/u/razorlab/seth-do...-31&solo=20-31

WGDCcorr goes to -2.5 when TPS closes.

Here, 2nd through 3rd gear pull, WGDCcorr goes negative between shifts but snaps to 0 on throttle lift after 3rd gear.

http://datazap.me/u/razorlab/seth-do...-31&zoom=6-500

Another 2nd through 3rd gear pull. WGDCcorr snaps to 0 between shifts:

http://datazap.me/u/razorlab/seth-do...31&zoom=11-436

The above are all the same car with the same boost control settings.

Different car, here is 4th and 5th gear, no RAX patch, snaps to 0 between shifts:

http://datazap.me/u/razorlab/thunder...om=30707-31148

 

Hi Bryan.

What has me intrigued about those -ve wgdccorrvalues between WOT tests is this...


Historically, a lot of tuners (both pro and own-car-wannabes like me) have made a point of zeroing out the top cell of the Target Boost Error Correction table, so that wgdccorrwas not cranked up to the limit during early- and mid-spool, just because it was technically "below target". By zeroing out that first cell, one could avoid having any upward EC until boost levels were in the ballpark of the expected target.


And with Target Boost Error Correction cell #1 set to 0, it therefore follows...


...that interval-based alterations to wgdccorr would have absolutely NO way of pulling a -8% value back up to 0%. Because the upward EC value it has available to add to wgdccorr... is 0.


While my "Smarter EC" patch might well be missing an opportunity to pull up a negative EC value when in vacuum, one of the most common tuning tweaks to error correction would be right there alongside it.

Rich

 

Ah ha! That's funny.

I never leave that #1 cell at 0 and I did it this time because it said to in your instructions (or maybe I understood that incorrectly).

I'll go back to my usual method of not zeroing out that cell.

 

That'll help, I reckon!


But I think the edge condition may still exist with the patch...

- If PSIG manages to go from WOT-target levels to vacuum levels really fast.
- If wgdccorr was negative by that point, due to EC doing its thing.
- If that vacuum-level PSIG then goes immediately into a "rising" pattern.

Then my patch will activate and lock out any +ve correction to wgdccorr.

If there isn't a separate "zero out the EC" trigger in the ECU's processing, wgdccorr will stay -ve while the various conditions remain true.


There might be knock-on implications for "fixing" this. I'm not going to rush into anything...

Rich

 

Quick update...

In the initial beta patches, there was a problem with the "Atmospheric Boost Baro Compensation" Omni 4-Bar Mode processing, which resulted in boost targets being incorrect (too low). I've now fixed this...

...and have uploaded all RAX Patch v3 files to the original post, as an attachment. I guess this means RAX Patch v3 is now in "Beta Phase 2".



Oh, and I haven't made a decision on the "Smarter EC" patch behaviour we've been discussing. For now, I'm content to wait and see. If the ECU has its own ideas as to how it manages wgdccorr when off-throttle, it doesn't matter what RAX Patch "Smarter EC" does - it won't "fix" something that's not technically broken. But if the ECU turns out to need +ve correction in vacuum, to return wgdccorr to zero, I'll make a change to ensure the patch doesn't get in the way.


Enjoy "Phase 2".

Rich

 

Thanks Rich for all the hard work. I finally have my car back again so can do stuff!

 

Note: Corrected a typo in the list of supported ROMs, first post.

52370004 should have been 52370024.

Rich

 

Any chance to add 53600010 to the list? It's my preferred 09RA rom. Or can I just use the 53600009 and rename it. Sometimes that works, sometimes it doesn't....

 

As far as I can see from Golden's XMLs, 53600009.xml just includes 53600010.xml.

The latest EcuFlash-delivered XMLs point 0009 and 0010 at "53600008 2009 USDM Lancer Ralliart SST.xml".

And way back when I did my RAX v1 work, the one patch did all of 53600008-0010.


So it should "just work", no worries.

Rich

 

I need a little help with step 1. (listed below) When richardjh says to "uninstall" the patch does he mean to change the Rax maps from "Enabled" to "Disabled" or is there more to it than that?

2nd Question: Are rax maps present on tephra roms right from the start? I have been running a tephra V1 rom, 55580106, from the beginning, as my stock rom was undefined. Ive been on this rom with Rax2 for so long now I can't remember if the Rax maps where there when I started or not until Rax was added later on. The reason I ask is I had Rax2 in place when I got my TephraMODV3 rom and I think I may have effected the rom based on your instructions. I did not add Rax3 xml to my rommetadata file yet but the V3 xml is has been and Rax2 is still in the file. Have I made a booboo here? And how do I fix it?


Instructions for First Use "Provided by richardjh to install Rax3"

1. Uninstall any old RAX/RAX2 patches from your vehicle ROM.

RAX3 Patch contains differences in patch data and/or patch location, compared to older RAX Patch versions.

If you wish to use RAX3 Patch on a ROM currently using an older version of RAX, it is necessary to first uninstall any old RAX Patch code/data from your ROM.

Do this before downloading and installing RAX3 Patch.


2. Move aside any old RAX/RAX2 files in your EcuFlash folder.

If you have used an older version of RAX Patch...

Go to your EcuFlash XML folder for mitsubishi, eg.

C:\Program Files\OpenECU\EcuFlash\rommetadata\mitsubishi

Find any and all old RAX related files. In Windows’ File Explorer, hit CTRL-F, and enter RAX as the search string.

Move ALL these old RAX files to an entirely separate “backup” folder, outside the EcuFlash folder tree... where EcuFlash can’t find them!


3. Download the new RAX3 Patch XML files.


4. Copy your ROM’s XML file into place in your car’s EcuFlash folder.

eg. C:\Program Files\OpenECU\EcuFlash\rommetadata\mitsubishi\evo or C:\Program Files\OpenECU\EcuFlash\rommetadata\mitsubishi\lanc er

...depending on vehicle model.

 

56920008 confirmed as working okay, with tephraXModv3.

List updated in first post.

Rich