I spent a miserable amount of time tuning the lower portions of the VE table yesterday after work. I got them dialed in to match the commanded 13 AFR, then commanded 12 and 14 AFR to see if the fuel compensation was correct, I got this:
notice how the AFR almost instantly pegs high, or low?
This kind of step lead me to believe the flow value for the injectors was off, first, I found that for some reason I changed base fuel pressure in the tune to 39.1 instead of 43.5... I fixed that, retuned the VE table to match the commanded 13 AFR, and tried again, no change. so I adjusted injectors flow up and down to see if any improvements were being made, and I really wasn't getting much change. so I began playing with injector dead times, bumping them up and down to try and see a trend, maybe they were off? I wasn't able to find much by adjusting dead times, eventually, I adjusted them WAY out to see if there was any change, and making them about 3.5x longer than what I started and got them generated a change in AFR closer to the commanded change, to adjust to that kind of value throws everything else off, at that point, my VE table had a peak of something like 40%.
after all of that, I have verified the data for my injectors off of 2 different sources, so I think it's reasonably accurate. I set my fuel pressure via a pressure gauge, and my pressure transducer that I log agrees with that pressure at fuel pump prime, as did a separate test gauge, my fuel pressure, is set to 300KPA in the tune, which matches the pressure from the other instruments. I have come to the conclusion that my injectors, although being new, with low miles/hours, might have something wrong with them? Dirty? ethanol shenanigans? something?
Fuel settings:
Current VE table:
insight would be appreciated if you have some. that being said, drunk me bought new fuel injectors last night, from FIC, that have all of the parameters defined for an MS3, so when they get here, I'll pull the plenum and put them on, and hopefully won't have further issues.
Beyond that, in this tuning series, I was able to gleam a important data point from this tuning session, Lambda delay time. because I was commanding a distinct difference in AFR, and the PCM was making a stepped change in PW, and generating a step change in AFR, it was very easy for me to see that it takes a whopping ~1.3 seconds average for the O2 sensor to register the change, in the MS3. (I checked several spots, average was ~1.3, this point was ~1.4)
this is only part of the equation though, delay time has two major contributors, one fixed delay, from the O2 sensor interface, the time it takes the interface to read the signals from the sensor, calculate a 0-5 volt output, and send the output, which will be the same all the time, and a variable delay, which would come from the time the exhaust has to travel to get to the sensor. These two factors are separate in the MS3 EGO control schemes, the fixed delay is under "AFR/EGO control" to adjust this value, you will need to enable EGO control if not already done, then enable the delay table. I got the value in this menu from the O2 sensor manufacturer, for a 14point7 Spartan 2, this value is 100-150ms. so I set it to 126(it only accepts even numbers)
for the variable delay, we have to inspect the datalogs, at idle, this is pretty easy, change the commanded AFR, PW should be relatively static before and after, so you can measure the time it takes for the change in PW to generate a change in AFR. next, take that time, and subtract the fixed delay from that time, and you have your first data point. alternatively, you could set the fixed delay to zero, and put the total delay in the table.
I said idle was easy, what about the rest of the RPM ranges? they probably won't be that much harder. but I haven't yet tested them, the trick to getting reliable data is to have a stepped change in AFR, due to a stepped change in PW. at power, it would probably be advisable to make this change a step richer, as opposed to leaner, but your tune will determine the safest way to do this. if you can make the change in AFR happen at the slowest RPM change possible, that will also give you the easiest data to read. My plan to get the delay data is to use the table switching functions of the MS3.
first, enable AFR table switching use one of the "Loop" triggers, this will allow you to edit both AFR tables. Next, transcribe your primary AFR table to the secondary, I use the table export feature. then highlight all the cells you want to include in your testing, in my case, the only purpose of this table is to test, so I highlighted the whole table. then change the commanded AFR by an amount that will generate a stepped change when the table switches.
Next, you'll need to configure the loop, the loop is basically a software based I/O, they're in the manual under "7.8.24.1 Loop conditions" set the active condition to whatever RPM value you want to test, make a few pulls, then repeat for the next RPM value.
as a general rule, the lambda delay should be long at low RPM, and short at high RPM, and low at low load, high at high load, with RPM being the dominate factor. most other variables for lambda delay are relatively fixed on a running engine, your exhaust size rarely changes, the O2 sensor distance from the port doesn't change, so this method should allow you to generate a viable table with minimal effort.
I did a bunch of searching and was unable to find any method to better do generate the delay table, if you have a better way, I'd love to hear it.
there are at least two other lambda delay tables, but I don't think either are associated with the tune, or even stored in the MS3. one is in Tunerstudio, the other in Megalog View. both are used for the autotune features in each program, and to maximize effectiveness of the programs, it would be a good idea to adjust the delay values too, I would use the same method I outlined above.
I don't intend to tune the delay table until the rest of my issues are more well sorted out though, it was just a tangent that I spent a little time on last night because I want to eventually dial that table in.
