Transport delay

I am in the process of setting up / initial tuning of an ITB system on a Big Block Ford. Now working on the transport delay settings ( I am using a Performance Electronics ECU). Some questions on this setting. The headers are similar length, not equal length and have already been installed on a car (replica Cobra). The O2 sensor is mounted in the collector tube along side the body, at the end of the header tubes.

1) My thoughts are to stretch a string along the outside of each tube, on the long side and on the shortest side of each tube to come up with an average centerline length.

2) When done, I know I am going to end up with different lengths, maybe as much as 4". Any suggestions on the best method to compile this as the program accepts only one length to determine the delay. Shortest, Longest, Average, Weighted average?

3) In calculating the revs when a cylinder's contents reach the sensor, do you calculate to the leading edge, trailing edge, center of the mass?

When all done, is there a way to best test your calculations and settings? Maybe make a particular cylinder go rich and see if the sensor catches it? I do have sequential control so I can play with each cylinder.

Or am I overthinking all this? I have a tendency to over-analyze. Do I just take an average calculation/reading and put it in?

Thanks for any input

Paul

I think there is a simpler way to determine the transport delay.

- Setup logging of RPM, Target Lambda (or fuel pulse width), Measured Lambda at a fairly high sample rate.

- Now enable logging (make sure close-loop fuel control is off) and run the engine at a fixed RPM (whatever matches the breakpoint in your transport delay table).

- Now change either the target lambda or fuel table by like 5-10%, wait for the Lambda to stabilize and repeat returning to the original value.

- Then repeat the last two steps for each RPM breakpoint in your transport delay table.

-- Examine the logged data, and measure the time between the fuel changing, and the lambda stabilizing at the new value. That is your average transport delay for that RPM.

- After updating the transport delay table, don't forget to re-enable closed loop operation.

Sorry if I've used the wrong terms for your PE3 ECU -- I don't have the time to fire up that software and get it completely correct -- but this should give you the general idea.

I am still trying to set the proper transport delay and still can't get it done. David, following your suggestions, I generated a sharp cut point using a feature in my ECU program. I enriched the mixture about 15%, let the engine stabilize, then used the reset button which immediately put the fuel back to normal.

Below is a copy of the log file showing the results. The four charts, from bottom-up: RPM, Fuel and Lambda 1 & 2. X axis is seconds, Y axis are the ranges for the four logs.

You'll note the sharp change in Fuel Open Time at about 544.8 but I don't get a really noticeable change in the Lambda settings. This was sampled at 50 Hz. The log settings will allow me to log at 100,50,33,25,20,10 and 1 Hz.

My volume calculations (Bore, Stroke, exhaust port volume, header pipe volume, etc) indicates the transport delay should be somewhere around 6 revolutions. But the variation in the Lambda signal is so erratic, you can't identify anything. The manual for the ECU indicates a typical delay setting is 10. I am unable to tell if my settings are helping or hurting me. I've tried 6 and 12, just to see if I could tell a difference in the way the engine runs but can't see anything.

Any ideas on how I can get a clear definition of when the O2 sensor senses the fuel change?

Thanks in advance for any ideas

Paul

OK, this is a case where we need to use our "eyeball average". The lambda 2 value in the top graph has about 4 "lean peaks" per second. Just looking at the lambda value just past each lean peak (before the rich peak), there is a "flat spot" in the trace -- I am going to use that as the Lambda value. Notice it had still not stabilized (was trending richer) prior to the fuel pulse width step. But there are three flat-spots at about Lambda 1.0 between 544.8 and 545.7. The first time the Lambda reaches above Lambda 1.15 in a "flat spot" is about 547.2 (not sure if it stabilized). -- so I would put the transport delay at 547.2 - 544.8 (2.4 seconds) which at 850 RPM (14.167 rev/sec) is 34 revolutions.

I am not surprised to see a value of around 2 seconds at low RPMs. This is the hardest one to measure because the lambda value is rarely stable.

I suspect this would be more obvious if you were running at 2500 RPM.

Thanks for your insight, David. I'll give it a try at the higher RPM and report back

Paul

David or anyone else,

It just dawned on me, even with the most accurate calculations of volume and how quickly the gases could reach an O2 sensor, I overlook that there is a processing time from when the gas is sampled, calculated, value transmitted to the ECU, internal process and then, finally, a change in the fueling.

Does anyone have any ideas, the time involved for the Bosch processors and sensors to report a change to the ECU?

Paul,

I love that you're trying to calculate an expectation, then verify the result is as you expected. That's a great way to do many things.

In this case I think you're working with some unknowns that are resulting in having to perform iterative adjustment until you get your desired result.

I don't know what the table you're tuning looks like on that ECU, but several engine operating factors contribute to transfer delay. If you know engine speed, exhaust temperature and pressure that helps. If your system can accurately calculate exhaust mass flow rate, and base transfer delay on that, that's quite helpful.

And David's suggestion to make a known change while logging the change occurring is how I generally do this too.

