NefMoto

So the low pass filter time constant ZKLAMFAW is delaying the onset of LAMFA from what I want it to do:

(http://i.imgur.com/nleMO.png)

(http://i.imgur.com/msS4B.png)

Anybody see any harm in significantly reducing (or zeroing) ZKLAMFAW?

I halfed it and there is still a slight delay, but I haven't had a chance to really play with it further.

I don't see a problem with reducing/zeroing it.

hmm.. my ZKLAMFAW sais 13107 seconds.. id assume this means deactivated?

I'm pretty sure zero would be deactivated and that it is CPU time not seconds.

hmm.. funktionsrahmen tells me it is a time-constant and that the default value should be "2 s", which is where i got seconds..

ZKLAMFAW located at 1CF8C, 16bit(LoHi), but i have no conversion for this value.. should there be one, or is my definition wrong here?

this is a wideband me 7.5 ecu, but i think this constant should still apply?

I see the same as you in my R box (0x3333), scale=1, offset=1

the others are 0xffff

$ grep ZKLAMFAW *.csv
4Z7907551R.csv:"ZKLAMFAW","0x1edac","Zeitkonstante Filterung Anfettung durch Fahrerwunsch","1x1","16 Bit (LoHi)","-","s","-","-","1.0","1.0","1.0","13107.0","13107.0","0x3333","0x3333"
8D0907551F.csv:"ZKLAMFAW","0x1ca4c","Zeitkonstante Filterung Anfettung durch Fahrerwunsch","1x1","16 Bit (LoHi)","-","s","-","-","1.0","1.0","1.0","65535.0","65535.0","0xffff","0xffff"
8D0907551G.csv:"ZKLAMFAW","0x1c3f0","Zeitkonstante Filterung Anfettung durch Fahrerwunsch","1x1","16 Bit (LoHi)","-","s","-","-","1.0","1.0","1.0","65535.0","65535.0","0xffff","0xffff"

Something is screwy here.

This value is supposedly 2.000 seconds but we all obviously see 13107 and nobody has found a correct conversion.
Not to worry, math dude here to save the day.

Don't fret.  13107 / (2^16 - 1) = .20   So, we are off by a factor of 10.

Thus:  10 / (2^16 - 1) is our conversion constant.  Here is our formula:

Expression = .00015259*X          8 decimals on the formula

Try it:   .00015259 * 13107 = 1.99999713 ~ 2.000       5 decimals or 6 decimals accuracy depending on how scientifically trained you  beeee

There ya go homeys.

What boxes use CWLAMFAW=1 by default?  We should look for our ZKLAMFAW from such a default box as seen from the factory.

The filter is basically:

current value + ((|new value - current value|)*constant)

I was way off before.

Doc Brown does maf real gud.

hey you tubes! lol, i do MAF table revisions real gerd.
ok, so on subject.  what do you think of this LAMFA table?  please note the revised RPM and load points.
obv would like input from el trooperino from near cupertino on this table:

I think it's pretty bad for fuel economy.
Only place where you want enrichment through LAMFA is WOT really, run rest at lambda=1 and set BTS correctly so it takes care of EGT's at 3/4 throttle for example.

Otherwise you will just have horrid fuel economy, even when driving normally.

Mainly this is used to prevent enrichment in the emission test with drivers that have a nervous foot.
Only downside is that you may have a bit higher fuel consumtion if you have a digital driving style.

I agreed. I only modify the WOT line

I modify the 80 and 100% columns to ~13:1 and ~12:1 respectively.  Wideband and fuel gauge confirm it only works when needed.

I would only modify the last two columns.  Beyond that, your requested should be richest around peak torque.  (B5S4: ~3500-5000) and taper off to ~12.5:1 as the curve gets furthest from that point.  There's probably no need to be at .8 at 7000RPM.

I am using 0.001525902 as the conversion for ZKLAMFAW.

It is (sorta) the percentage of change per cycle (0-100). Better understanding here:


I am currently using a value of 50 for rapid change.

Has anybody tried to configure ZKWLAFWL (Time constant weighting offset engine target lambda)?
What influence does it have on target lambda? I guess it's related to KFLAFWL (Offset engine target lambda)
It's currently defined as a byte with value FF = 255 s
And i doubt it's correct definition.
I thought it should have been similar to ZKLAMFAW.
In FR LAMFAW 7.100 (Driver's Requested Lambda) it's default value is similar to
ZKLAMFAW
:
ZKLAMFAW: 2 s
ZKWLAFWL: 2 s

To increase the speed of change, the value has to be increased? FFFF is fastest change?

No, it is a time constant, so decreasing it makes the response faster.

Are you sure? The formula above would indicate that the value would actually make faster change the higher the number is and what phila_dot states above, along with his set up for this value, would make sense in that light.

The formula that I posted is directly from the code and is exactly how it works.

The conversion is my device and how I prefer to realize it.

So to confirm: the FR is incorrect, and it is not a time constant?

so 2.7t F and G box (stock) values seem to be zklamfaw = 0xffff (100%), and R box 0x3333 (20%)

phila: does this jibe with your understanding?

Yes, at least that is the case in our ECU's.


Yes, 100 (0xFFFF) would be no filtering. The value will jump to the desired value in the same cycle.

50 (0x8000), will take 11 cycles to reach the desired value going 50% of the difference each cycle.

Stock value of 20 (0x3333) would take (alot of) cycles to reach the desired value.

0, becomes 1 IIRC to avoid preventing change.

Edit: corrected error in number of cycles

Any idea what the "cycle" is then?

On the side note, I see that LAMKR is also filtered via this which has huge ramifications to anybody using map KFLAMKRL for enrichment on knock. This explains my experience with delay in fueling enrichment on knock I was experiencing to date which I always attributed to interpolation in the map itself, not the filter. It would make sense to me to switch filter to "100%" - no filtering.

Ecu cycle

This occurs everytime the code is run. The output filtered value is adjusted towards the input desired value whethers it's toward enrichment or enleanment.

Yes, this is applied at the end of LAMFAW and will effect desired lambda from the entire function.

Ok, so I'm slightly an idiot.

It will take alot more ECU cycles because it recalculates everytime.

So with ZKLAMFAW set to 50%, enriching from lambda 1 to 0.80:

1st cycle  : lamfa_w - 0.90
2nd cycle : lamfa_w - 0.85
3rd cycle : lamfa_w - 0.825
4th cycle .....

I should add that I was also running DLAMFAW at 0.008 to get back to lambda 1 and closed loop faster, but that might not be necessary if you FFFF ZKLAMFAW.

BTW i don't see that anybody posted the ME7.1 m-box location... i am using 0x1c3ee (hopefully I have it right)

I would like a confirmation on this as well.

0x1c3ee is correct guys.

Confirmation confirmed

I know is an old topic but i need ZKLAMFAW address for 8N0906018H  0004.
I have defined in 0x1C9EA with lohi and conversion 0.001525902*x with value 16.7.
Is it correct value, correct address?

NOBODY can help me with some advice for upstairs request???

Upload your firmware, I'll see it

here....

I know this is pretty old tread, but I found in one full map pack nice conversion for (KF)ZKLAMFAW.
So if you'd like to look at it like in seconds filtering, put reciprocal factor of 3276.8

If you prefer to see it like percentage change per cycle, than phila_dot factor (100/65535 = 0.0015259) is nice.