Excellent job. Besides having to patch either the IAT scaling subroutine or the fuel tank temp subroutine, I wonder if any other ROM mods will be needed to get this working on USDM cars. I kinda wonder if the more comprehensive OBD-II routines on the USDM cars will require some patches to keep the CEL off.

BTW, there a large number of routines that depend on the IAT sensor continuing to operate and provide typical IAT values that would be much different that MAT values under some conditions, e.g., cruise. Seems that the IAT sensor would need to remain operating (and would preclude patching this subroutine for MAT on USDM cars). Is that your intent? Quite a few things depend on baro as well. Leave that operating as well?

 

If you need a test mule.....I am all for it. 94170015.

I've been working with the MAP to MAF patch with mixed results. Link me to your patch and I will start testing asap.

Paul

 

wow absolutly brilliant
John I have a 3 bar map sensor and IAT sensor fitted to my intake manifold
on 90550001 if you need any testing done

 

SNAP

 

+1, 90550001 with 3bar map and IAT too!

 

lets let john get it up and running with IAT replaced and Baro removed b4 we start putting in porting requests

 

VE is accounted for in the MAP calibration map and the RPM VE map, the results of each are multiplied together. I did consider a 3d map of MAP vs RPM which looks up VE, but I think the two 2d maps are easier to tune and logs and previous experience suggest that it just makes it harder to tune and no more accurate. If a 3d map was required it wouldn't be too hard to add but it would require some actual assembly rather than being a patch that can be applied in Ecuflash. As it is, if there were issues, then the fuel and timing maps can be altered, as can the original MAF compensation maps.

Eric, yes it replicates the original load, that is why the MAP calibration is not 1:1. Yes, I left my fuel and timing tables stock, and for off boost driving with my quick test in the snow it hits the right areas, I had to unplug the MAF sensor to prove to myself it really wasn't still using MAF. Of course then I had the CEL for baro and IAT, but unlike the MAF CEL they at least on JDM don't make it overfuel like mad, set a 4500 RPM limit and set the octane number to zero along with loads of other horrible effects.

I did hook up OBD Scantech to see what codes there were, and a few remain, hopefully if I can zap the ones that light up the CEL on the JDM models, someone that understands the OBD routines can zap anything there relevant to US/Euro models?

The OEM baro is a strange sensor since it is in the induction system - partly barometric pressure comp, but mainly I think to compensate our volume airflow sensor. Most of the things that depend on baro and IAT are load and IPW calcs. I think on JDM at least if MAT replaced IAT and baro was set to 101.5kPa it would work quite well. I suppose you could have a baro sensor sitting in the engine bay and adjust the mapping to suit if you needed a baro comp.

Bottom line is that there is flexibility on sensors, what is kept, what is deleted, what is replaced, what is change of sensor position/location etc, I can show where in Ecuflash to patch to get the JDM version going, from there it can be customised. Also just with the variety of tables we have people can set it up how they like - they could put all the MAF compensation tables to zero and end up wiht a "proper" load that is better than OEM since it is proportional to air charge, or they could replicate the OEM arrangement like I have, or they could do the MAP table 1:1 and the RPM table flat and then entirely compensate for VE in the MAF compensation tables. You can also change the range of loads that you'll get, and also replace the MAP sensor with another voltage sensor - if there is an offset it could be corrected in the MAP calibration map, although planning is needed as this table also does VE. If we add more layers of tables it is more complex.

One issue with flexibility is support - if there end up being dozens of ways to do it, it will be difficult to help users to tune it.

Of course I think my way is best Discuss...

 

EvoScan v2.6 Beta7 (download available on the other thread) reads and clears Full OBD Diagnostic codes, so you don't need to use Scantech anymore.

 

Last night I couldn't get 2.6 (an older version) to read OBD fault codes. I'll try the latest version.

Forgive my stupidity, I've not looked into this area, but is there a non-OBD fault code system as well?

 

Yes, there is always MUT

 

I've never got MUT fault code reading to work, but I suspect on JDM this is what determines if the CEL is on or off rather than OBD codes. What will read MUT fault codes? Never managed to get this working in Evoscan?

Whilst I could log or correct the internal sensor fault codes, I don't have the overview of how these are converted to a MUT fault and then logged...

 

The more I read through this, the more I like it.

One suggestion is to maybe label the map sensor calibration table something like 'map sensor ve and calibration', so that people understand this is taking into account VE for map, if they want to use it this way.

I would be interested to leave this as a 1:1 relationship and just using the RPM VE table to compensate. In your second worked example you could have changed the RPM you were at to about 77 to come to the same answer. I'm curious if using just the RPM table would be enough.

Overall great work...can't wait to use something like this myself.

 

Yes relabelling to make it clearer would be good.

By far the biggest variance of VE is related to MAP rather than RPM though. Not what you would think until you look at the logs as everyone things of VE vs RPM. If you drop the RPM VE it will go lean at full throttle to make it correct at part throttle.

 

While working with the other MAP to MAF patch I noticed that changing the values would change values for other maps. I would think, to get your patch to work correctly, you will need to ensure that any values in the patch only affet the patch and not other base map values.

Currently the VE table in the MAP to MAF patch will change the Lean Spool tables.

 

Yes, that is because of the actual VE changes from the throttle plate being full open or slightly open. Now I see your point about map, since in that scenario, only map and VE are changing and not RPM.

I'm wondering if the VE RPM table could be set so that the values were all for a 'WOT' condition and and conditions such as idle would be handled via closed loop trims or possibly just add some TPS correction, like one more 2D table. So, instead of map and RPM 2-d, have TPS and RPM 2-d.

That may be a bit messy. I think you solution is the easiest and cleanest. As long as people understand what's going on, I think this is going to be great!