Transport Delay /Transport Time Constant

[CCS86]

Another log, same conditions, but with transport delay doubled:

I also logged Commanded EQ bank 2, and this showed that logged pulse width seems to only be looking at one or all bank 1 cylinders. Otherwise, the PW would show nearly flat with the way commanded EQ is ~180* out of phase.

I also threw in "WB current", but it doesn't seem to give "less filtered" data compared to WB EQ.

O2 Response_TD_double.jpg


Defined transport delay: 0.351
Logged transport delay total: 0.546
Observed peak to peak: 0.440

[CCS86]

Summary of findings for different defined Transport Delay values, at fixed steady state conditions.

Defined TD:	0.106
Logged TD:	0.350
Observable:	0.470
Defined TD:	0.242
Logged TD:	0.468
Observable:	0.450
Defined TD:	0.351
Logged TD:	0.546
Observable:	0.440

Observations:

• Observable delay stays basically the same (within my margin of error)
  
  
• Logged "O2 Transport Delay total" changes nearly 1:1 with a change in defined value, which makes me question its value at all.

[dtownmikebrown]

I don't know if this has been observed by anyone else, but here's what I noticed with transport delay. I have long tube headers going into a catless Boss 302 midsection with open side pipes on my car, so I had to do something about the transport delay values. It didn't seem like the right approach to multiply by the same amount across the board. I started by taking my logged O2 Transport Delay Total values and subtracting the values from the Delay Constant table. I left the Time Constant table alone and put the resulting values into the Transport Delay table. Some of the values were 90% higher thank stock, others were 15% lower. I flashed in the updated values and drove for about 80 miles and repeated the process again. The second time, my logged values minus time constant were a lot closer to the last transport delay values. The third time, logged values minus time constant were all within a few percent difference from my last transport delay table.

Here's the overall difference from stock after the 3rd try.

TransportTable.PNG

Here's what my updated transport delay values looked like in relation to the time constant table.

TransportTimeConstant.png

Before doing this I was almost convinced I had a vacuum/exhaust leak or a bad MAF. After I did, my fuel trims became a lot more stable and I was finally able to scale the MAF sensor properly across the entire range. Maybe this isn't the right way to do it, but it seems to be working for me.

[CCS86]

I don't know if this has been observed by anyone else, but here's what I noticed with transport delay. I have long tube headers going into a catless Boss 302 midsection with open side pipes on my car, so I had to do something about the transport delay values. It didn't seem like the right approach to multiply by the same amount across the board. I started by taking my logged O2 Transport Delay Total values and subtracting the values from the Delay Constant table. I left the Time Constant table alone and put the resulting values into the Transport Delay table. Some of the values were 90% higher thank stock, others were 15% lower. I flashed in the updated values and drove for about 80 miles and repeated the process again. The second time, my logged values minus time constant were a lot closer to the last transport delay values. The third time, logged values minus time constant were all within a few percent difference from my last transport delay table.

Here's the overall difference from stock after the 3rd try.

TransportTable.PNG

Here's what my updated transport delay values looked like in relation to the time constant table.

TransportTimeConstant.png

Before doing this I was almost convinced I had a vacuum/exhaust leak or a bad MAF. After I did, my fuel trims became a lot more stable and I was finally able to scale the MAF sensor properly across the entire range. Maybe this isn't the right way to do it, but it seems to be working for me.

That's great! I have a spreadsheet setup to do just that. I haven't tried going down that road on a long tube equipped customer csr yet.

Can you post driving logs from before and after the TC modifications?

[dtownmikebrown]

That's great! I have a spreadsheet setup to do just that. I haven't tried going down that road on a long tube equipped customer csr yet.

Can you post driving logs from before and after the TC modifications?

Unfortunately, I don't have the exact log files I was talking about anymore. I'm new to the platform and the software, andI've had a few "Screw this, I'm starting over from scratch" moments where I purged all of my logs and configurations in the process. This was definitely right before one of those moments. The only values I saved were my new transport delay and MAF scale.

I did find a .csv file from a log where I was running a nearly identical configuration. That's about as close as I'm gonna get to before/after logs right now. Here they are.

Log Files

I noticed a big difference in the part-throttle fuel trim vs load values. Calculated load on the left, air load on the right. The difference is a lot more dramatic if I reduce the y scale range and add transient and closed throttle values back in, but I think you can still see what I mean.

Stock TD
BeforeTD.png

New TD
AfterTD.png

Using data from after TD to update MAF scale
AfterMAF.png

[CCS86]

The only thing that makes me suspicious of the "Logged TD" minus "Defined TC" approach, is that you got some values lower than stock.

