Megasquirt Support Forum (MSEXTRA)

How does one go about setting the Lambda Delay in TS/MLV? I'm using an LC-1.

Justin

I've been wondering about that too! Also using LC-1.

Even so, I've been using the standard values that comes with TS with very good results. I guess that those values would depend on many factors, most notably how far away the sensor is mounted from the engine. Exhaust diameter would surely also play a role (the bigger in diameter, the slower the gas flow in it, the longer the delay?)

And then I presume LC-1 has to be set for "instantaneous", not 1/12 etc averaging. Keen to see what Phil says on this one

I have found the default settings to work well for most setups. But like Philip L said, you are probably best off without the averaging in your WB Controller.

There is some latency in the controller, but if you are on instant, I have found most of the latency to come from the distance to the sensor and the exhaust gas velocity, once again as Philip L said...

Now How I usually determine the latency is by looking at the log files. Look for key events that cause a large change in PW like accel enrich, decel enrich, overrun, etc... count the number of records from the where the large PW change occurred and where you see a change in the afr.
Then see what the time delta is in log between the 2 points. Or in MLV just stick with the record count. I have found a substantial difference at different map/rpm points in the table, so ideally you would want to capture points for at least the 4 quadrants. I know on my own care if at WOT on the high side of 6000 RPM there isn't usually more than a 50 ms latency, but when over run kicks in at 1600 rpm there can be like a 450 ms delay. I have 2 1/8 inch primaries with the sensor in the collector, so with little flow like under over run it seems it can take a long time for the sensor to react.

I kept the tables only a 6 x 6 because I figured it would be hard to capture valid data beyond that, also I plan to put in a auto measure type feature at some point, where TS can watch for the key evens and time to afr change.

LT401Vette wrote:I have found the default settings to work well for most setups. But like Philip L said, you are probably best off without the averaging in your WB Controller.

There is some latency in the controller, but if you are on instant, I have found most of the latency to come from the distance to the sensor and the exhaust gas velocity, once again as Philip L said...

Now How I usually determine the latency is by looking at the log files. Look for key events that cause a large change in PW like accel enrich, decel enrich, overrun, etc... count the number of records from the where the large PW change occurred and where you see a change in the afr.
Then see what the time delta is in log between the 2 points. Or in MLV just stick with the record count. I have found a substantial difference at different map/rpm points in the table, so ideally you would want to capture points for at least the 4 quadrants. I know on my own care if at WOT on the high side of 6000 RPM there isn't usually more than a 50 ms latency, but when over run kicks in at 1600 rpm there can be like a 450 ms delay. I have 2 1/8 inch primaries with the sensor in the collector, so with little flow like under over run it seems it can take a long time for the sensor to react.

I kept the tables only a 6 x 6 because I figured it would be hard to capture valid data beyond that, also I plan to put in a auto measure type feature at some point, where TS can watch for the key evens and time to afr change.

