Hi guys,
I have finally got my long term project motor on to the engine dyno. It's an Evo 6 motor using an Evo7 ECU and Tephra 9055001 ROM that came with the car when I bought it. I have modified an Evo 8 MR wiring loom with Evo7 ECU plugs paralleled up with the Evo8 MR ECU plugs so that the loom can be used by the workshop I'm at to tune both Evo 7 and Evo 8 and 9 ECUs down the track. I've run the motor up for the first time today and immediately struck a few issues.

1. The Innovate LC-1 I've got connected through a USB/RS-232 converter immediately connects to COM 10. I can read it fine using Innovate's Logworks program but the only COM port options Evoscan gives me is Com 1 and 0. When I do go to com port setup and force the PC to connect to the innovate using Com 1 it will read for a few seconds but then it simply locks up and I cannot get Evoscan to read the LC-1 after that. Why can't I get Evoscan to offer me any ports other than COM 1 and 0?

2. When I log Fuel Trims using Evoscan all of the LT fuel trims sat at 0 after I fired it up. The min temperature for closed loop is set at 20 degrees C in the ECU so this should not have stopped it going into closed loop because of coolant temp. When I did finally get something to budge in the fuel trims it was Fuel Trim High (LTFT) and Fuel Trim in Use (LTFT) that bumped up to 0.9% and just sat there when coolant temp reached 87 degrees C. I ran the motor through all load ranges, idle and cruise with both those LTFTs sitting at 0. Is there somewhere else in this ROM which forces the ECU into open loop that I am perhaps overlooking?

Many thanks if anyone can help!

Cheers

 

It looks like EvoScan has a bug when the COM port has 2 digits in it. For example if I force my com port to COM27, then EvoScan shows:






Shows entries for COM2 and COM7, not COM27. Which is... wrong.

What I think should be done in this situation is to go into your COM port settings in Device Manager and assign your wideband any available COM port 1-9.

The dialog that allows setting the COM port number is here:
Device Manager -> COM Port Properties -> Port Settings tab -> Advanced button

You sound like you know what you're doing, but the LTFT is a bit quirky.. a search on the forums should get you a pile of information on the behavior of LTFT. The short version is that the Evo calculates updates to the LTFT value only every 4 minutes or so in closed loop. The LTFT will not be affected by changes to the STFT except in a short window every 4 minutes. Perhaps this is what you're seeing.

If what you're seeing is definitely not normal LTFT behavior, then I don't have any great advice, only general troubleshooting ideas. It sounds like you've frankensteined the engine+ecu combo a bit. Perhaps there are some sensors you have installed which aren't compatible with every ECU, and the ECU won't go into closed loop if its getting erratic readings (STFT works? HO2S test passed?). A place to start might be to log as many sensors as evoscan allows and see if any look extremely out of range.

 

Thanks for the response. I did discover the bug you speak of! I ended up reinstalling the drivers for both the LC-1 and my Serial to USB converter. Suddenly Evoscan would now offer me the com port that the LC-1 was on without me having to force the LC-1 on to a COM port that Evoscan offered me AND it wouldn't lock up anymore after a couple minutes so that was great.

As far as the trims not updating I reflashed the ECU, cycled its power and then the long term trims started updating every 4 mins as expected. So far so good.

Just for some background my motor is an Evo6 with an Evo7 ECU running the 9055001 ROM. It has 1300cc FIC injectors and I intend to tune it on E85 after I get my head around what I'm working with on 98 which is what it has run on in the past. You have to keep in mind that I purchased this car with many of these modifications already done so a lot of what I'm dealing with are mods made by the previous owner which I have no information on. I am completely new to the Ecuflash EVO tuning world and am struggling with this after understanding other OEM and standalone ECUs that utilise speed density or MAF or hybrid virtual volumetric efficiency mapping.

I've run up the car with the tune it came with when I bought it as a starting point and am finding some frightening air fuel ratios coming up. It would track the AFRs in closed loop operation nicely with LT trims hovering around +/- 2%. However as soon as I went into open loop with load in the 100-130 range if I had filled the Fuel table above load 100 with 11.5 AFR values my measured AFRs would be in the 14-16 range!

