I turned off O2 feedback then:

Start engine, and hold revs at 5000 RPM, started datalogging, and while datalogging:
- increase fuel injector PW by +10% (in my AEM I did this with the overall fuel multiplier)
- decreased fuel inejctor PW by 10%
- repeat every 2 seconds or so

Examining the logs:
- at 5500 RPM my LC1 starts reacting about 180 ms after the injector PW changes
- after the initial 180 ms it then takes about 220 ms to rise (or fall) to the new O2 value


At idle the LC1 takes 500 ms to react and 700 ms to rise/fall. The latency is due to the engine operating parameters, not the LC1. This is also why you can't have closed loop O2 react very quickly at idle, and why ideally you want the O2 feedback speed parameters to be a function of engine airflow (i.e. RPM x MAP).

I compared a new sensor vs. my old one which had seen thousands of miles of oil burning, and surprisingly the old one was only marginally slower at the 5500 RPm test like 30 ms slower. Obviously at idle the difference is negligible.

An interesting observation is that with the new sensor the response shows ringing (like an underdamped PID loop), while the old one doesn't.

 

Here's my guesstimate lambda delay from datalogs based on the AFR's reaction to excessive throttle enrichments (PW goes way up..... then AFR goes way down).

 

is that table only used in VEAL?

 

Thanks Jason. That's good information. Your test indicates that it is best to time O2 correction increments by ignition events rather than by msec. That's how I'm currently setup.

It would be nice if we could specify a table of delays while fuel tuning with VE Analyze. I think going forwards that I will run VE Analyze multiple times with varying delays and then populate a final VE map accordingly.

 

Good idea. Is that on MS3?

BTW MAP would also affects response time. More MAP = more airflow = faster flow = shorter delay

 

y8s, I think the delay should be 100 ms + factor / (MAP*RPM)

Factor is such that you get 1.2 sec at idle.

 

It's on my MSPNP, so I would be shocked if it's not on MS3.

Understand about MAP. That's why I suggested a delay table. Would be a cool add to MegaLog and TS.

 

so essentially the table is superfluous?

(1200ms - 100ms)*35kPa*950 = factor

factor = 36575000

so then my table becomes:


compared to:

 

I think the problem is that the delay is proportional to 1/MAP, but the MS does linear interpolation. You may want to figure out what to put in the 10 kPa row to minimize RMS interpolation error from 35-90 kPa. (<30 kPa isn't as important)

 

I could change the 10 to a 30 and let it use off-table values for <30. breakpoints are totally flexible.

I suspect also that once you're down around 200-something ms it becomes much less critical--especially when you're squirtng a much larger duty cycle at higher boosts

If I bring the 10 up to a 30 and recalculate the value, the rest should be pretty reasonable you think?

 

Ah, if you can change the breakpoints but are limited to 3x3, then you can mathematically choose said breakpoints to minimize the error the matters. i.e. maybe the RMS of the log of the error is what matters most.

 

It has been some time since lambda delay was discussed anywhere in this forum. What have you determined since then? What values did Y8s or anyone else end up with and why?