Lambda delay

[panel]

Can someone post the factory Lambda delay graph for me?

[Piledriver]

There's a factory lambda delay graph?

There was a bug in the sequential code awhile back (fixed now) that would cause an intermittent "miss" of an injection event... was very useful to figure out the lambda delay at different RPMS/loads.

Hmm..

[MarioVelotta]

I like where your head is at Pile! I think that should be be implemented in the tools menu.

Miss a cylinder every 5 seconds and watch for the rich peak in the graph then use the ruler to figure out the amount of time from the injection event, r something like that

[Piledriver]

I like where your head is at Pile! I think that should be be implemented in the tools menu.

Miss a cylinder every 5 seconds and watch for the rich peak in the graph then use the ruler to figure out the amount of time from the injection event, r something like that

Already floated as an idea on msextra about 30 seconds after posting "hmmm" here.

jmscortina (Main dev) has already commented positively, we shall see how it goes.

I suspect it will probably be implemented as a programmable ignition miss and log "mark" or flag output, the O2 sensor cannot tell the difference between missed fuel and missed ignition--- neither burns and it spikes full lean.

[panel]

This is mine in question.

Tuner studio 2.04->VEAL->reference tables->Lambda graph.

[MarioVelotta]

That looks like the factory graph already.

[panel]

I'll leave it for now then.

[MarioVelotta]

You have to figure it is based on a V8 header though

[panel]

I guess this is where you'll help out I have the load and RPM down I think but how/why make changes in the (ms). In a log what do you look for to make that change?

[MarioVelotta]

I haven't spent alot of time working my table but this is what I have done the little time I have spent with it.

Quick transitions seem to be the best indicator. letting off the throttle sharply will cause fuel cut if you have over run enabled, Look in your data log for the quick throttle cut and with the measurement tool see how long it took the wide band to catch up or respond to the fuel cut and plug the numbers in

[Piledriver]

In MLV, there's no table unfortunately, you have a choice of 1>7 sample count regardless of load/RPM.

[emtee]

Quick transitions seem to be the best indicator. letting off the throttle sharply will cause fuel cut if you have over run enabled, Look in your data log for the quick throttle cut and with the measurement tool see how long it took the wide band to catch up or respond to the fuel cut and plug the numbers in

Good call, I've been playing with this a little today as I wasn't 100% happy with the way VEAL was working. Looks like there's some hefty delays in the response of my wideband (LC-1). In the screen grab from MLV below you can see that when the overrun fuel cut is activated at ~2500rpm there's a delay of around 700ms before the wideband reacts. At lower RPM it looks like nearly a second in some places. Seems a hell of a long time..?



The sensor is just before the flange on a merged header so there's a fair length of pipe between it and the heads but I'm surprised it takes this long to react. Is there some kind of inherent latency in the LC-1 controller as well?

I'll amend the Lambda delay table in VEAL & see what difference it makes.

[panel]

From Mario

Steady state idle, adjust delay in veal until AFR and target table match

Add some rpm 2800 (mid point), same thing, adjust the veal delay in the bin until the AFR and target are the same.

When doing this.......do you have VEAL running? Do you have to keep clicking 'BURN' ?

[panel]

Motec's approach:

So the best way to measure this is to be data logging injector duty cycle, rpm, throttle.

Next put a huge fuel step in your fuel map. Example.

RPM fuel
5500 60
6000 62
6500 100
7000 65

now as you run the engine through the rpm range (on the dyno or the track), you will see that from 6000, the injector duty cycle will ramp up, and at 7000, it will have come back down.

Now look at your lambda readings, you will see the lambda go very rich. Look at the duty cycle of the injector, and compare it to you lambda trace, the offset between these two is your lambda delay. Log everything as fast as possible to increase accuracy.

[Piledriver]

There can be large lag differences between controller brands/designs.

MS3 even appears to show far more delay than MS2 did with the same WB controller.
(despite logging at ~1/2 sample rate or less due to the logging data volume)

At least you can make the delays match using TS/VEAL...
Megalogviewer is almost unusable for VE table tuning at the moment, at least for me, and it is 100% useless for VE tuning with high datarate SD card logs, as MLV only has sample # based delay, not time based.
(I can log at 333ms/333 Hz, at least for bursts, and >5ms/200Hz consistently, sdcard dependent)

Many WBO2s are also heavily filtered on the analog output, at least.
Not all of them will show you a single event misfire...
(The SENSOR can see it, but what the controller passes on is another matter)

Built/installed my SLC-OEM eval kit today, seems to work OK, but extended fuel cut is only seeing ~17.5:1 using the innovate 0-5v//10-20:1 default cal... that at least theoretically matches. (should read max AFR on fuel cut)
Have to work on the MS side cal, at least until I get the IOX to allow digital comms w/no offset/scaling issues.
May just swap my old JAW back in until I can go all digital, at least I can scale the MS side to match the digital output over the full range.
It seems much more heavily filtered vs. my JAW 1.03, but i does have a documented filter circuit on the carrier that can be changed.

I have read of folks being concerned about getting a long enough cable in the SLC-OEM kit, but I installed it with my MS3 under the backseat, cut ~18" off for the power etc connections, ran the sensor line to thee other side of the car past the battery, down some flex conduit and to the back of the car and still have ~18" of service loop.

The SLC-OEM carrier board (power supply and place to hook wires) silkscreen has 2 resistor values wrong, (and strangely, the 2 1Ks were also supplied in the kit to catch folks like me that don't read documentation ) but the fine documentation very clearly (and repeatedly, in RED) points out the error.

On MS, it will interpolates between several cells, so a temporary change to the VE/target tables at 2-3 RPMS with a very close "normal" column before the step in fuel will help make it sharper/easier to see.
(make sure your last column isn't into the rev limiter)

The VEAL delay table only has 3 MAP rows and 3 RPM columns, and should be consistent for your sensor/exhaust setup once done.

The only other variables are EGT and the response of the sensor vs. AFR, but those are probably lost in the noise, or accounted for in the existing delay.
The data at the higher MAP readings is more important IMHO, and impossible to get only using fuel cut delays.

Digging through my logs in MLV I have almost a 1 second fuel cut>AFR signal lag at ~25kpa and ~2200 RPM.