I looked at the MAF Scaling table and really want to get my head around what it represents.


If this table is meant to represent Mass Airflow as a function of the Frequency Output of the sensor then why is the sensor output not a function of the airflow rate? By this I mean how can two frequencies represent one mass airflow number? As an example, if the sensor is flowing 472 grams/second then what frequency should it output, 805Hz or 1409Hz?

To answer this question I stuck my MAF sensor on a flow bench. I ran it from 3 cfm to 480 cfm. This corresponds to 1.7g/s (3cfm) to 246 g/s (543 cfm) mass airflow.



I connected the ECU to it and logged the Load (at 4000 RPM) over this airflow range and got an exponential-ish line going from load 6 at 20Hz to load 347 at 1580 Hz. I was quite lucky that the superflow bench I was using had just been upgraded to just achieve 543CFM = 1580Hz give or take.

This is what I got.


Clearly this plot is a function and there is no ambiguous data in it such as one frequency corresponding to two airflows (as you would expect). The x axis is actually incorrect in that it should start at 20Hz and not at MAF Hz! It should also end at 1600 Hz but you get the gist of it I'm sure. I didn't spend too much time tidying up my excel plot, I really just wanted to see the shape of the curve. So the first takeaway from this is that the MAF scaling table must be mislabelled and does not actually represent airflow in grams/second versus MAF output frequency as it states. However from looking at the slope of this curve it becomes pretty clear that the MAF scaling table is actually a representation of the slope of this curve.

When I plotted Load against cylinder charge per stroke in grams I got an almost straight line which again made perfect sense given that the load is supposed to represent this value linearly. (Blue line is the MAF response, brown line is a straight line for reference). I ran the load versus airflow test at varying engine RPMs (by triggering the crank sensor input with a frequency synthesiser) to give me the best resolution so this plot was normalised for 1980 RPM and thats why the load values are so high. If the motor could ingest that amount of air at 1980 RPM then the load values shown would be true for those charge masses shown..

Please excuse that my axes are not labelled as I'm in a hurry doing this but the x axis is cylinder charge per stroke in grams or air and the Y axis is my load value read from the ECU (normalised to 1980 RPM). Clearly this will require some correction to make the load vs cyl charge line totally linear.

