Page 2 of 5 FirstFirst 12345 LastLast
Results 21 to 40 of 93

Thread: Transport Delay /Transport Time Constant

  1. #21
    Tuner
    Join Date
    Apr 2017
    Location
    Dearborn, MI
    Posts
    92
    Quote Originally Posted by murfie View Post
    No, The delay will be adjusted for exhaust and sensor position modifications OR rate of airflow through the engine is altered significant enough the learn is way off and compensating a lot.
    Just when dialing in the maf, I would disable the learn so that the back and forth rich/lean behavior isn't moving around the actual lambda/ commanded lambda on its own. Unless you are paying attention to which side of rich/lean, the average of the data you are applying, is spending more of its time on.
    With good MAF data use the Learn PID it will be more accurate than just math in the scanner.
    Thank you for clarifying.

  2. #22
    Tuner
    Join Date
    Jul 2016
    Location
    Richmond, TX.
    Posts
    83
    Great explanation Murf!! Thanks for your help here once again!

  3. #23
    Advanced Tuner
    Join Date
    Dec 2015
    Posts
    203
    Just to clarify if you don't have good maf data it would be better to turn learn off and dial it in but on the other hand if you have good maf data it will be easier just to paste what is logged into the delay table.

  4. #24
    Senior Tuner
    Join Date
    Jan 2013
    Location
    Hawaii
    Posts
    2,101
    Quote Originally Posted by Devildog1325 View Post
    Just to clarify if you don't have good maf data it would be better to turn learn off and dial it in but on the other hand if you have good maf data it will be easier just to paste what is logged into the delay table.
    Yes, Its mainly if you are having to tune from scratch and both exhaust and MAF housing are modified. Also if you have FI and airflow or exhaust back pressure is increased.

  5. #25
    Advanced Tuner
    Join Date
    Jun 2008
    Location
    Tyler/Longview, TX area
    Posts
    746
    Can transport delay learning be logged?

  6. #26
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    This thread is due for a bump.

    I am curious to learn more about transport delay. I just started logging O2 Transport Delay Total on my supercharged '12 GT. I'm sure the M122 blower has an affect on transport time, but I am running stock headers and cats. Everything else is aftermarket and bigger. I wasn't expecting to have to tune transport delay because of this.

    After one 30 minute drive, logging that PID against load and rpm, I have a pretty decent looking chart. Here is a comparison of the stock data vs copy paste from my scanner log. With a little more log data and some smoothing it looks surprisingly usable. Pretty minor spread from max to min values. I'm just surprised to see some values double or triple the stock values:

    Transport-stock.pngTransport-log-data.png


    Murphie, thank you for the explanation of the Time Constant table! I was a little confused on that one. On the log you posted screenshots of, I can see that your commanded oscillation looks very "fast". Mine has more of a square-wave shape. I generally don't have any actual overshoot of commanded, but they run very close to each other. One thing that looks odd on your log, is the commended EQ having an undulating swing to it. Even with your min scale value at 1.0, you never seem to dip under that. Mine is always centered about 1.0 during low load:

    EQ-vs-measured.png


    Looking at the response of my WBs, it looks like I could make a slight increase to the Time Constant while I am still tuning fuel. Do you agree?

    Some questions:

    1. Should logged values for Total Transport time be copied over into the table, assuming good data was taken?
    2. When tables like this use "load" as an axis, should you be mapping "Absolute Load", "Calculated Engine Load", "Air load"?
    3. When logging PIDs like WB EQ, STFT, etc, is the data gathered absolute, or is it shifted by the transport delay? It seems like the measured WB signals could go either way, but that STFTs should essentially be shifted by the current transport delay. So that the correction at any given moment is relevant during current conditions. I'm leery of using the EQ Error math parameter, as this could be unshifted and give you bad correction data.
    Last edited by CCS86; 04-17-2018 at 07:49 AM.

  7. #27
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    Okay, I did a quick test by modifying the Transport Delay table.

    Instead of using the values in my logged chart, as a first pass at this, I took a cell with a lot of steady data (1750 rpm, 0.2 load) and found it to be essentially double the stock value. I took the whole stock table and multiplied it by 2. I was pretty sure this would be a change for the worse, but I wanted to see the effect.

    The result is interesting. The car still drove well, but the log data is definitely different. Here is a comparison view of back to back drives with only the transport delay changed:

    Stock-Transport-Delay.pngDoubled-Transport-Delay.png

    What I notice between them:

    • The STFTs are far more "lively". With the stock TD, the STFTs look filtered compared to the doubled TD
    • I accumulated far less LTFT over the drive with the doubled TD (related to the last point I'm sure)
    • With the doubled TD, the rear O2s spent much more time at high voltage, avoiding some deceleration (lean) dips seen with stock TD
    • Looking at my logged "Transport Delay" table, the values went ever higher after increasing the transport delay. This makes me feel like the direction is wrong. Unless I'm looking at this the wrong way, a change for the better should start to close the gap between the TD table flashed and the TD table logged. Or, you could look at steady periods of CL operation, aiming to have STFTs not exhibit any of the commanded oscillation.



    I may revert back to stock Transport Delay values, and modify the Time Constant table instead.
    Last edited by CCS86; 04-17-2018 at 11:25 AM.

  8. #28
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    I tested some modification to the Time Constant tables today. I did one drive with the whole table multiplied by 1.25, and another with it multiplied by 0.8. (Stock Transport Delay table values)


    • Changing the Time Constant did seem to lengthen / shorten the duration of the commanded EQ, but only the richer side (higher TC = longer period of rich)
    • Changing the Time Constant table changed the reported values of Transport Delay (higher TC = higher reported delay)


    Delay-TCx0.8.png

    Delay-TCx1.0.png

    Delay-TCx1.25.png



    TCx0.8.png

    TCx1.png

    TCx1.25.png

  9. #29
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    I noticed something else today. The dwell period of each commanded EQ ratio doesn't seem to be dictated only by Transport Delay / Time Constant. It definitely appears to be reactive.

    During this log portion of steady idle, something prevented the mixture from leaning back out. STFT was swinging in, trying to make it happen, and commanded EQ hung out and waited:

    O2-long-EQ-dwell.png


    Here is a shot of steady 5000 rpm, with increasing load at the end. You can see that the commanded amplitude and period start to decrease with increasing load:

    O2-delay-load-increase.png


    Does anyone know what Ford's definition of Transport Delay is? Is it the time from when the commanded EQ peaks, until the WB matches that value? Is it the time from when the commanded signal starts to rise, until the WB signal starts to rise?

  10. #30
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    I stumbled on this picture that murphie posted in a different thread. It describes a t_delay (which may or may not be how transport delay is used in the Copperhead), as the time between the commanded lambda change, to the wideband crossing stoich:

    Transport delay patent.PNG

    fig 5b shows a 'pulse width', which really can't be related to injector pulse width, and really just describes half the period of a lambda cycle.

  11. #31
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    Does anyone else have very poor polling rate on WB Measured channels?

    I have mine set to 20 Hz, but am only seeing data at around 3 Hz.

  12. #32
    Advanced Tuner 15PSI's Avatar
    Join Date
    Feb 2016
    Location
    East Coast Somewhere
    Posts
    458
    Just remember that the amount of items you are logging will affect the overall polling rate. Too many will slow polling down. If you have not done this, I would suggest you log with very few items so that faster polling is available.
    2012 Mustang GT with S/C
    4Runner with S/C
    Turbo/NOS Hayabusa - 320RWHP

  13. #33
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    True, but many other parameters are polling at 20 Hz or faster. So, I don't think I have hit a global threshold.

  14. #34
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    After spending a lot of time looking at transport delay, comparing logged values for Transport delay total with manual measurements I took, I started to notice a trend.

    Basically, logging Transport delay total over a long, mixed condition drive, gives you a surprisingly clean table of data:

    Transport-delay-logged.png

    But, the values themselves seem very large. On my car with an M122 blower, but stock headers and cats, these seem way too big. Punching these values into the delay table just results in destabilized STFTs and new logged Transport delay values which are even larger.

    Dividing these logged values by 2 gave me values that very closely matched my hand measured O2 response time, so I thought, why not? I put in the halved values to the delay table, graphically smoothed things slightly, and flashed. This has actually given me a pretty nice result. The STFTs look quite stable and the new logged delay values (again cut in half), show very little change.

    Logged and halved values:
    TD-Logged-halved.png

    I'm curious to see whether this technique give others a good result. A log file of a long drive is attached. I still have some transient fueling to dial in, but if you look at general O2 and STFT response, I think it looks quite clean.
    Attached Files Attached Files

  15. #35
    Senior Tuner veeefour's Avatar
    Join Date
    Oct 2016
    Location
    Poland
    Posts
    1,711
    You can actually log transport delay as a pid - have you tried that?

  16. #36
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    Quote Originally Posted by veeefour View Post
    You can actually log transport delay as a pid - have you tried that?

    It doesn't sound like you've read my posts.

  17. #37
    Senior Tuner veeefour's Avatar
    Join Date
    Oct 2016
    Location
    Poland
    Posts
    1,711
    Probably...there are many...

  18. #38
    Advanced Tuner
    Join Date
    Jan 2018
    Posts
    202
    CCS86-

    have you messed with the transient tables at all?

    I have a customer coming in tomorrow with a (2016 5.0) vortech and im going to be doing some testing with the gain on the transient tables to see how they affect STFT's at WOT, i also plan on adopting your strategy to dial in TD by logging and then halving and pasting directly in. Ill be sure to share the results!

  19. #39
    Senior Tuner CCS86's Avatar
    Join Date
    Nov 2017
    Location
    Austin
    Posts
    1,089
    Quote Originally Posted by txtailtorcher View Post
    CCS86-

    have you messed with the transient tables at all?

    I have a customer coming in tomorrow with a (2016 5.0) vortech and im going to be doing some testing with the gain on the transient tables to see how they affect STFT's at WOT, i also plan on adopting your strategy to dial in TD by logging and then halving and pasting directly in. Ill be sure to share the results!


    I have tried a number of times, but have not yet figured out exactly how they are applied. I really wish there was a PID you could log that told you how much of a transient correction was being made at any given time. Otherwise, you are assuming what is from transient modifiers vs something else.

    I'm curious to hear your results. But I don't really think you'll see much from transient tables during WOT. They could affect the period while you are rolling into the throttle, but once you are steady state WOT, I don't think transient tables are used.

  20. #40
    If you have a known calibration (Whipple) with known injectors (id1050x) can I use trims to adjust this? ie. keep tweaking until they are close to =-2-3 % in the important zones?