Wideband Lambda delay compensation

[DerekAE86]

Is there a way outside of transient lockouts to account for the time delay from injection event, combustion, wideband detecting a change and then sending that feedback to the ECU?

I expect this value would change with RPM as the combustion event has happening at a higher frequency and with higher loads the manifold and exhaust pressure would assist in the travel time of fuel into the combusion chamber and then out past the wideband sensor. And I assume it would vary with sensor age, controller brand and if it's analog or CAN based on top of the engine's physical traits and current operating range. 

But I was curous so some basic testing just changing the fuel cells from rich to lean and logging how fast the reaction is.
On my engine holding at idle (with no load) it takes around 600ms from the new fuel value being commanded to the ECU seeing a change from the wideband, then of course another 600ms for any CLL corrections to be made and seen.

This doesnt seem like a insignificant amount of time. Obviously when correcting fueling "live" there isnt much you can do, but I would assume this has a significant impact on LT CLL or using the Mixture Map since the initial reading may be transitioning through a incorrectly tuned cell, but by the time the ECU receives feedback from that you've moved into a cell that was already tuned correctly and any adjustments made there will be wrong. And this is where transient lockouts are used.

But it would be nice to be able to "back date" the correction data for LT CLL or the Mixture Map if possible

This leads me to a question about the Mixture Map "samples" option.
Is that "total" samples for that log file, eg: during that session there must be data for that cell at least X times somewhere in the log.
Or is it a threshold everytime you enter that cell, eg: you need to have X concurrent samples from that cell before any additional ones are utilized? Then when you leave that cell and re-enter the count is reset.
 

[essb00]

What does your current 'CLL Update Rate Table' and 'Gain Control Table' look like? How far is the O2 sensor from the exhaust port?

Well, remember CLL corrections are supplementary to just correct small target deviations, but you really should not solely rely on it as it would still be a lot better when your fuel table and 'charge temp approx table' are properly tuned.

[DerekAE86]

O2 sensor is right after the collector flange where the cat would sit on a factory car:

As for my rate table:


-60 is overrun, -35 is idle, -20 is cruise and anything above that is load.

I'm not too concerned about CLL itself, it's more about accurately using the LT CLL and Mixture Map as a tool to assist in fine tuning.

[essb00]

Sorry, but you're supposed to actually turn off CLL (or any fuel corrections/trims) if you want accuracy on Mixture Map tuning or Quick Tune...

[Electredge]

10 minutes ago, essb00 said:

Sorry, but you're supposed to actually turn off CLL (or any fuel corrections/trims) if you want accuracy on Mixture Map tuning or Quick Tune...

you can leave it on if you use a math channel

 

[DerekAE86]

13 minutes ago, Electredge said:

you can leave it on if you use a math channel

Yes this is what I do

[essb00]

@Electredge yup...  I actually also have that Math Block saved as well.

Going back to @DerekAE86, as you may have already figured, you're not supposed to correct the already corrected values in the data logs. ... but about the delay, it is why steady state tuning (in the dyno) is the most accurate way to it.

[DerekAE86]

As above I'm already using the math block to correct for "pre corrected" values. But that doesn't take away from the origional point of the post.

Even if you lock out CLL from making corrections and then utilize the mixture map how it was intended there is still the issue of this delay.

[Adamw]

So there are really two things being discussed here - 1), How system response time is handled in CLL and 2) how the same delays are handled with the mixture map function.  Firstly, an explanation of what im referring to as "system response time", there are two main factors that contribute: Transport delay - this is how long it takes for the effects from a change in injector PW to arrive in the exhaust gas at the Nernst cell in the sensor.  Sensor response time - this is how long it takes for the sensor to determine lambda or oxygen content of the gas after it has reached the measurement chamber.  

