Thanks john, I have just changed my rom to show those values.

I will flash it in again tomorrow, and see how it reacts.

I also plan to wire up the MAT sensor tomorrow (weather permitting), so will try and get some good logs with and without the maf connected

 

John,

If you ever want me to use LogWorks for the log analysis like I did with Tephra's, just let me know. I think LogWorks does it correctly, so it may be a bit easier.

All of this looks great. I have to order some ECU pins and get my map sensor and GM IAT fed into the ECU now. Hopefully, by that time, the patch for my ROM will be done.

 

Definitely easier on the DD guys that need minimal downtime

 

Attached are the original logs of a single commute journey in my car when I ran the MAF sensor. The counts show the areas I used most often, so I ignored the transients with low counts. All I did to tune mine was read off the values, giving the original VE curves I showed in post #1 that were quite close.

You can see why on mine I had load=MAP since the full throttle is about 100%. Maybe others with different induction systems will get a divergence - cossie1 at WOT seems to be 91%.

 

Would that be because I still had the maf connected or maybe due to me using the HKS induction instead of the stock airbox ?

 

The percentage I'm referring to is 2byteload divided by MAP(kPa).

 

Sorry I mis understood what you were saying.

Sorted now

 

Not to do with the MAF still being connected, probably related to the HKS induction - you've mapped around an airflow meter misread, and now we're emulating your misread

 

Now I know what your saying.

SO with that in mind.

Once I (we / you ) get the emulation of the misread correct, to prove that my car will run perfectly well with SD.

Would I be better off, then setting the rom how it originally was (as the car does run), and then remapping it, so it isn't emulating a misread that is no longer present ?

 

You might be able to run my RPM and MAP VE setup on a stock fuel and timing maps, and then just tune from there. I tend to think in boost terms, so I like having 100% VE in the open loop areas except a drop off at high RPM. You can do it however you like, load can be an abstract, unitless value that just makes you land on a certain area of the map, or it can reflect your own version of reality

 

Well lets get it running correctly first.

As you know, I have some changes planned very soon for my setup, which would mean a full remap anyhow from scratch as I feel it would be a) a better map and b) probably much easier, than just adjusting it from the current map I am running.

 

I loaded up my MAF ROM and did a fairly comprehensive log of baro+airtemp corrected load vs RPM and MAP. If the goal is to exactly match load from SD to load with MAF, then I don't think that separate RPM and MAP VE tables is going to do it. Below about 160 kPa, load is invariant with RPM, and from ~160-220 kPa, load increases with RPM out past about 3500 rpm, and from 220+ kPa, load falls off with RPM out past about 3500 rpm. I suspect that MIVEC is playing a role here.

 

pic of what u mean? if you are talking about the spike in load at spool then thats normal - incorrect MAF behaviour

also I keep running this through my head, if I use GM IAT at the ADC input (as per V2 patch) then log my MAT (in MY CODE, not stock) vs the MAFIAT its the same... so doesn't that mean the stock ECU scaling is working fine for the GM sensor?

 

The plot is at work. After thinking about it a bit, I've got it backwards. The RPM VE is still flat at low MAP values, but at the mid MAP values, VE goes down with RPM, and at the high MAP values, VE goes up with RPM. I obtained the logs similar to what 03whitegsr suggested. I'd hold the car at constant RPM and play the brakes against the throttle to run though the a range of MAP values. I need to do some more logs this weekend to verify.

Are you comparing the GM IAT scaled using the stock IAT scaling table vs GM IAT scaled using your own scaling table?

 

You could go to a 3d table of RPM vs MAP vs VE very easily in the code. I wouldn't recommend it though without live tuning AND the patience of a saint, and it won't drive any better than a well calibrated pair of RPM and VE tables - which on my example drives so that you can't tell which sensor you're driving off except it is smooth on lift off on SD. When I've done 3d tables before, the small trends I think I see are not consistent or are based on transients with low sample counts/rates. Make this too complex and you'll never get it right and it will rapidly turn into your worst nightmare.

Constant RPM and playing the brakes and throttle can give unrealistic results for real world use whether you use MAF or MAP as your source, as you're stopping the car accelerating in cells it would usually accelerate in. I get best results by adjusting the values based on their real/common use. Then the transients off idle are nice.

I always find the vacuum stuff hardest, the boost stuff is really easy. I'm also very fussy, but the only issues I usually find with SD (whether an emulator or an SD ECU) are getting the compromise between idle, over-run, cruise correct. Boost is always a smooth, easy to tune experience on any car that is mechanically sound. I'll do the full throttle stuff across a wide RPM range in an intermediate gear, part throttle boost is harder because holding the same boost across a wide RPM range is difficult, a loose proxy is to use actuator pressure, but then it becomes a full throttle map. RPM locking on a dyno or left foot braking also gives a false impression. Recognising this, I just take the points I can and smooth the rest, deliberately avoiding the sorts of humps and lumpy maps that logs would suggest. The car drives smoothly, does good gas mileage, is safe, and is easy to control in corners on the limits of adhesion.

Using an 8 point map of simulated MAF voltage against VE % on the Power FCs on the Imprezas we had no problems with everything from 9 second drag cars to daily drivers - except for transients which were a far bigger headache than VE, but thankfully we are not having issues with on the Evo once the VE is right.

For now, I strongly suggest keeping it simple and filling out the numbers the engine wants before making more complex tables.

I reckon I could let any of you drive my car and you would not know it was SD except for the smoothness on lift off. I can no longer tell the difference between the datalogs and have actually mixed them up accidentally thinking an SD one was MAF when I wasn't noticing that the baro was not changing and MAT=IAT.

Don't think I'm being patronising with my suggestions, but I've made airflow estimation into engines my specialty over the years and know what I'm doing, I've studied and experimented with this for years. This conversion is my best yet, up there with MoTeC. I wouldn't swap to a MoTeC if you gave me one for free - it would go on Ebay straight away and I'd keep this.