With long tube headers that move the sensor significantly further from the cylinder, plus have a significantly larger diameter primaries; there just isn't a way I can think of that transport delay could decrease.

[dtownmikebrown]

The only thing that makes me suspicious of the "Logged TD" minus "Defined TC" approach, is that you got some values lower than stock.

With long tube headers that move the sensor significantly further from the cylinder, plus have a significantly larger diameter primaries; there just isn't a way I can think of that transport delay could decrease.

I'm not sure what to make of those values either. All I can say for sure is that this was the the first method I tried that yielded logged values that were more consistent from one revision to the next.

[momotunes]

Maybe better exhaust scavenging or change in ignition timing changing the exhaust gas temperatures??

[murfie]

Im probably the only one saying these delays need to be decreased, same with the WOT enrichment rate that are not the minimum ones. If you actually want better/tighter fueling, and not just be happy with what WB say and the FTs taking care of it, you need to work to reduce the transport delay, but your fueling needs to be tight enough to allow it. Tuning this has so many similarities to the knock sensor and finding the borderline of a fuel. These events have to happen for them to have some thing to sense, so it dangerous to a degree. The more error you can get out the closer you can get to your goal. Of course that leave less room for error, unforeseen circumstances, and the control is only finite in its capabilities. Its easy to tune things when there's more room for error, multiply the table by 150%. That doesnt mean you are actually optimizing it.

I think you guys get what the delay is doing by giving the WB signal the seen oscillation from .97 to 1.03. What you seem to be missing is how STFT's are determined to higher %'s than that from a signal that is bouncing around your target under %3+/-. Its the rate at which it goes rich compared to the rate at which it goes lean in these oscillations. If the signal goes across stoich in the lean direction faster than going rich, you engine is running lean, and vise versa. I'm certain the exhaust gasses travel much faster to the sensors than the times in these tables, im also certain the o2 sensors respond very quickly to changes. Changing from a stock manifold to a LT header and moving the sensor a bit further away does add delay, but the WB signal would not change slow enough to warranty a change in the table. Its the fuel/ air models error that usually are not tight enough, and require a longer delay to determine control from.

[CCS86]

Im probably the only one saying these delays need to be decreased, same with the WOT enrichment rate that are not the minimum ones. If you actually want better/tighter fueling, and not just be happy with what WB say and the FTs taking care of it, you need to work to reduce the transport delay, but your fueling needs to be tight enough to allow it. Tuning this has so many similarities to the knock sensor and finding the borderline of a fuel. These events have to happen for them to have some thing to sense, so it dangerous to a degree. The more error you can get out the closer you can get to your goal. Of course that leave less room for error, unforeseen circumstances, and the control is only finite in its capabilities. Its easy to tune things when there's more room for error, multiply the table by 150%. That doesnt mean you are actually optimizing it.

I think you guys get what the delay is doing by giving the WB signal the seen oscillation from .97 to 1.03. What you seem to be missing is how STFT's are determined to higher %'s than that from a signal that is bouncing around your target under %3+/-. Its the rate at which it goes rich compared to the rate at which it goes lean in these oscillations. If the signal goes across stoich in the lean direction faster than going rich, you engine is running lean, and vise versa. I'm certain the exhaust gasses travel much faster to the sensors than the times in these tables, im also certain the o2 sensors respond very quickly to changes. Changing from a stock manifold to a LT header and moving the sensor a bit further away does add delay, but the WB signal would not change slow enough to warranty a change in the table. Its the fuel/ air models error that usually are not tight enough, and require a longer delay to determine control from.

What makes you certain that these values aren't actually physical representations of gas transport time?

Here is an example, where an observable delay between pulse width and WB response, matches the table value for transport delay pretty well:

O2 Response3.jpg

The length of the period drawn here is 0.43 seconds, and the table value is 0.39




I'm still curious about your thoughts on this:

"If it is repeating a per-cylinder rich lean cycle, how can it use that alone to establish a transport delay?

At 2500 rpm -> 42 rev/sec -> 21 per-bank-patterns / sec, even in the defined transport delay of 0.242, there are 5 full bank sequences (one every 0.050 sec). How does it know which one is which? To me that sounds like trying to figure out the lag between opening the throttle and rpms rising, by looking only at the crank trigger signal. It's hard coded to rotation, and can't give you transient response data. It seems like the "pattern" of adding an observably different set of pulse widths, would have to be longer than the maximum possible transport delay, to avoid ambiguity in which time difference to measure."

I also don't agree that the "speed" at which the signal crosses stoich (ie the slope), is what drives STFTs to higher values.

I have spent a lot of time looking at O2 sensor response very closely, and see this characteristic a lot:

slopes.jpg

