I had tried to consider transport delays, but not sure if what I'm doing with the analysis is sensible.
I binned the TPS and calculated deltaTPS then did a pivot table type analysis in excel to see what the average lambda error was and how the average (actual) pulsewidth was different to the base pulsewidth calculated from the VE map. The transport delays would only be apparent in the lower TPS bins so these can be eliminated from the analysis. I then calculated the average pulse width extention required to reach the target AFR based on the actual AFR and actual pulsewidth.
Does this sound sensible? I could believe the answers.
I think I follow you - ish
To measure the transport delays the easiest way is to sit at a steady speed load site and then make a step change to the fuelling and watch the effect on lambda. So you need to be open loop, and then just add say 10% extra fuel. From the log you will then be able to measure the time delay between the pulsewidth step and the lambda change. do this at a few different speed/load sites and you can plot a rudimentary curve (against airflow) or map (against speed/load) The results should be linear so you don't need many points.
Once you have that bit of data you can more clearly see what is happening in you transient cal, as you will know when to expect a lambda change. This means you can use your proposed method, but you know exactly when to take the lambda data that you will use to make the PW correction.
I find it useful to keep in my head what I am trying to achieve physically. The trans comp requires 2 parts - an intial large but short duration spike, and a longer, lower duration increase. The spike is to replace any fuel that is initially drawn off the wall on tip in due to a delay in injecting. The second part is to actually compensate the wall film for the additional amount required. It is also useful to go
slightly rich during the tip in to improve response and avoid any issues with stumbles etc (most aftermarket 'tuners' seem to achieve this by simply running rich everywhere all the time - OK if fuel economy isn't an issue).
So you want to make sure your steady state VE numbers are correct, then perform step tip-ins from one TPS to another, initially with no trans comp (if it will stand it). Look through the log and identify the shape of the resulting lambda curve, allowing for the transport delay at the initial speed/load condition (calculated from you previously defined map). From this you can identify the required lambda correction during the delta lamda event, and as you say you can then back-calculate for the required pulsewidth increase and ramp out rates. But remeber the timing is quite important, so be careful with using the avarge lamda as that will tend to reult in a lean to rich compensation, which isn't what you want.
As ever, all this is much easier on a dyno so that you can hold a fixed speed, but it is possible to have a good go at it in the car.
Hope that makes some sense...