this has inspired me to figure out the latencies properly on both my cars now. i rely on the autotune (before that was the MLV analyze) quite a bit, so eliminating that variable(or at least making sure it's closer to where it needs to be) would be fantastic.

it's not that hard to get it close. Basically watch the log for AFR "events" (where it changes drastically in a short time), and look to see what probably caused that event (PW spike, MAP increase, throttle stab), and count the time from the event to the actual change in AFR. them adjust the lag table appropriately.

it matters more in changing conditions than steady state, so I don't think it's critical to be perfect. it's still better than the global lag value in the old MLV.

hassmaschine wrote:it's not that hard to get it close. Basically watch the log for AFR "events" (where it changes drastically in a short time), and look to see what probably caused that event (PW spike, MAP increase, throttle stab), and count the time from the event to the actual change in AFR. them adjust the lag table appropriately.

it matters more in changing conditions than steady state, so I don't think it's critical to be perfect. it's still better than the global lag value in the old MLV.

yeah, makes sense. should be fairly easy to figure out.

It is the changing points that help in identifying the delay, then that delay is applied during steady state also.

I took a more mathematical approach to setting mine up. I basically looked at how much volume of air was pumping through the engine (taking into consideration the VE) then easily worked out the exhaust velocity with the I.D. of the tube and finally the time it took to reach the sensor, the math's fairly simple w/ a spreadsheet. Here's a capture of what I came up with, seems dominated by engine speed more than anything else.

Oops guess the board isn't taking attachments now..you'll have to use your imagination

I don't know about that, exhaust velocity can be very tricky to measure. Measuring velocity is basically everything behind header/exhaust tuning, which I spent a lot of time reading about - velocity is affected by more than just pipe ID; EGT, collector style, backpressure, scavenging, reversion waves, etc. can all increase or decrease velocity.

However, given that I set my lag table by just looking at the logs and getting it "close enough", as long as you're in the ballpark it should be fine.

LT401Vette wrote:I have found the default settings to work well for most setups. But like Philip L said, you are probably best off without the averaging in your WB Controller.

If I remember correctly, Al once said that the averaging is better done in the controller because it will be more accurate. I think it makes sense, although, averaging using the lag factor in the MS is a bit more accessible.

That said, I think there is still a huge gray area around this whole process because those delays (lc-1 and ms lag), in addition to the exhaust distance, all need to be factored in to the final lag time, and nobody has come up with a simple, straight-forward way to measure it.

I think it would be really handy if there was some kinda button that could be pressed to instantly bump up (or kill) the PW so it's very obvious. I was thinking about making some kinda push-button contraption so I could test this at varying loads and RPMs, but I just haven't gotten around to it. Would something like this be possible within TS?

Would it be usable to scatter a few cells in the VE map with very large values and then datalog the results?

Here's a thought - how about setting up a fuel-cut rev limiter, set to whatever RPM you want to check lambda delay for? Then you can drive into the limiter at various loads, and see how long it takes the AFR signal to react.

hassmaschine wrote:I don't know about that, exhaust velocity can be very tricky to measure. Measuring velocity is basically everything behind header/exhaust tuning, which I spent a lot of time reading about - velocity is affected by more than just pipe ID; EGT, collector style, backpressure, scavenging, reversion waves, etc. can all increase or decrease velocity.

However, given that I set my lag table by just looking at the logs and getting it "close enough", as long as you're in the ballpark it should be fine.

Yeah, I didn't factor in the air heating up and expanding or the backpressure, I wonder how much this affects it compared to the basic pumping rate changes due to RPM. From the quick calcs I did the RPM is a major player, just wonder if the others are insignificant in comparison?

therieldeal wrote:Here's a thought - how about setting up a fuel-cut rev limiter, set to whatever RPM you want to check lambda delay for? Then you can drive into the limiter at various loads, and see how long it takes the AFR signal to react.

this will play better than the overrun method because there's still air being moved there, versus throttle plate being more closed than open.

You know, there are plenty of ways to get more fuel/less fuel to inject - I've done it before and it works, but it's a pain.

If there were a button (virtual or mechanical) for which you could specify the exact PW that you want (whether it be a high or low amount), and when you press it, that's what gets injected, I think that would be very handy. Very simple, yet very effective as you'll see it on the log and you can measure the time it took for the wideband to register the change.

msoultan wrote:You know, there are plenty of ways to get more fuel/less fuel to inject - I've done it before and it works, but it's a pain.

If there were a button (virtual or mechanical) for which you could specify the exact PW that you want (whether it be a high or low amount), and when you press it, that's what gets injected, I think that would be very handy. Very simple, yet very effective as you'll see it on the log and you can measure the time it took for the wideband to register the change.

external tableswitch to a map that's 255 all across or some other amount.

Is there any way to do this within tunerstudio such that I don't have to hardwire an input?

myk777 wrote:
Yeah, I didn't factor in the air heating up and expanding or the backpressure, I wonder how much this affects it compared to the basic pumping rate changes due to RPM. From the quick calcs I did the RPM is a major player, just wonder if the others are insignificant in comparison?

for a back of the napkin calculation I'm sure it's fine, but those other things can be quite significant. Calculating the actual velocity of the exhaust in a header is difficult, and is part of what makes the "dark art" of exhaust/header tuning. There are general guidelines though, so as long as you're not an order of magnitude off and the number makes sense.

Is there any way to do this within tunerstudio such that I don't have to hardwire an input?

Yeah, ultimately I intend to put in an auto mode, or detect lambda settings. TS should be able to identify many shifts as it is, but up at WOT and what not it is quite possible for TS to send some table values. You wouldn't be able to send a new value for right where you are running, as that would interrupt the reads and you wouldn't have the data. But a couple of placed values may work. Something I would want to do with care though. You would probably want to shift the X axis too to make the ramp up to the cell steep. Otherwise the interpolation might make the PW change vague.

LT401Vette wrote:you wouldn't have the data. But a couple of placed values may work. Something I would want to do with care though. You would probably want to shift the X axis too to make the ramp up to the cell steep. Otherwise the interpolation might make the PW change vague.

Yeah, this is what I did (created a "shelf" in the table), but it was somewhat of a pain to do. It would have been much easier to have a button to press and activate a fuel cut/shot.