VCM Scanner - Wideband Delay vs Table Data - Need Extra Option?

[BigDaddyCool]

I'm just putting this out there........

Is there any way to match what the ECU Reports on say your 'Chart vs Time' vs the wideband data so they line up? Essentially I've noticed an average 0.9 second delay in the lower 1200-1800rpm area from the fuel events going on in the engine vs what reaches my wideband. Now clearly this is different for everyone else and I'm not sure if it's just my PID timing or not..... but atleast how I think well there would be a delay from the engine fuel down the exhaust to the wideband depending on the distance etc.

What I commonly find is I cannot determine for sure where say closed loop vs wide band data correlates together. Closed loop might be report pulling fuel on LT's and being lean on ST's... with the wideband being negative or positive etc. The problem is given that the wideband by default 'in real world conditions' has a delay before the air/fuel mixture reaches it I feel like the 'Chart vs Time' table almost needs a rubber band type effect for reporting the wideband data to closely show it more accurately on that table against other pids if any of this makes sense.

Clearly the wideband delay in the engine would be determined by many factors......... so it would need to be like a RPM vs MS delay etc. Just food for thought.

I probably will be selling off my v8 to downgrade to a 'family car' but I'm trying to finish up my own V8 before selling it etc.....

PS. I know there is no RTT for Gen 4's..... but it would have been great if you guys had the ability to perhaps create a virtual O2 closed loop tuning process which I think may be possible? So you could workout the integrator delay vs proportional while driving to bring the LT's and ST's into line...... would make the process a million times faster each time comparing it to wideband data.

[dr.mike]

I think what your a looking for has been discussed before. Usually, this turns out to be the result of the response time of the wideband. Especially older units with the NTK sensors. The data for transition events can be "smeared" over hundreds of milliseconds.

See: https://forum.hptuners.com/showthrea...Wideband-Input

This is why the manufacturers toot their horns about response times so much. Although, they never seem to take the time to explain it.

[g26er]

I think he's referring to the actual combustion event and the time it takes for that events exhaust gas to reach the sensor. The further the sensor from the exhaust port, the bigger delay. He mentions being more pronounced in the lower RPMs which makes sense because the velocity of the exhaust gases are slower creating even more of a delay.

@BigDaddyCool - Is that what you're talking about?

Back when using other tuning solutions (Subaru platform). I'd bring the data into Excel to filter it and shift the WB row over one column which wasn't a perfect solution but, the data lined up much better.

[dr.mike]

Could be. But, usually, exhaust gas transport velocity at idle is greater than 15ft/s

Some quick, back of the envelope, calculations:

5.0L engine 2.5" exhaust ( single free-flow ) 1200RPM

1200RPM = 10cycles/s ( 4-stroke )
5.0L * 10cycles/s = 50L/s = 50,000cc/s

( Exhaust volume has to be greater than the engine displacement to run under its own power. )

2.5" tube has a cross-section of 31.67cm^2

50,000cc/s / 31.67cm^2 = 1579cm/s ~= 15.8m/s ~= 51.8ft/s

Halve that for dual exhausts and you get about 25ft/s. So, to get 900ms delay latency, from gas transport, you would need about a 22ft long exhaust run. And the sensor in the tail-pipe.

On the other hand, the t63 response time for an older NTK/NGK wideband can run about 700ms-1000ms.

[BigDaddyCool]

Correct. You can slow other pids to more align the wideband delay etc but yes I'm talking about the combustion event delay to the wide-band sensor etc.... real world.

[g26er]

Correct. You can slow other pids to more align the wideband delay etc but yes I'm talking about the combustion event delay to the wide-band sensor etc.... real world.

I wonder if you could create a math parameter to look at the WB data some ms later using slope() function. See screenshot attached. My example has 200ms but, this could be adjusted to line up better to what you're seeing. (forgive me if I'm using slope wrong)

WB Offset.JPG

[g26er]

I wonder if you could create a math parameter to look at the WB data some ms later using slope() function. See screenshot attached. My example has 200ms but, this could be adjusted to line up better to what you're seeing. (forgive me if I'm using slope wrong)

Just wanted to bump this as I've actually tested what I wrote in my previous post and it seems to work by creating a math parameter for a delayed WB reading.
Here is my math parameter which in this example is a 100ms delay ( [36.238.slope(-100)]+[36.238] ) which may or may not be an interpolated delay depending on update frequency. Should still be a valid representation none the less. You'd change the 100 to however many ms delay you wanted.
math.png

You can see in this first sample grab the WB is "Lambda" is 1.001 and our 100ms delayed "WB Slope" is 1.000.
first sample.png

In this second screen grab, "Lambda" is now 1.002 and our delayed "WB Slope" has now caught up to the previous reading and is now 1.001.
second sample.png

If I would to move ahead another 100ms the "WB Slope" would be 1.002(the delayed reading) and "Lambda" would be whatever the WB is currently reading at that current time.

I know most don't use a delayed reading, including me but, I think this is the best way that I know of to do it using the tools HP Tuners has given us. Hope it's helpful.
*If anyone sees anything wrong with my math, please point it out... always learning.