Post Process AFR based on delay table

[vw_chuck]

IS there a way to apply the delay table delay and show what AFR is actually being used in the ECU using table generator? The delays in my table are set correctly (based on visually getting them from a datalog) but the AFR values that the ECU is actually reading in table generator are way off. My sensor is a few feet away from the engine so there is quite long delay. It seems like autotune is having a real hard time. It actually moves the mixture in the wrong direction is many cases. ANy ideas?

[LT401Vette]

Which delays?
MS3: EGO Sensor response time & EGO Delay Table?

TBH, I'm not sure how the firmware is handling those 2. My speculation would be: delay = egoResponseTime + delayTableLookup.

But, then how is the firmware handling that end delay?
Is it like MLV & TS use the Lambda Delay Table?
Or is this just a delay of how frequently it calculates if EGO Correction needs adjustment.

The complexity in doing it as MLV & TS do it, is that you really don't delay the EGO values as that is the lagging value. So, what you really have to do is delay every other value in the fueling calculation and use the current Lambda.

For example, if your current delay is 200ms.
You have your current AFR/Lambda, but that is based on what was being done 200ms ago.
So, you really need to know what was MAP, RPM, VE lookup, etc... From 200 ms ago as that fueling calc is what produced the current AFR.

Now the firmware guys may just be tracking what the end fueling calc and target AFR was that period ago and correcting based on that?
But, I'm guessing.. I would need James to clarify.

[vw_chuck]

Yes the delay table and the ego sensor response.
I have never gotten a definitive answer as to how the code works. I did get a response once and was told that the ego code runs at the delay table rate so if you have a 1000ms delay at idle it is sampling every 1 second at idle. This approach would NEVER work if you want the EGO control to actually keep up with transients in anyway. It should be running at a fast rate regardless of the delay table but like you said it will require memory to be able to look back or look forward to see what the AFR is.
I am looking for a way to accomplish this in a post process kind of way. So lets say we run the code at a high rate of 1 ms (not the delay table rate) and look forward to see what the AFR is based on the delay table and ego sensor delay. This way it should be able to keep up during transients also and be more accurate.