I'm going to put this here as I find there are a few people who want to perfect a tune they bought an OTS, e-tune or pro tune that perhaps didn't go the whole hog and deliver perfect driveability. Tuners are busy and time is money, so this is quite understandable. It takes time to dial in larger injectors perfectly and most owners don't want to pay for it.
Why would I do this?
If you've fitted larger injectors you may notice that your fuel trims (Long Term Fuel Trims or AFR Learning) bounce around a fair bit and may be able to feel surging or lurching or generally less than smooth response in closed loop. You may have fuel trims that are a bit staggered, like where A and C are positive values and B and D are negative values.
What are the underlying precepts?
These issues occur because fueling in Closed Loop is done in a pretty simple way, where the ECU watches the MAF signal and RPM to calculate load and RPM and then look up a value in a 3D table, apply corrections to that value, spray the fuel, then look at the AFR via the O2 sensor and make further corrections from there. You can probably imagine that different manifold pressures change VE (volumetric efficiency) to a high degree because of resonance in the intake manifold, intercooler etc. For example, the engine can be at the same rpm and MAFv but flow quite different amounts of air at (say) deep vacuum or slight boost because of the different charge density. Tweaking MAF scaling in the airflow ranges the correction is split into will not resolve these differences and it's easy to end up with a very jagged MAF curve, which is not the right way to fix this. These problems are magnified when larger injectors are fitted because the same small differences in IPW create much larger changes in AFR.
In each 32bit ROM there is at least one table that is used after looking up the base fuel requirement, called the Engine Load Compensation table. There may be one for cruise and one for non-cruise but in most ROMs they are the same anyway. It doesn't make much sense having a table for non-cruise when you'd normally be in OL (open loop) fueling if you're not cruising, so this was probably left for future development work. In most ROMs the table will be 14x11 cells and look like this:
You'll see the table is scaled by RPM and by MRP (Manifold Relative Pressure). You'll notice that in this ROM the RPM axis stops at 3k2rpm and MRP stops at 3.83psi. This is because beyond these ranges you're most likely to be in OL fueling and these corrections would not be applied to the final fuel base anyway.
So where do I start?
First off you want to be confident about your current MAF and injector scalings, plus injector latencies. If you're not, get those sorted first and then come back to this.
You do not need an aftermarket WBO2 setup to tune these tables, though since you have larger injectors you probably have one.
Next, set up a new profile in RR Logger to log just these parameters:
A/F Correction #1 (%)
A/F Learning #1 (%)
A/F Sensor #1 (AFR)
Engine Load (Direct)* (g/rev)
Engine Speed (rpm)
Manifold Relative Pressure (psi)
Mass Airflow (g/s)
Mass Airflow Sensor Voltage (V)
Throttle Opening Angle (%)
We are using the factory front O2 sensor data because that is what fueling is based on, and there are always small differences between sensor readings.
At CANbus speeds about 10 minutes of logging will fill up almost all the rows in a .csv file. You want to capture as broad a range as possible of OL driving, so that all conditions are represented. Cruise a gear lower than you normally would, to get data from higher RPM / lower MRP. Cruise up a hill in a gear higher than normal to get lower RPM / higher MRP data. Try not to waste space by idling for long, as all data from idle speed is rejected. Avoid rapid changes in throttle angle. Try to get data from as high in the load and rev ranges you can while staying in CL.
Go download this wonderful tool our benefactor Airboy made for us here: http://www.romraider.com/forum/viewt...c95cabd#p53407
First, go to the 'ROM' worksheet and copy / paste your stock EL Comp table there. The values are not used for calculation at all, just the axes are grabbed to organize the correction values.
At the 'Input' worksheet you can import your first log file, select your parameters manually if 'Grab Headers' didn't work, and then 'Filter Data'. What this does is toss out all rows of data that are at idle speed or have large changes in throttle position where big corrections are inevitable. In the cells that are valid the short-term corrections and long-term trim values are added together to show how much total correction took place, and we can use that value to then adjust the compensation table to reduce both the correction and trim values in the next iteration of our tune.
I actually prefer working with revision 3 of this spreadsheet vs. the current R5, so I'll show you that.
So the output here shows you how much total correction had to be applied, cell by cell, in the effort to adjust AFR to stoich. The graph on the left will give you an idea of the average and most extreme corrections, and where you need to focus attention on.
At the right are is a table of numbers with the correction values arranged in MRP columns and RPM rows, like the table in the ROM. What you may notice is that the column values are changed. If you didn't put log data at (say) 3.87psi MRP in, you're not going to get correction data out. Many of us run greatly reduced CL-OL delay, or zero it altogether. Those with larger turbos will get into OL at much lower boost pressures because the switch is made according to load and RPM values, not MRP. The output is suggesting in this case we drop the 3.87psi column and add one elsewhere, in this case at 1.56psi. You will note there is never any data in the 700rpm row because this is filtered out as garbage. Idle fueling is not covered here and needs to be approached separately.
This is a good moment to select all the values in the table and see what the average is. In the example above the average of the whole table is actually zero. This means the basic injector setup and MAF scaling are good. If the average of your corrections is much more or less than zero then you have issues with MAF or injector scaling and latency still to address.
Below the table of correction values is a second table showing the number of data points which support the values above. You'll notice that numbers 10 or lower are greyed out, meaning we should treat the correction values with suspicion.
I find that the more data you have, the better the results are going to be. I will normally fill four or five logs with 10 minutes or so of data in CL, then run each one through the filter. Each time I'll copy the results from both the corrections and data point count tables and paste them into the columns alongside, making sure the RPM labels line up. After all the logs are filtered, and the results copied one after another off to the right, I average all the corrections and add all the data points together, like so:
Yes I went a bit bonkers and averaged out the results from eleven logs on this one, to see if I could get the table right on the first try. Make sure the average function actually points to the same MRP column in each copied table and all the RPM labels line up. Remember the 700rpm row is not in play here.
I've highlighted in yellow the cells that came up with few data points (like <10) as you can't consider them reliable. In green are the cells that have correction values of more than +/- 2%. I do not try to get all my LTFTs to zero. I like to see all the LTFT values sitting at a few percent negative and let the system pull a little fuel from all four ranges. It's okay to try for zero but don't let it drive you crazy.
Here's a copy of the file above
to save you a little time.
Now I go back to the table in the ROM and rescale the MRP axis. Where you have to relabel a column you can just interpolate the data from either side to populate the 'new' column. Here's an example of a rescaled table, but note it's not from the same ROM as the example above:
Once you've done that, start applying the correction values you want to use. In my case I am ignoring anything under +/- 2% and only applying the correction values larger than +/- 2%. So, in this case for example for the cell on 1k4rpm and -10.64psi MRP shows us a correction of 4.3%. I'd ignore the first 2.0% and adjust the value in the ROM table up by 2.3, from -2.0 to 0.3, or as close as the input will let you. If you want to try for zero, use the whole adjustment value but be warned it usually ends up with you chasing your own tail.
One more step / sanity check. Copy just the values from your rescaled but unadjusted table and paste them into a blank spot on an Excel worksheet. Look at the average value. Once you've finished adjusting the table by the averaged out corrections, paste a copy of that into another spot and again check the average of those values. The difference between the two should not be that great, and will give you an idea how the LTFT values should move. If you have really big changes, like more than a few percent, go back and check your work.
Go flash the new ROM file to the car, and make more logs, rinse and repeat. If you follow the above instructions it should only take two or three rounds at most to get your B, C and D range LTFTs small, flat and very stable. In the example shown, using 11 logs to average out, I was able to get this job done in one go.