Now my question is, given that I have now characterised my (presumably Evo9) MAF, how do I correct my MAF scaling in my tephra ROM to compensate for this slightly nonlinear Load versus cyl charge plot? I have no idea how the real world values I have measured are represented by that strange curve in my MAF scaling table. (I suspect the answer is going to be that the MAF scaling table is not actually grams/second vs frequency but this table actually represents d(flow rate)/d(freq) so something more along the lines of (g/s)/(MAF Frequency) versus frequency which is the same as grams versus frequency.

My three MAF tables in the ROM are MAF Size, MAF Scaling (MAF Adder added) and MAF compensation.

Has anyone got any knowledge of how this ROM converts the MAF frequency into the load values via the MAF scaling and MAF compensation and MAF size tables? I have read through a few of the (very old) threads concerning this but have got so much conflicting information from them I thought it might be timely to ask the question again. Is the MAF adder in the scaling table simply my MAF size which is around 357 g/sec (sic) from memory. Should MAF size actually be stated as airflow/second/Hz?

Just for info, I have found that I have very little headroom on my MAF Scaling table as it maxes out at 495 however I do have lots of range left in my compensation table. And I have had success in adjusting the compenation table above 270 Hz in lowering my open loop AFRs so that they were a lot closer to what was in the fueling MAP. So I guess I have a solution but I would really like to understand what is going on so that I'm not just doing this by trial and error but rather by reading an AFR error and adjusting my MAF calibration accordingly.

 

It's amazing what difference a day makes. Having slept on this issue and then enlisting the help of a mathematician at my work I think we've cracked this nut. Of course everything I'm saying here might actually already be common knowledge amongst some who access this forum but in the absence of any responses to my question I'm thinking maybe not. I may as well quickly add to what I've previously posted firstly to correct any erroneous stuff I may have already stated as well as explain what I have discovered in the past 24 hours. I'm about to pop the engine back on the engine dyno having taken a four day break for actual customer engines. I should have an unrestricted two and a half weeks straight to play with the motor before the next customer booking.

After some analysis I have come to the conclusion that the MAF scaling table appears to be the derivative of the mass airflow versus frequency plot. This means that the values in the table represent the slope of the MAF vs MAF Frequency relationship. This also means that if we assume that the MAF vs MAF Freq starts at the origin then the value of Mass Airflow at a set frequency is proportional to the area under the MAF Scaling curve up to that frequency point that we are concerned with. You can see this phenomenon occurring in my plots in the above post. You can see a point of inflection at approx 1000 Hz in the Load vs MAF Hz plot. (Please allow for the error in the horizontal scale due to my terrible excel skills). There is another less dramatic one at 1400 Hz which corresponds to the kick up in my MAF Scaling table at 1600 Hz. The reason the inflection occurs below 1600 Hz even though the change appears in the table at 1600 Hz is because of the way the ECU interpolates between points in tables. This also means that the MAF scaling curve units are actually grams not grams/second as it represents a slope on a grams/second/Hz versus Hz plot. (g/s)/(1/s) = g.

Now why do the Mitsubishi engineers represent the MAF versus Hz relationship in such a way? One theory we came up with has to do with the fact that the precision available if we represent the MAF vs MAF frequency function as a table will produce large errors at low flow rates due to the rounding errors incurred as a consequence of using an 8 bit integer to represent such a widely varying parameter. However if you characterize a function by using its derivative values then the error will accumulate from very small at the start increasing as you integrate the curve to the higher values. This means the error will be small when the MAF vs Hz values are small and they will remain in "proportion" to the number you are representing as you make your way up the curve.

The take away from all this is that if you tweak any value in the MAF scaling table, you do not change the MAF vs Freq relationship at that point but you simply change the slope of the line at that point. Therefore a change at say 400 Hz will end up being integrated and will end up as an accumulated change over the rest of the plot above 400 Hz. I can imagine that if this is not realised by someone tuning their car it will result in much head scratching when they start to wonder why a change low down in the scaling table is affecting their AFRs in the upper end of the load range.

Now I suspect the person who previously tuned this motor put that kick up at the top end of my MAF Scaling table as a "safety" in case the motor ever exceeded a MAF frequency of 1600 Hz thus ensuring that the AFRs would not lean out too much as the MAF maxed out. However as you can see from the MAF vs MAF frequency curve this massive jump in the MAF scaling number has had little effect on the MAF vs MAF frequency value at 1600 Hz as measured on the flow bench!

So what is the MAF Compensation table all about? I suspect this is the final "tweaking" table which allows us to fine tune MAF values at specific frequencies without affecting the overall "slope" and up range values of the MAF vs MAF frequency curve. Had he put the kick up in this table instead then we would see a massive jump in my MAF vs MAF frequency plot at 1600 Hz and the "safety factor" he or she intended would be real.

Now the $64K question is, given that if we assume that the MAF vs MAF frequency plot starts at the origin, we do not need any "offset constant" to help characterize this curve. Then what is the MAF Size number all about? I'm surmising it's just the "MAF Adder" used to offset the MAF scaling curve up into the three and four hundred region thus allowing finer adjustability up in that range. I need to get onto the ECU and start changing this number to see if it does feed through into the offset of the MAF Scaling table but aren't able to at the moment. Any input here would be greatly appreciated.

I am tempted to stick the MAF back on the flow bench and tweak these MAF scaling values to test and hopefully confirm this hypothesis and also see if I can get my Load vs Cylinder Charge per Stroke plot dead straight. Alternatively please feel free to just chime in and tell me what I've just stated is actually the case or conversely that I'm just talking out of my ****

One last completely unrelated question. Where in this ROM can I turn off closed loop boost control so I can get my open loop setup first before turning on closed loop?