The WB signal almost always rises faster than it falls. Not sure if this is purely a characteristic of the sensor itself, or something about the chemistry/flow of combustion.

I do agree that the slope of the wideband signal is used heavily, but I think it is put through a PID controller. If it makes a correction to a STFT, and after the transport delay has elapsed no change to the WB signal slope is observed, it pushes further in that direction.

Maybe instead of "Transport Delay Time Constant" being some sort of sensor characteristic, it and "Transport Delay" are just the same table, but one for the lean:rich swing, and the other for rich:lean. Just a thought.

[dtownmikebrown]

What makes you certain that these values aren't actually physical representations of gas transport time?

Here is an example, where an observable delay between pulse width and WB response, matches the table value for transport delay pretty well:

O2 Response3.jpg

The length of the period drawn here is 0.43 seconds, and the table value is 0.39




I'm still curious about your thoughts on this:






I also don't agree that the "speed" at which the signal crosses stoich (ie the slope), is what drives STFTs to higher values.

I have spent a lot of time looking at O2 sensor response very closely, and see this characteristic a lot:

slopes.jpg

The WB signal almost always rises faster than it falls. Not sure if this is purely a characteristic of the sensor itself, or something about the chemistry/flow of combustion.

I do agree that the slope of the wideband signal is used heavily, but I think it is put through a PID controller. If it makes a correction to a STFT, and after the transport delay has elapsed no change to the WB signal slope is observed, it pushes further in that direction.

Maybe instead of "Transport Delay Time Constant" being some sort of sensor characteristic, it and "Transport Delay" are just the same table, but one for the lean:rich swing, and the other for rich:lean. Just a thought.

Have you read this patent? You can probably make a lot more sense of it than I can.

https://patents.google.com/patent/US...total&q=delays

It sounds to me like this excerpt is describing the Transport Delay and Transport Time Constant values.

TD_SEC[1]=TD_BASE[1]+TD_HEGO[1];

wherein,

TD_BASE[1]=base transport delay

The possible values for the base transport TD_BASE[1] are empirically determined and are stored in a table in the ROM 62 of the controller 58. The table of TD_BASE[1] values are indexed by engine speed and engine load. Thus, the subroutine 177 determines the transport delay TD_SEC[1] responsive to the engine speed and the engine load. After the transport delay TD_SEC[1] is calculated, the subroutine 177 calls a control frequency subroutine 209 (step 206) to control the frequency of the signals LAMBSE[1] and LAMBSE[2].

Referring again to step 194, if the ADAPTIVE_TD_FLAG indicates a non-steady state condition exists, the transport delay TD_SEC[1] is calculated using a value TD_HEGOi−1[1] determined in a prior iteration of the subroutine 177 (step 208). Thereafter, the subroutine 177 is exited and the subroutine 159 advances to the step 164 illustrated in FIG. 9C.

[CCS86]

I have read through that patent before, but didn't find an "ah-ha" moment.

Looking back at it again, I see some differences in the control method:

O2-patent.jpg

They show a ramped commanded EQR, with a jumpback and hold. The time period of the ramp is equated to the time delay. But we have no evidence of this ramp, so I think they have just moved to a new style of control on the Copperhead. Maybe this method is applicable to earlier PCMs, and maybe is specific to those without wideband O2s.

They talk about the adaptive transport delay routine, which adjusts the frequency of EQ oscillation to better control peak-to-peak measured EQR. This is how I have been thinking of it. Basically, if measured EQR overshoots the commanded peak-to-peak values, you need to shorten the transport delay, which increases the oscillation frequency.

BUT, in practice I haven't seen the PCM doing this. In my tests that I posted, I took a steady state condition which had great peak-to-peak control and intentionally fudged the transport delay values. I saw the expected reduction in peak-to-peak control. But even after minutes straight of holding this condition, in steady state, with a fully warm vehicle, I saw no adjustment being made. The wideband response stayed the same, and the logged transport delay did as well. Maybe I am missing something needed for this adaptation to take place. But, if I couldn't get it to happen with such steady conditions, it's hard to imagine it learning when you just barely touch a certain condition as load and rpm move around.

[CCS86]

I noticed something pretty interesting today while looking at a log.

This happened shortly after startup. The car was idling for about 45 seconds after fueling went closed loop. Then, it did this funny dance:


o2 transport cal maybe.jpg


Suddenly commanded EQ snapped to 1.0, and the bank 1 STFT did a very fast rich/lean pattern, which can be observed in the wideband signal. I wonder if this is evidence of some self testing / calibration of transport delay.

Would it sneak these into different load/rpm combinations to update the transport delay values. Or, would it assume the table shape is generally good, and use a single condition measurement to globally shift delay?