The transport delay part varies hugely - mass flow is the main contributor, but there are many other factors - exhaust pipe volume, injector timing, cam timing etc all have some influence. The sensor response time is less variable but still significant.  Factors like gas temperature, gas flow and how far away from stoich the exhaust gas is, influences the response speed.  If we combine these two delays, the typical total system response time can vary from about 4s at rich idle to about 0.05s at stoich WOT.   

1. For the CLL control loop:  The update rate table, lockouts for heavy transients, and the reactivation delay generally takes care of the large variation of total system response time quite well.  Since mass flow is the main contributor, the update rate table is best if referencing a variable that is indicative of mass flow such as Injector Eff PW or Air Mass flow estimated, but even just RPM often works well enough.  It is best to have the update rate a little slower than the total system response time if possible.  This is not always possible at idle with our current minimum of 1Hz but usually close enough. 
2. Mixture Map:  The mixture map has no way of knowing what the system response time was for every sample in the log or any way of compensating for it either.  You can only be smart with the filtering or the way in which you capture the data so that more weight is given to samples which are a better representation of steady-state conditions.  

Some logging software does allow you to specify a "lambda delay" for tools like histograms or scatter plots which effectively just offsets all of the lambda sample's time stamps, this can work ok for applications like a race engine where it spends most of its time running above say 5000RPM and 50% TP so the system response time is much less variable, but this type of correction wont help much in the case of a typical road captured log with no thought given about how the engine was operated during data capture.

On 5/7/2023 at 2:55 PM, DerekAE86 said:

This leads me to a question about the Mixture Map "samples" option.
Is that "total" samples for that log file, eg: during that session there must be data for that cell at least X times somewhere in the log.
Or is it a threshold everytime you enter that cell, eg: you need to have X concurrent samples from that cell before any additional ones are utilized? Then when you leave that cell and re-enter the count is reset.

Total samples for the whole log that were within the specified active zone area for that cell. 

[DerekAE86]

2 hours ago, Adamw said:

the update rate table is best if referencing a variable that is indicative of mass flow such as Injector Eff PW or Air Mass flow estimated

Huh that's really interesting. I'd never considered that but it makes a lot of sense. Would you still do a 3d table with pw vs map for example?
I had no idea there was a estimated air mass flow parameter either - unless I'm missing something the help file doesnt seem to talk about it.
How does it work?

3 hours ago, Adamw said:

Some logging software does allow you to specify a "lambda delay"

Would it not be better to allow the user to set a delay - no matter how inaccurate, then not setting a delay at all?
So if the user put in 150ms, but the delay was actually 500ms. It's still closer to the actual than without it.

3 hours ago, Adamw said:

Total samples for the whole log that were within the specified active zone area for that cell. 

Could such an option be useful? "Discard the first sample for each cell"? Since there is a high chance that lambda is actually from a different cell.

But thanks Adam that gives me a lot of food for thought.



 

[Adamw]

2 hours ago, DerekAE86 said:

Would you still do a 3d table with pw vs map for example?

No need for a 2nd axis.  

 

2 hours ago, DerekAE86 said:

I had no idea there was a estimated air mass flow parameter either - unless I'm missing something the help file doesnt seem to talk about it.
How does it work?

Obviously only applies to modelled fuel equation.  Mass air flow estimated is the calculated air mass from the modelled fuel equation using VE and density.   If you are using traditional fuel equation then Inj DC is very closely related to mass air flow.  

 

3 hours ago, DerekAE86 said:

Would it not be better to allow the user to set a delay - no matter how inaccurate, then not setting a delay at all?
So if the user put in 150ms, but the delay was actually 500ms. It's still closer to the actual than without it.

Possibly something that may be considered in the future, not high priority right now as I have never seen it make F all difference.  

[DerekAE86]

39 minutes ago, Adamw said:

I have never seen it make F all difference.  

Fair point lol

How good is in the estimated mass airflow on a ITB setup with poor/low resolution MAP?
And how correct does the engine capacity need to be? as in; a 1.6lt can be entered as a 1600cc, or should be as close to exact, eg: "1587cc"