EFILive Scan Feature Request (Please!)

[Mr. P.]

Hey guys, I've been examining log files for a few weeks now and have a request for a feature that would be handy, and I don't think it would be that hard to implement -

Can you offset the WB data stream a couple frames? Ideally, it would be great if when you select a PID you could right-click on it and 'delay' it a couple frames from the rest of the data. The reason why is because in my study case comparing commanded EQR to observed EQR there is a consistent delay of .1-.2 seconds and I belive this is because the PCM commands a change in EQR and 2-tenths later the WB02 sees the effect of the change because it is located a few feet downstream of the injectors; it would be awesome if one could line them up to account for this delay so you could easily trace transient fueling errors.

Here's a drawing of my issue - this is valid data of my AutoVE log trace, taken during steady state cruise on the freeway at 2400-rpm with the MAP varying from 63-66 kpa; the default BENS filter included with EFILive does include these frames for calculating a VE adjustment:

This first Excel graph clearly shows that the commanded AFR 'curve' and observed AFR 'curve' are the same shape graphs, however the WB02 line "follows" the Commanded line because the wideband sees/reports the effects of fueling changes 4-feet later in the induction path; I also calculated and charted the resulting BEN value -


Here is the same data, but with the WB02 line shifted backward ONE DATA FRAME (about .15-seconds), and you can see they line-up almost perfectly - in fact this shows that in my tune the observed AFR goes leaner than commanded/expected when MAP is decreasing (throttle is lifted), but tracks perfectly whenever MAP is rising.



BUT the most important observation is the new BENs line, notice that it is much flatter, there are a lot of spikes/errors in the first default EFILive AutoVE procedure which are NOT present in the shifted data. The results is dead consistent repeatable BENs corrections on repeat runs (I have been doing this for the last 2 weeks); once my BENS are set, they don't wander anymore in subsequent logging.

Anyways, hope this illustrates the problem and my idea, if when you selected a PID you could right-click on it and set a logging delay of 1-5 frames it might correlate much better on analysis, because not everyone has the resources to develop their own separate data analysis software. And it would help everyone doing their AutoVE tuning to not have their BENs swinging a couple percent from run-to-run.

Mr. P.

[joecar]

Mr.P,

I pm'd Tech Support to see what they say.

In the meantime, I'm going to play with this:

You could create a calc pid using value({GM.AFR}, frame()-1)...

where:
frame() returns the current frame number,
value() returns the value of the pid at that frame.

So your BEN calc pid would be this:
BEN = {CALC.AFR_PLX1} / value({GM.AFR}, frame()-1)

I'll try this out.

[mr.prick]

Have you tried playing with {B3644}& {B3645}?
Instead of a sharp increase/decrease in commanded AFR they can give
a smoother transition in/out of PE.

This can be done with a calc_pid too.
Something like this:
"value({PID},frame()-1)"
This will give you the value of the PID in the previous frame,
you can transpose it over actual to see the delay in a chart.

MAP will always change faster than AFR.

[joecar]

Yup... it works...

do you want to edit your own calca_pids.txt or do you want me to do it...

post your calc_pids.txt file from My Documents\EFILive\V7.5\User Configuration.


Attached see my calc_pids.txt particular to my own BEN pids... see CALC>EQR_DELAY.

[joecar]

Holy number crunching, Batman...

this means that the EFILive scantool can implement digital/discrete filters...

hmmm... might need better than 10 frames/second to be effective...

a digital filter is the summation of the previous N values weighted by an array of factors to produce a "filtered" value... (some filters also use future values)...

this is how cell phones implement low pass or band pass filters to remove noise.

[joecar]

The average of N values is a special case of a discrete filter... all of the N weight factors are 1/N, each one is multiplied with the previous N values and all the terms summed together.

[Mr. P.]

MR PRICK - my tune is currently OLSD and has PE disabled (for VE mapping).

JOECAR - I have actually made my own C# utility to analyze exported log files, it's not very sophisticated but I shift the WB data one frame and use harmonic means to find areas in the log that are important to me and weed-out the transient areas. I had no idea that variable (frame number) was available as an arg in a custom PID, that would do exactly what I describe here, problem partly solved I guess.

Mr. P.

[Mr. P.]

Have you tried playing with {B3644}& {B3645}?
Instead of a sharp increase/decrease in commanded AFR they can give
a smoother transition in/out of PE.
...

No man I haven't strayed very far from VE tuning yet (learning as I go). I will have to ask you guys for some insight, I've got three issues -

1) on decel the RPM wanders, when the vehicle is stopped the managed idle takes over and it idles fine, I think I read somewhere this is just not enough running airflow.

2) the motor spits and cuts apart at 4000-rpm if the MAP > 100 kpa, I thought this was the A0009 Boost VE table being too rich, but logs suggest that it's not the issue. Also there is no KR and spark is 17-degrees so I don't think this is the issue either, I am not sure how to troublshoot from here.

3) I get a single spike of KR on trans kickdown; I don't know where to go to address this, I'm just learning...

But so far the tune is IMO coming along well, the truck is AWD and will rip all 4 tires loose from a stop before boost comes in, and it's very strong for 4-psi, I haven't been able to spin the motor higher than this without breaking up.


Mr. P.

[mr.prick]

Etc?

[swingtan]

I was looking at this some time ago and decided that offsetting the WB data was not going to work for me. If you are only going to tune for WOT, then offsetting will work OK, but for a daily driver, it's not going to work. My reasoning is this.

The data from the WB unit is actually not delayed at all. The data is exactly what the WB is reading at any given time. However, the exhaust gas being sampled IS delayed by some amount of time when compared to the rest of the logging data. This is because most of the data in the log is "Commanded" parameters or data collected before combustion. The exhaust gas is sampled after combustion and in the case of long 4>1 headers, some distance down the exhaust path.

So the data coming from the WB unit is offset from the rest due to both the position of the WB sensor as well as the time taken for combustion to occur. The amount of offset changes with both exhaust gas flow and RPM. At idle, where RPM is low and gas flow is low, the offset is quite large. At WOT and/or high RPM, the exhaust gas reaches the WB sensor sooner so the offset is less. So having a fixed offset is not going to work well for anything other than fixed conditions.

When I was going through all this, I just made mental notes on the amount of offset and manually adjust the corrects when / if needed.

Simon.