Mike

My ECU's transport delay adjustment allows me four positions, based on either RPM or Load. It doesn't map or use exhaust temperature, exhaust pressure or exhaust flow rate.

My goal in this is to have as accurate a number as possible, only to help the engine perform better - to sense the needs of the system faster rather than slower or presenting inaccurate information into the fueling equation. The problem I keep running up against is I can't tell if the setting should be 4,6,10,20 or whatever. In all cases, its impossible to accurately see the change point in lambda due to the variations of the lambda reading. I can generate and see a distinct fuel change point, but I can't determine when the system is able to sense it.

Is there anywhere I can read and understand the other factors that come into play on transport delay? Doing the volume calculations gives me setting numbers that are not appearing in the log files. There has to be more going on because like David pointed out, he's indicating a "34" reading in his interpretation when calculated by volume, you would expect the number to be "6" Big Difference. And when I try the 34, just to see what happens, I see little if no change.

The guy who wrote the algorithm for the fueling equation is no longer with the company and we're not able to ascertain any of the history or background on this part of the programming. Most of the companies focus is on 1 & 2 cylinder performance engines with little to no attention to closed loop or long term fueling. Racing is a different game than driveability/street performance.

There's an answer out there somewhere, just beginning to get an understanding of this part of tuning and the learning curve isn't flat.

Paul

Paul, I think the fact that you don't have a stable Lambda signal is what prevents you from seeing the change (and may be what prevents the closed loop algorithm from working effectively.)

Is the wideband controller built into your ECU, or is it external? If external, how is it connected (digital like serial or CAN), or using an analog voltage input to the ECU?

If analog voltage, are you sure the power supply / and signal grounds are good for the wideband controller? If you stop the engine and seal the exhaust pipe, does the reading remain stable (since the oxygen in the exhaust should not be changing), or does it still jump around? What if you power the wideband from a separate battery (still keep signal grounds connected) -- is that more stable while running?

Next, let's look at the sensor installation. Does your exhaust system have any slip joints up-stream of the 02 sensor? Can anything be done to seal any small gaps (even on a temporary basis, just to see if it makes a difference)? I mentioned that it's not unusual to see Lambda variation at idle, particularly with short exhaust systems as air is pulled in from the tail pipe. What happens if you block most of the exhaust tip (hand, wood block, metal plate) -- often this will stabilize a wideband reading to help understand what is happening at idle (or low RPM).

Finally, we might be just be measuring what is really happening. Perhaps the fueling isn't consistent from cylinder to cylinder due to injectors, spray patterns, fuel system pulsations, injection timing, exhaust system design, cam overlap, etc. I would be trying experiments like changing the fueling for one cylinder (if the ECU features this), or the injection timing to see how that affects the Lambda signal.

I think you and I need to get together some weekend and work on this...

Hi Paul,

The methodology David has outlined is the mot effective way to calculate transport delay to a wideband sensor.

Looking at your logging screenshot however, there is one item I would like to raise. As you have a big block with individual throttles, unless the system is already finely mechanically (throttles) and calibrated, I would advise against completing the test at idle and at such a lean mixture.

The chances of cylinder to cylinder variance, particularly at low engine speed in the 1.0-1.15LA range lends itself well to some cylinders not achieving complete combustion, causing results like you in your graph.

I would recommend testing at 0.95LA and increasing fuelling 10%. I would also be attempting higher engine speed break points, rather than starting at your 'effective minimum engine speed' as this can be interpolated after testing at higher engine speeds, and revisited once tuning has progressed further.

Nathan

Sorry, I am a newbie at this. Can you tell me what the acronym "LA" stands for. Can you put "0.95LA" into laymans terms

Paul

LA = Lambda

0.95 Lambda is approximately 13.97:1 Gasoline AFR.

If you have to choose between RPM or load, and only get 4 cells, or even if you have a 3d table with RPM and load axes, but only have 4 cells to work with, I don't see how you can accurately characterize an engine with that many cells.

I'd spend a little time deciding which conditions you want to handle best, and understand other conditions simply won't be optimal.

If you have PID values you can adjust, I'd work on those and dial back min/max trim limits to reduce the lambda error caused by corrections based on transfer error.

Mike,

My inexperience with the terms may have misled your comment. The way you describe it, I am able to sample and control based on either Load or RPM and then the column associated with that selection. ie, If I set the highpoint at 5500rpm, then I can tell the ECU, the transport delay at that rpm is "X"

does that make sense?

Paul

Guys

Thanks for your help in talking me thru this. Transport delay isn't a highly documented subject and very difficult to obtain information on the subject. In my case, I think the key was to concentrate on higher rpm's and ignore the idle setting. Once I moved up in rev's, I was able to find and read changes which helped me zero in on a solution. Figured out a way to filter my lambda readings which made all of it come into focus.

Thanks for your help, time to go out and put some miles on her.

Paul

Awesome, great work Paul!