NefMoto

Opinions: using KFLBTS vs LAMFA for fuel all the time?

I really didn't like the idea of mapping fuel by requested torque% via pedal position, so I chose to use KFLBTS (current load).

Any thoughts why this may be a bad decision?

Thanks,
Rey

I think we have discuss that!

Lamfa axis is not PEDAL position!

KFLF is your answer if you like to have different fuel for different load. You have to calibrate ECU with a totally diferent way to make it work like that!

KFLBTS option is WRONG, there is the EGT model behind KFLBTS....

From my reading....

EGT is just a trigger for KFLBTS.

TABGBTS = on/off
FBSTABGM = EGT -> % of BTS correction to be used.

I set TABGBTS = 200*C (always on)
and FBSTABGM :
200 => 0
210 => 1
230 => 1
900 => 1

So, once 'calculated' EGT hits 210* I get full control of AFR via KFLBTS. It doesn't matter that my EGT model is off as long as 200*C is low enough.

KFFDLBTS all = 1 (deactivated)
LAMFA all = 1 (deactivated)

I tried, and it works as I expected.

ok didn't noticed the last!

KFFDLBTS = 1 is not disabled but enable the KFLBTS. If you set it to 0 then you deactivate with the RIGHT way the BTS!

When ECU understand "high temps" that means that you run over TABGBTS thershold, it calculates with different way a lot of things for high EGT!

So you have to calibrate the EGT model.

Sorry, you're right. I set this to 0 not 1. KFFDLBTS is an additive to KFLBTS.


My EGT model would be off whether I'm tuning or not since my setup is no where near stock -> http://forums.vwvortex.com/showthread.php?4260387 (http://forums.vwvortex.com/showthread.php?4260387)

For arguement's sake, say my EGT model was corrected. I would still try to use LAMBTS for fueling the same way.

TABGBTS looks to ONLY be used in LAMBTS and no where else. It doesn't look like it's used to affect anything else BUT on/off of LAMBTS which only affects target lambda. If I'm wrong, please give me one example where TABGBTS affects anything other than target lambda.



edit: I see EGT Limp mode, but several other conditions need to be TRUE also before that is enabled.

I've been following this in the other forum with much interest, great info!

Fotis, KFFDLBTS = 0 disables KFDLBTS not KFLBTS.

Rey, setting TABGBTS and FBSTABGM to 200ºC, gives you lambda control through KFLBTS, right?

Yes it did. I did a little more testing and 940*C TABGBTS = ~760*C pre-cat temp via vag-com and  810* TABGBTS = ~600*C.
I now have it set to 800-810. This makes LAMBTS off during lite cruise and on with any kind of load. But it's not quite a solid threshold. It moves depending of current airflow thru MAF and current IAT.
i.e.
with TABGBTS set @ 800-810*, logs showed LAMBTS coming on at different VAG-COM pre-cat temps in different situations:
low speed when AIT was high and airflow was low, ECU 'calulated' EGT a lot higher (relative to VAG-COM pre-cat temp) than when I was going faster where IAT was low and airflow was high.

I'll probably set it back lower. I don't think it matters as long as KFLBTS is set to 1 in areas where you don't want it (to let other functions use a higher AFR when applicable).

Lambdabts is KFLBTS + (KFDLBTS * KFFDLBTS). Setting KFLBTS to 1 where you don't need it won't disable bts, you also have to set KFFDLBTS = 0 to disable it.

KFDLBTS is an additive correction for bts and is function of ignition timing efficiency.

I've already set KFFDLBTS = 0.

I think the idea behind LAMFA is the WOT fuel-enrichment and not a base fueling map (like on many other ECUs).
This is why LAMFA depends on torque demand (by pedal) and not (actual) load. Demand is always ahead of actual load (timely)

2nd I do not like the idea of fooling the ECU to be in BTS to inforce a certain function. You always lose a bit of build-in security, don't you?

What is the intention of your way to fuel? did you get something you could not reach before?

cheers

oh, I missed a very important thing: seems like that lambda'ing only by KFBTS (and leave LAMFA = (1x1)) is already done in at least 2 original files by Audi in 1,8T and 2,7T.  :-\

Hello.
I have set my 1.8T ME7.5 fuelling only by LAMFA (flat at 1 plus some enrichment at WOT) and KFLBTS. KFFDLBTS all 0.
But I am trying to do it better. The KFFDLBTS and KFDLBTS tables works very good (seems that the ignition timing influence
on lambda is properly done by ECU), way better than simply KFLBTS, especially at middle load (part throttle).
The only problem is that this mechanism gives too rich mixture at high rpm and load (near 0.75). I would like to correct it,
but to make it working properly I think one information more is needed. What is on Y axis of KFDLBTS (%) ? Does anybody know ?
With that info we would know what to correct (KFFDLBTS, KFDLBTS or both) to make fuelling work yet better.

Cheers!

KFFDLBTS all 0 would mean you disabled the Lambda changes on ignition eta.
part throttle should be another kind of focus with resulting lambdas very near 1 or slightly above?

KFDLBTS is f(nmot,delta-ignition eta)

Yes, it was disabled. Now it's enabled and the engine runs better. Timing is also affected.

The part throttle areas in my program were almost all set to 1 via KFLBTS except for high load & high rev (enrichment up to 0,805).

Thanks for info. I left this map stock, while KFFDLBTS is lowered by about 50% for now.
That is enough for the KFDLBTS & KFFDLBTS not to enrich the mixture too much.
I'm still testing, but I think results are better than with KFFDLBTS disabled.

How do you tune that ? KFFDLBTS disabled or not ?
And how rich do you go in your engines ?
Any comments highly appreciated.

Regards
Goszu

I understood it as timing (delta-timing) was an input only and not directly affected.

Maybe you are right. Don't know if it's related.
Sience I didn't figure out how the timing model works yet I can't discuss it.

for example in 1.8T in extreme setups, I tune like that

1) deactivate KFFDLBTS
2) deactivate KFLBTS

tune only with LAMFA

for more safe maping, I leave BTS and make it little bit richer than LAMFA but increase the activation EGT threshold.
for example if lamfa is 0.828 at 6500, I make lamfa to 0.805 at 6500

Tuning these maps is not something standard, but is how a tuner want to tune an engine!

I've tuned my AFR using KFLAMKR and KFLAMKRL. KFLAMKRL is the lambda target based on knock correction, and KFLAMKR is the scaling factor. I've tuned the two maps to give me an enriched lambda under heavy load, and to enrich further based on knock.

I chose not to use KFLF because that affects the AFR under all conditions; it is the basis of all calculations for fuel injection based on load.

I never bothered with LAMFA because the driver requested power axis was wrong in my base tune. Driver requested power is from 0 to 100%, but the axis in the map is from 0 to 1.

That´s what I Guess the line of thinking of Bosch engineers to make ME7:

How do I make the best torque ?... with lambda about 0,90~0,95 ! just the way LAMFA work... 

Only when the temperature raises -something that the temperature model see as a maximum power demand (note I´m not speaking WOT) the ECU enrich (via KFLBTS) to ensure maximum power, and if there is some extra temperatura issue it will protect with (KFDLBTS ans KFFDLBTS).

If you modify the way Bosch managed to Work you´ll lose some kind of protection ou function...

if you want to tune via load the mixture, different mixture at 140% or at 160% or at 185% you can see at "steady map GAS temp" and make the EGT over TABGBTS value,

if that map read a value over TABGBTS then BTS enable and you tune only with KFLBTS, a proper tune on KFLDLBTS must be done!

Each tuner tunes different the ME7, but fistly you have to understand how ME7 work. For me took me a lot of time!
Each project needs totally different ECU calibration and for big turbo application you have to go off from "how bosch do it"

So....

Well, I´ll desagree

Bosch know how to make ECU... you can work as it was created without lose any protection.

There is one way to make ME7 right, there is some other ways to ME7 work nicely...and a plenty ways to make ME7 work... but just work... implies in lose something that Bosch project for security or economy or emission...

Tony,

From the above are you saying that you enrich when Knock is detected, ie when the engine is knocking, then it must be under high load.  In that case, this will need retuning every time you alter the ignition map, as there will be different levels of knock correction depending on how much advance you have dialed in?  Correct me if i'm wrong. 

It's an interesting concept, but being able to enrich due to EGT is nicer I think.   What happens when you exceed the EGT threshold, do you disable it?

Rick

My enrichment map based on Load and Knock allows me to force the ECU to add more fuel when knock is detected at high loads. I have tuned the ignition map when knocking to reduce timing compared to the non-knocking ignition map.

Ultimately I think you need to have a good baseline target AFR, and then allow the different enrichment maps to add fuel anytime something bad happens. I think enriching based on knock, EGT, IAT, etc, are all probably useful.

tested some 551K,Q box and LAMFA not working good in this ecu.
in 1.8T working great , but on this not
set 0.8 at high load but it working on low loads too, tested all rows because think  my rows as mixed but not.
EGT model was turned off.

LAMFA is requested load, not actual load. So, depending on pedal input and KFPED, you could be 'requesting' high load while actual load is still low. And thus LAMFA is requesting 0.8 at low actual load. Reason I don't like LAMFA.

I agree. I tried using LAMFA with limited success. I was looking into using LAMBTS (component protection) but I actually really like Tony's idea using the knock activity based fueling. Seems you could change the axis so that at 0 knock activity you can define a single axis of fueling relative to RL. Then keep additional fueling for high knock activity. This does not really reduce the ME7 feature set and allows us to tune a desired lambda indexed by RL.

In my 1.8T ecu (8N0906018AE) LAMFA doesn't work - idle and with part throttle i have about 0.945 (via LAMBTS) but in WOT i have about 1.020 and trying to set lower but ecu don't listen my wishes :(
Can be solved via KFLBTS? I am not sure i have KFLAMKR - i can't find that maps :(

Definitely. I do all my WOT fueling via KFLBTS. It may not be the best way (I'm positive there are other ways), but it works for me.

Thank you Nyet. But why in my case don't follows my settings and is 1,020?
I have stock turbo and 630cc injectors so it's not reason (lack of fuel) ...

Stock LAMFA is 0,9532 on 100% and 1 on 99% in my case - i need to set to 1 in 100% column?

Are you basing this on wideband data? Or logging a target AFR variable?

Lambas will follow the richest input.

On target AFR - wideband will connect after my big rebuild to final tune :)

No clue. I don't use LAMFA so I never bothered to see if there are other maps that have to be modified to use it for WOT fueling.

If you want to use LAMFA, you need to change the axis.

Rick

Going through the assembler code, it seemed as though LAMFA axis was 0 to 1, and not 0 to 100 as indicated by most map packs. But the input value going to the map lookup is 0 to 100, so I think for LAMFA to work properly, the axis data needs to be changed.

Correct :)

Can somebody explain why? Is stock LAMFA not supposed to be used?

Thanks all :)
I have axis without factor 16384 to 32768 so how i need to change?
I don't have to use LAMFA when KFLBTS is better, so tell me please how to set correctly in my case when not working properly with my setting (i think not bad) ...

Today rides - about 50% of PED = AFR was about 0.945 - more of PED = AFR grows to about 1.020 :(

Are you using VCDS, ECUx, ME7Log (Setzi's logger), or something else? What variable are you referring to?

btw. TABGBTS i have stock 750 ...

I have liquid tt installed. There is air fuel ratio option and takes data from ecu via obd.

When I first saw the assembly code, I thought "WTF!"

To me it seemed like a bug in how the assembly code mapped the pedal range to 0 to 100, which caused it to accidentally be mapped to 0 to 1. I never bothered using LAMFA after that.

Err wait. explain this slowly. Assume im stupid ;)

I am assuming the input to lamfa is *erroneously* 50-100 (not scaled to 0.5-1.0 like it should be), so the axis data to lamfa (6x1, 0x1C382 mbox) should all be multiplied by 100 (.5005 -> 50.05 ... 1.0011 -> 100.11)

Is that what you and Rick are saying?

In the FR the axis interpolation points for mrfa_w in LAMFA are 70, 80, 90, 100, 110, and 120%.

The factor for the z axis of KFPED is 0.0032052 and it is 16 bit LoHi.
The factor for mrfa_w is the same, but it is 16 bit HiLo. Either way it doesn't look right.

Has anyone logged mrfa_w?

The purpose of LAMFA is extra torque when requested by the driver.  It allows the enrichment of the mixture depending on pedal position/req load. 

From the factory it is disabled by setting it to lambda 1 everywhere, and having an unuseable requested torque axis of 0-1%. Reqested will always be above 1% so only this load column gets used.  The idea is the factory wanted to run lambda 1 everywhere for emissions and economy, and only enriched when egts' rise.  What this means is that if you try and use LAMFA to tune fuel factory axis you will always be rich.  Change the axis to 0-100% and now you can set the fuelling according to load, which is how it should be done.  For example at 80% req load and above i usually request lambda 0.82, then enrich a little more with KFLBTS.

Rick

Rick, thank you for your explanation. I will be adding it to the tuning wiki.

Thanks for posting the explanation Rick. I would have opened the assembly code up again to post more info, but my laptop decided to die. Now I just have to wait a couple of weeks for a new one.  >:(

holy crap.  big mystery solved for me.

New wording in AFR section of s4 wiki

Looks good Nyet :)

Rick

I am not convinced I have the proper conversion for the mrfa_w axis in lamfa.

What conversion are you guys using in your definition files for this?

Hello, great discussion. I've been following intently. In MY 2001 A4 bin, I notice lamfa is on as per x axis. I'm assuming this is because 1.8t are fitted with wideband? Which would lead me to my next question; if S4 are fitted with narrowband 02, why use lamfa at all? How acurate can lamfa be? Lamfa is requested AFR correct? How can ME7.1 accurately measure afr? (I know most of you have wideband...i hope.) I may be way off, if I am, its my lack of experience shining through. I'd didn't see any way of finding this answer without asking. Thank you.
 

Phil,

I'd have to check - but from memory it's 0.03 something. 

Rob - lambda is calculated, not measured.

Doh, thank you for clarifying Rick, makes more sense now. Still not sure why x axis on 1.8t is above 1%?

The axis vary between ECU's but LAMFA is always disabled in anything i have seen with all table entries being 1.

Rick

My map pack has LoHi, .003052

Setzi's logger has the same for mrfa_w:
mrfa_w          , {DriverRequestedRelTorque}        , 0x3827AA,  2,  0x0000, {%}       , 0, 0,   0.00305176,      0, {Relatives Fahrerwunschmoment aus FGR und Pedal}

Yes, spot on.

Thanks Nyet and thank you Rick for shedding some light on this.

I'm gonna have to log mrfa_w and see what kind of values I'm seeing.

I have seen some enrichment in lamfa_w, but it must be coming from the overboost map. Does anyone know exactly what triggers the overboost condition?

As far as I know, ME7.1 mbox overboost is never active

Sharing my tuning process for others:

KFLBTS is little richer (few percent)
KFFDLBTS is all 0,25 (before 0,5)
DLBTS is stock (for ignition eta keeping)

engine runs better and have more power than before (KFFDLBTS 0,5 :)

Will try to set KFFDLBTS to 0,15 ...

DLAMOB is all zeros.

The enrichment I saw must be from KFLAMKRL. That appears to be the only possible enrichment via lamfa_w in stock configuration.

So what is the location of the axis to change LAMFA values to something usable?

I am not at home now so I can't give you a straight answer, but you can open the "edit map in xdf" window in Tunerpro or map properties window in WinOLS and get the address from the axis. Then define the axis as a map.

Is the general consensus just to do 50-100%?

I looked at an old log that included mrfa_w and the logged values are from 0-100%, so I don't know why the FR states 70-120%.

wouldn't manually defining the axis map only make it seem like you're changing it... in the ECU the axis would still be 0-1%

No. Thats the point. The ecu is feeding it values from 0-100.

No, that would be if you changed the conversion to display the values you wanted. You need to define the axis as a map (with the proper conversion), and change the actual values to physically be the desired values.

Right so am I understanding that I need the info to define the AXIS map for LAMFA...

Just like Snow Trooper did with LDRXN..

just I'm guessing no one has actually defined a map with the AXIS for LAMFA yet?

LAMFA axis spec IS in the xdf.

in winols, you can edit axis data directly. In protuner, you'll have to make a separate table for it. However, you can see exactly what the location/scaling is in protuner by looking at LAMFA properties.

I'll add LAMFA axis to my map pack (for protuner users) when I get a chance.

Ah I understand now...

And is there a general agreement on what the new Axis should be?  Follow the FR examples? or something else?

Whatever you want it to be :)

It isn't shared with any other map (that i know of), so you can do pretty much whatever you want.

I'm guessing a simple linear scale from 0-100 is a good start..

Sweet... When I get a chance I will try a few revisions with this change...

Still want to make some logs with my current file though.

1c382, 16bit lohi factor 0.003052, 6 columns 1 row.

Cheers Rick! Thanks!

Even when LAMFA is setup correctly, what happens when driver requests full load at lower RPM on a big turbo car? Due to spool time, actual load takes a while to catch up to requested. All the while, LAMFA is dumping fuel in when the actual load doesn't need it.  I'm sure LAMFA is great with a small turbo. But what about larger turbos with longer spool times?

I'd say set up LAMFA for max power (12.5) and let BTS do additional fuel dumping if you need it for KR.

You can use BTS, but when the turbo is in it's spool zone, say below 4500 rpm, you would want lambda to be around 0.85 anyway.  Once above the boost threshold you're not going to see a measurable difference in spool whether you're at 0.78 or 0.85.

Rick

Agree 100% with Rick, as usual :)

i dont feel like this thread has closure...


i dont have anything to add as I havent played with it much yet beyond building the axis map in my definitions and then changing it, but I still am asking myself why audi didnt use lamfa.  Or am I mixed up?

any setup tips on the map?  Say we change the axis to 0,20,40,60,80,100... then what?  Would filling all the values with 100 be just like when it was all 1s?   I have read this thread alteast 3 times and something just isnt clicking for me, when I look at the map I am not even sure what values i would want to build it with.  are the values lambda, AFR?  herp derp help please  :)

Nope. Because if you don't fix the axis, LAMFA will ALWAYS be used if its lower than BTS, regardless of throttle position.

So the idea is, set up the "100" row to follow the curve you'd like to see based on rpm.

The problem is, you don't have a load axis, so you can't tailor it based on how "late" the driver mashed the throttle. IMO you really dont need to though. Just set it up so you get the fueling you want assuming the driver mashed the throttle WAYY before your boost really starts to build.

holy crap, i need to go do something really basic and then come back to this.  I am really confused...

So currently I mash the gas and the engine starts to increase RPMs which increases my spool, builds boost and then the car fuels off calculated EGTs, which are off load(boost).  this is all part of the BTS stuff.  I have fueling figured out there and I have it so that as boost builds it drops basically from 14.7 at partial load to mid 12s and then to mid 11s as boost peaks and holds.

what will lamfa changes do for me?  i guess thats where my disconnect on this topic is happening.  is lamfa supposed to smooth something out in the transitions?  Is the goal here to prevent from going too rich too fast or the opposite.

I am sorry i am being retarded, i really just cant digest something correctly here.

I think the problem is, in order to get BTS to get you enough fuel soon enough, you have to set the load threshold pretty low... and then you'll have really shitty fuel consumption part throttle, when the driver *isn't* mashing the gas.

This way, you can set up LAMFA to get fuel going early, BUT ONLY if the driver mashes the pedal.

Then, you can use BTS for ONLY high load situations, regardless of pedal position.

Make sense?

Using BTS only without changing the temp threshold, I don't see enrichment until about 14 psi (K03's) sometimes.

I set the mrfa_w axis values to 50, 60, 70, 80, 90, 100. I am planning on installing my ZT-2 this weelend and I will try to get some logs up. The file I will be using will enrich via lamfa to 12.5 AFR and further enrich into the 11's as needed via BTS.

YES!

Thank you Nye, now I have my head wrapped around it.  Thanks!

(using boost in lieu of load, I know it's not correct but easier to follow)

So, what you're saying is that there are times when 12psi doesn't need enrichment and times when it does, right?

If BTS is set to enrich @ 11psi, then 12psi will ALWAYS see enrichment, even when it doesn't need it. Thus, bad gas mileage.

On the other hand, if BTS is set higher eg. 17psi, and LAMFA is used. 12psi will only see enrichment if driver smashes the pedal (i.e. when 12psi needs enrichment according to you).

And since LAMFA does have a RPM axis so you're not enriching at very low load, I can see your point.


note: I've always assumed EGT threshold for BTS would be set low in order to use it for main enrichment - for the poster that mentioned only seeing enrichment @14psi

I agree with nyet. The lambda enrichment maps for exhaust temp, knock, intake temp, etc all enrich based on a condition that has already occurred in the engine. LAMFA can be used to respond to the drivers input before the engine conditions have changed.

Awesome. Finally got my fueling where I want it. LAMFA now anticipates peak torque without having to lower the EGT threshold too far. Notice the improvement the most on a long multigear pull... less knock under initial boost spike after a shift. Good stuff.

Just out of curiosity's sake, what are you guys setting your MRFA_W values to?  I would like to revisit my enrichment method to use LAMFA a little more effectively instead of relying on BTS.

(on a ME7.5 1.8T)


Also curious what you're setting EGT threshold at and where you see enrichment from BTS at that point.

Nice topic over here :) Now one thing i do not understand yet is how to make my fuel mixture leaner when there's almost no torque request (idle for example)? Right now I'm using E85 with KRTKE +30% and o2 sensor is always keeping me at stoich, when i would like to have leaner mixture at idle and low rpm and richer mixture at high loads

you have to disable closed loop.

so there's no other way? I mean, maybe there is some map which has lambda signal coefficient or something so i could adapt it for idle and on wot car goes to open loop anyway...

Well, I'll try to use KFLF map... Any suggestions on E85 AFR? (attached image)

KFLF won't help you if car is still in closed loop, you don't want to touch that.

And how can I force open loop instead? Which maps should I edit?

BTW: If car is in open loop does it still uses o2 sensor to reach target AFR?

Not on a narrow band ECU like ME7

Can't you just raise the lean limit and target a leaner AFR?

mine is ME7.5 and has wideband o2 sensor...

that's what I was thinking... just change target AFR and o2 sensor should adjust automatically to it... But Rick said that it's a no no

The lean limit is lambda 1 by default. Lamlgfmn needs to be raised to allow a leaner mixture.

Edit: i wouldn't adjust kflf though.

thanks :) if not KFLF then which map would you suggest to control target AFR?

Btw: maybe you know address/factor of Lamlgfmn on m box, so I could compare it to my bin?

It should be map LAMLGF or something along those lines. I'll look it up when I get home. Lean target lambda is the hard part as LAMSEL is set up to always follow the minimum/richest path and LAMDSK is hardcoded Lambda 1 by default.

Edit: Lambda lean limit is LAMLGMTM at 18CC0 factor 0.007813 and axis 1014B degrees celcius factor 0.75 offset -48. Stock is 1.093.

I don't think it will help though.

Hey Guys - i've been following this thread for a while and I'm not sure about alot of things here.

The stock DLBTS has a % that ranges from 4 to 17.  Surely this can't be that relevant right?  The values taken by the table are all negative, implying that when multiplied by KFFDLBTS - where the values are all positive, we'd see a decreasing of the KFLBTS target.  In other words, with everything stock, when the EGT model goes above TABGBTS, there is targeted richening of the mixture.
This obviously makes intuitive sense.

The question is why does the DLBTS axis go from 4% to 17%?  That seems like an irrelevant axis...  Does anyone else agree with this?  Why is this?

Here's the thing.  Everybody here seems to be talking about using KFLBTS as an actual functional target axis.  If this is true, we aren't using this table AT ALL like it was intended.  We are using it rather to distinguish between casual driving and high load driving, not normal driving and emergency conditions - as Audi used this originally.  Therefore we need a discussion about what needs to be done with the associated tables.

Here's my point of view on it.  KFLBTS should be a target AFR, and the additive tables (KFFDLBTS and DLBTS) should be zeroed out.  Input please...

I really think you have confused yourself.  There are 101 ways in which to work the fuelling, choose and calibrate a method that you think is right. 

Rick

lambts provides enrichment to combat rising EGT's. dlambts is an additive to lambts to provide further enrichment for a severely degraded ignition angle up top.

Why would you want to disable this function?

The axis is correct. The input for DLBTS, delta ignition angle efficiency detazwbs typical values are ~0 if zwist equals zwbas and retard is near zero. detazwbs is % of ignition angle effectiveness (zwopt-zwgru) - % of ignition angle effectiveness(zwopt-zwist). Only torque intervention or high retard will activate it. It is also a multiplier for KFFDLBTS which is zero everywhere but up top.

OK.  Thanks for that clarification.  Very insightful.  There's effectively no reason to turn off this inherent safety feature regardless of how you tune LAMBTS.  I understand this now, thanks.

I did a quick log with ME7logger yesterday during which I spend a good length of time at 100% mrfa_w to generate EGTs up to 933°C. lambts_w was unity all the time (presumably because the threshold temperatures are 950°C so LAMBTS is never active) and LAMFA reduced steadily from 1 to 0.89 (approximately "lean best torque at WOT") along the 100% mrfa_w line as nmot rose from 2,000 to 6,000.

http://nefariousmotorsports.com/forum/index.php/topic,1296.msg12400.html#msg12400

However, something more subtle is happening because desired lambda (lamsbg_w) and actual lambda (lamsoni_w) decrease well below 0.89 to around 0.75 (approximately "rich best torque at WOT") as EGTs rise above 900°C.

As Rick says, there are many and varied ways to achieve the same result. Before I discovered this, my personal prejudice was that using LAMFA for high load enrichment was perhaps crude way of getting out of tuning LAMBTS. This prejudice on my part arises, I think, from a comment a professional tuner made to me which I paraphrase as "I'm not going to reveal how I tune WOT AFR because many people don't understand the subtleties of LAMBTS".

All good fun.  :D

TTQS

I feel this thread lacks a summary a bit.
Obviously I understand that everything can be done in many ways, after reading through this, but the factory approach has emissions as nr 1.
For an approach that favors power/torque more than emissions, I would based on my research:
Leave EGT threshold for LAMBTS close to stock, and use LAMBTS as it was intended, for component protection.
Use LAMFA, and make it mimic the driving pattern. Usually the driver will go WOT at low RPM's all the time, but it is a bad idea to enrich there, as it will hurt fuel economy. I would tune LAMFA to enrich to around lean best torque, over a certain RPM where turbo spool up becomes instantaneous, and where the driver does not go unless he is flooring the car.
To get from lean best torque, to rich best torque and a bit below it (around 12:1), I would use KFLAMKR/KFLAMKRL.

So during a WOT pull (obviously they are all combined, but to illustrate my idea):
14.7 to 13.3 - regulated mostly by LAMFA initially at high requested load and RPM > turbo lag threshold
13.3 to 12.3ish - regulated further by knock control
12.3 and lower - caused by component protection.

LAMFA is used to get maximum torque from the engine during high demand conditions and to reduce the initial onset of knock during gear changes, KFLAMKR/KFLAMKRL are used for further enrichment to make best torque and LAMBTS is used to protect engine components. This way the ECU is geared towards best torque in all high load/high rpm conditions, while still being economical and having good emissions when the car is being babied.

Just throwing some ideas around, feedback appreciated.

fwiw i find that on 91oct you have to go a LOT richer a LOT sooner (well before peak torque) to prevent knock... more like 12-11.5

That's a good summary. I haven't had time to further analyse what method other than LAMFA and LAMBTS Revo has used to go below lean best torque at WOT but the lamfaw-lamkr method certainly seems valid enough (Tony uses it). I need to do a lot more logging when I get a new battery for my laptop, but lamfawkr_w isn't currently in the list of variables in ME7logger.

Thanks for a good summary of the position. Once I've deduced Revo's strategy in full, I'll update the 'understanding tuning' guide with a summary of all the salient points of this excellent thread.

TTQS

Yea, I know.
But I am in Europe, and I have 93 everywhere.

And you never really "prevent knock", it's always riding the limit anyway.
You don't gain much by going richer than 12. The additional advance is negated by slower flame speed inside the cylinder.

Agreed. Especially on 91. "prevent" is definitely more the wrong word.

On 91 oct, you need that much fuel preemptively just to STAY above 0 degs at peak tq.

But you are not gaining really gaining much (if anything) by running it that rich.
As you get richer than about 12.2 flame speed starts to decrease. Going richer means that while you can add more timing than before, you actually *need* more timing than before to make the same power, because laminar flame speed is decreasing and thus PCP occurs later with the same timing advance.
Sure, slightly richer mixture has the benefit of cooling the cylinder, but at some point you will get to the 50 cent "get rich or die trying" scenario.

If you try varying mixture levels on a dyno while adjusting timing to suit, at some point you will hit the barrier, you will also see, how there is almost no difference between 11.5 and 12.0 at knock limited MBT, so in that range you tune for best EGT. Your EGT's will eventually go up as well when going richer, as fuel starts burning in the EM...

Sorry for the nitpicking, just sharing some experience :)

thanks for the advice... i will definitely try to back off to 12 AFR again, but on my car, i was making more power from more timing all the way to 11.5 on 91oct.

i also tried less peak boost, but that also didn't work.

Hi - I like the theory discussion, very fascinating.  My experience is much like Nyet's, WOT AFR's higher than 12.0 seem to exaggerate timing interventions.  Certainly we'd all like to minimize the extra richness required to run safely, but I tend to err on the side of precaution while tuning this safety margin item.

I have noticed the same with a few 1.8T AMK & BAM engines, when going richer to 11.9:1 - 12:1 I tend to get more timing correction than 12.4:1 at the top end.  Used to keep adding fuel to reduce CFs, but over the last year or so I have found its not always the case.

I tune via LAMFA 99% request set to 1  just over 3000rpm then .89 upto 4500rpm then .84 to the red line, then all other load point over 75% I will tune to .91 upto 4500rpm and .85 to the red line.  All values below 75% set to 1 and  .89 over 5000rpm.

Then KFLBTS to dump me to .81 with egt threshold set to my own findings, stock manifold, stock cat stock exhaust a lower trigger vs performance manifold and full turbo back exhaust a  temp higher trigger.   I find the 1.8T engine make better power and run less correction the closer i get to 12.4:1

I think this is where I like Tony's approach a lot.
I also added LAMFA to the tune and gave initial WOT enrichment via LAMFA to about lean best torque from 3000 rpm.

The result should be that it gets initial WOT-enrichment from LAMFA, and then the rest of enrichment is LOAD and knock based.
It starts a bit leaner than rich best torque (12.6) and gets richer with knock.

I keep LAMBTS as intended for component protection only with a fairly high trigger.
This way the ECU basically tunes it's own fuel and timing to maintain 11.6-12.6 AFR. It just rides the sweet spot

EDIT:
Edited some rescaling info, as that affects other maps.

prj: i agree on the whole with your approach (and Tony's approach).

All I am saying is that rich best torque isn't rich enough for 91oct if you expect to get ANY timing at peak torque.

On 91 oct, you have to pre-emptively go super rich. I know, it sucks, but thats 91oct.

oregon 91-92 here and also not a fan of it... 

can somebody write a concise methodology for tuning via "tony's method?"  i'll re-read but again, as prj mentioned, this thread doesn't seem complete yet...


food for thought.  the rs4 has a TABGBTS threshold of 700...  the stock s4 has a TABGBTS threshold of 500...  so my gut feeling tells me prj's ideas are right, but i get the same nasty interventions that nyet experiences.

The RS4's TAGBTS is 750, not 700.

I've logged it quite a bit now, since it's my daily hack :P

The TAGBTS comes from turbocharger specification. The K04's were engineered to withstand higher EGT temperatures than K03's AFAIK.
It's really there to protect the turbos.

This is what I dont get: how does going super rich protect the turbos :)

lol, its quite counter-intuitive.  truth is that you are adding more fuel to an explosion.  LOL....

Let's talk a little bit about EGT in an engine, look at how the engine operates from factory and why LAMBTS is used to protect the turbos.
EGT is highly dependent on two things - spark timing and air fuel ratio.

Stock, the car spends most of it's operating time at Lambda=1, to produce the least possible emissions.
As it happens, peak EGT also occurs at lambda=1.
I already talked about flame front speed before. A faster burn while maintaining the same ignition timing is pretty much equivalent to advancing timing.

LAMBTS in a stock RS4 tune enriches roughly to lean best torque or 13.3.
This enrichment has the following consequences:
1. The flame speed increases (same as advancing timing a little)
2. We get further away from EGT peak (going both leaner and richer than 14.7 gives you lower EGT's, but richer is more effective).
3. We also can further advance timing because the additional fuel provides a cooling effect for the cylinder inhibiting knock.
4. Cooling the cylinder charge with additional fuel also means cooler combustion.

So, the way it is implemented stock, it is incredibly effective at lowering EGT when compared to operating at Lambda=1.
Think how the ECU is calibrated from factory. Emissions are king, so it is calibrated for Lambda = 1, thus what it does with BTS is protecting the turbos first and foremost.

KFLBTS, the component protection afr table, is on the standard m-box.  However, I can't find it on the RS4 F-box that I have.  Any thoughts?

0x19327 in F-box. The F-box map pack posted on here is missing about 200-300 maps.

I believe the peak EGT occurs under slightly lean conditions.  One of the reasons the factory aims for stoich is that while going leaner can increase gas mileage/efficiency the excess heat favors the formation of NOx and is an emissions no no.

A big effect of going rich as you pointed out is the large quantity of "cold" fuel being pumped into the system, and I think that is largely why it is so effective (conceptually for cooling/protection) because you have all those liquid droplets evaporating and that phase change takes a good bit of energy out of the process.

Actually EGT gets lower as you get away from Stoich...

I am following Tony's strategy by attempting to tune AFRs by using knock lambda control KFLAMKRL and KFLAMKR (kinda, don't have address for this table for mbox) and I run into interesting "problem".

First, I adjusted the table axis for different loads (higher range) and different knock amounts (first row is now 0.0).

It seems that regardless of  knock severity (run into -6.0 on dwkrz_ variables), it never follows any other than "0.0" row path regardless of retardation amount.

This makes me think that the table is not what we think it is... and he only way to control the LAMBDA is on 0.0 knock path but at least we then have load at out disposition unlike LAMFA.

Any clarification on this?

Lambda target from knock system is calculated as: (KFLAMKRL + DLAMTANS) * KFLAMKR

If I recall correctly KFLAMKR is only non-zero in a small range in its stock form.

are you tuning using this strategy or is this old news?

what is the kflamkr map address then? is there any way to force the ecu to amp the input kr values (I will log it tomorrow to see what wkrma shows)?

Posted map address here: http://nefariousmotorsports.com/forum/index.php?topic=200.0

The NefMoto Stage 3 Base tune uses this strategy, and it is what I run in my car.

Stupid question (KR enrich is a new topic to me)

Is KR enrich multiplicative to LAMFA, or is it just a matter of the lower one wins (like LAMFA vs BTS)?

Hrm. My reading of the FR is that lamfa = MIN(lamfaws,lamfawkr) (among other mins)...

The richest lambda target is what is used.

I did some logging last night to figure out why KFLAMKRL follows only 0.0 knock path regardless of what is really happening in the engine (knocking) and I found out the below:

dwkrz_0   dwkrz_1   dwkrz_2   dwkrz_3   dwkrz_4   dwkrz_5   zwout   wkrm   wkrma   dzwlamfaw   lamsbg_w
-2.25      -2.25         -2.25      -4.5         -3.75      -2.25         12         -2.25   -2.25      0            0.833253


As you can see, with the fair amount of knock, the ECU outputs wkrma=2.25 but then dzwlamfaw used for knock regulated lambda is 0...

I look at Funktionsrahmen and it looks like diagram on page 1022, specifically second diagram from bottom, shows how dzwlamfaw is calculated. The last Min(0, wkrma) calculation leaves no doubt that the dzwlamfaw will always be zero since it is a positive value in ECU?

This function also adds dzwwl to wkrma before the MIN(0,wkrma) but isn't dzwwl a warmup related variable?

I have a feeling that this path only applies to LAMBDA knock regulation during warmup and is otherwise inactive... But please correct as I am always wrong :)

IIRC dzwwl is calculated from two maps, one based on RPM and coolant temp (warm up), and one based on RPM and IAT. It is not only active during warm up.

This bit might explain what's going on:

CWLAMFAW Bit0:
0: dzwlamfaw = min ( 0, dzwwl)
1: dzwlamfaw = min ( 0, (dzwwl + wkrma) )

Defaultwert = 0.

I think I stumbled upon the reason why it doesn't work the way it should work. I appears that in all the tunes I have OLS files for (someobyd get m-box OLS finally!), the CWLAMFAW is set to "0000000000010000" or ""0000000000000000" which means that bit0 is set to "0".

This forces the dzwwl ONLY path. If we can find where CWLAMFAW sits in M-box (assembly gurus to rescue here please!) and flip bit0 to 1, the actual average knock will now we taken under consideration and perhaps map utilized to its full potential.

In Mbox, it appears to be the same as Gbox - 18ecb

but... its 01 not 00 :)

Also, its 8 bit, not 16...

Allright, you looked at assembly to confirm?

I compared the maps and "found" that region to be identical to G-box in hex editor but that doesn't mean all that much. I don't know if G-box is correct :) to begin with as it doesn't add up in my mind.

If it is indeed "1" from factory, then there is a problem here as the function never outputs anything but 0 regardless of conditions, it would appear, which renders the mechanism useless, or pretty close to it (you can still control lambda if you change knock axis and have 0.0 as a row and it will follow that path).

Another question is why the function would use MIN (0, "positive value of retardation") if the output will always be ZERO. Unless, of course, retardation is indeed kept as negative value in which case it would make sense. I am still getting zero in logs and LAMBDA follows "0.0" knock path.

Edit: Also,  I cannot log dzwwl as it is not listed in ECU definitions I generated. Anybody has that?

No I did what you did. Looked at hex.


stupid question: have you tried a negative knock axis?

Can't. Knock is unsigned byte with formula of "0.75 * x" which starts at 0 for "0.00" knock. It is not possible to use negative values.

Sign.

Any idea what the address for dzwwl? It might shed some light but it is not listed in auto generated list.

I'm not seeing that at all in the diagram... i'm seeing

0: dzwlamfaw = min (0, min (0, dzwwl) + wkrma)
1: dzwlamfaw = min (0, dzwwl + wkrma)

That's when you look at the diagram, I agree.

Notes on page 1026 say though:

CWLAMFAW Bit0: 0: dzwlamfaw = min ( 0, dzwwl)
1: dzwlamfaw = min ( 0, (dzwwl + wkrma) ) Defaultwert = 0.


So we have a discrepancy between diagram and notes...


Help me understand:

For positive values of both dzwwl and wkrma (which is how they are stored in ECU?), both paths will always return zero...right?

It just doesn't make sense from logical point of view  >:(

yea :(

we need setzi or tony to look at this; i don't know jack about disassembly :(

I will try to double check the assembly for this tonight. But this is the system I am using in my car, so I'm not sure why it would work differently for you.

I have a conclusion to the whole dzwlamfaw problem. Stick it in your WIKI nyet.

Facts:

1. Location CWLAMFAW  is right for mbox, it is 0x18ECB. I logged with "1" and "0" and got the results I expected. More on this below.
2. It is set to "1" (bit0 = 1) on M-box from factory.
3. No other boxes (RS4, A6, allroad, other S4) have this set to "1". It is "0" on other boxes.
4. Documentation states this should/is set to "0" by default.

This leads to a conclusion that Bosch/Audi released the m-box with CWLAMFAW set to "1" by accident (call it a bug), essentially DISABLING fuel enrichment on knock. The only residual lambda corrections I noticed came from dzwwl, which mean there is enrichment only from knock correction due to temps etc.

I set CWLAMFAW  = 0 and magic happened - dzwlamfaw  started following wkrma to a tee albeit it might actually exceed it if dzwwl would become positive.


Logs with CWLAMFAW  = 0 (set to what other audis have):

dwkrz_0   dwkrz_1   dwkrz_2   dwkrz_3   dwkrz_4   dwkrz_5   wkrma   dzwlamfaw   lamsbg_w  
-6         -4.5      -6.75   -6.75      -6.75      -6      -6      -5.25         0.801759
-6         -4.5      -6.75   -6.75      -6.75      -6      -6      -6            0.791505

Logs with CWLAMFAW  = 1 (Stock):

dwkrz_0   dwkrz_1   dwkrz_2   dwkrz_3   dwkrz_4   dwkrz_5   wkrma   dzwlamfaw   lamsbg_w  
-5.25         -3.75      -6   -6         -6      -5.25      -5.25      -0.75      0.818361
-5.25         -3.75      -6   -6         -6      -7.5      -5.25      -1.5         0.813966


My conclusion is that leaving CWLAMFAW  = 1 is not suitable to knock based lambda tuning since you will never get real knock values passed to function. Setting it to CWLAMFAW  = 0 will pass proper ignition retard values due to knock and with properly matched KFLAMKR table, you can essentially have self-balancing system where you run at some equilibrium between knock and lambda, as per that amp.

I find this method very intriguing since it might actually allow to have universal tune for different octane fuels and meth-no meth systems. As knock develops the ECU enriches more and more until a satisfactory state is reached where no further retardation of ignition angle occurs and you're at your maximum power point with given fuel/meth set up.

I'm confused now ..

dzwlamfaw = f(CWLAMFAW, dzwwl, wkrma)

... now please express f() for me based on your logging.

I am having a tough time figuring out what the actual path is because im dense :(

is it NEITHER of the ones in the FR (text and diagram)?

You're not dense. Document is obviously wrong either on the diagram or description below it. This fact alone suggests that formula might be anything in between... Couple that with butchered set up of the CWLAMFAW bit0 in PRODUCTION car and you really shouldn't wonder it could be anything...

If I had a crack at it, I would say that the formula in notes is accurate, not the diagram. We can tell for sure once we learn dzwwl's location and log it.

See, thats what I don't get, because that would mean that CWLAMFAW bit 0 = 0 would result in a dzwlamfaw that doesn't follow wkrma

Right. In that case the diagram might be right. Assuming the retardation is considered negative, min function would return wkrma adjusted by dzwwl.

I hope tony or setzi can find address for dzwwl.

damn julex, if you are right - which from what you've written i think you are, this is a major major find bro...

Glad to help again.

With CWLAMFAW set to 0 my car started self-regulating at WOT like nobody's business. I might go a bit lower on LAMBDA (lower AFR) as this was a first whack but my afr started at 13:0 at 4.5k with light knock and rode down to 11.5 which is my target at 7.2k... at the same time the retardation was controlled. I like it. I am not afraid to run out of meth now as high knock over -8 deg with douse the engine with 10.5:1 afr with current table.

just to verify, you are seeing it transisition off the LAMFA map and not the KFLBTS map?  what was your model EGT at the time of the "now working functionality" doing the enrichment?

wait wait wait.

so you're saying if this is right:

0: dzwlamfaw = min (0, min (0, dzwwl) + wkrma)
1: dzwlamfaw = min (0, dzwwl + wkrma)

then if dzwwl is sufficiently positive, it will always cancel out wkrma when CWLAMFAW bit0 is 1, but it will get clamped to 0 when CWLAMFAW bit0 is 0, letting dzwlamfaw follow min(0, 0 + wkrma) rather than min(0,0)

I shut off KFLBTS by raising its threshold model temp to 900C below which is doesn't intervene. I also adjusted the map to be more RS4 like where the richest point is significantly higher AFR (don't remember but I think I settled for 10.8 or so). RS4's values are much higher than that.

I reach 900C modeled temps if I do real long pull 5th or back to back in 4th. At this point the ATR would be about to kick in too triggered by EGT sensors so I figured a bit of pre-emptive intervention is in order.

I modified KFLAMKR so that it now has 0.0 row which makes it the driving force in lambda control. It has 6 ACTUAL load points (unlike LAMFA which has driver's requested load) at my disposal and allows me to set target lambda for any load, where it matters anyway.

Pretty cool stuff.

Tony was onto something pioneering use of this path.

I wish that was the case, however the logging with CWLAMFAW = 1 showed output of dzwlamfaw  to be equal to a small fraction of wkrma, as per me log excerpts above. I can't really figure it out without somebody looking at assembly to figure out what's going on in there.

I just thought this was the right way to do it.  ;) Glad I didn't copy any of the tuners.

Just spend five years looking at the assembly code without the OLS files, or the ME7 FR...

Anyways, back on topic, I will try to go over the assembly code for this tonight and grab some more info for you guys.

wow this is crazy! nice find julex!

great discussion gentlemen!

thanks for the great analysis Julex.

Nice work Julex!

8D0907551M 002
CWLAMFAW is a byte located at 0x818ECB
DZWWL is a signed byte located at 0x380DA5 Timing Offset Degrees 0.75 (positive numbers for advance, negative for retard)
WKRMA is a unsigned byte located at 0xF9B3 Timing Retard Degrees 0.75 (postive numbers for retard)

Here is the CWLAMFAW logic with the result of the equation being timing retard used for the table lookup:
CWLAMFAW 0: (max(0, DZWWL) * -1) + WKRMA
CWLAMFAW 1: min(0, (DZWWL * -1) + WKRMA)


EDIT: I added a code block of the assembly code for the CWLAMFAW logic.

Thanks Tony!

Looks like formula is nothing like either the diagram or notes under it. I will do some logging with dzwwl to see how it all plays out.


Thanks!

Note that this is equivalent to

CWLAMFAW 0: min(0, -DZWWL) + WKRMA
CWLAMFAW 1: min(0, -DZWWL + WKRMA)

... i.e. the diagram, sans the surrounding min() for cwlamfaw 0, which is presumably unneeded if wkrma is always > 0

Interesting :)

Great work guys. Looking forward to playing with this a bit later tonight.

Basically, 0 means "only let dzwwl retard dzwlamfaw" but 1 means "let dzwwl advance or retard dzwlamfaw"

sound right?

That is my understanding as well.

Pretty interesting discussion! I'm just thinking out loud, but I don't think it would be wise to tune an engines AFR running on E85 based off of this method, or maybe I'm wrong? I'm currently under the impression that knock sensors and E85 don't work well together?

In my file located at
http://nefariousmotorsports.com/forum/index.php?topic=1204.0

I'm pretty sure I found CWLAMFAW at 0x1902E. I'm not sure because at this location there is a value of 8??? Now I look in the FR, and it states this:

CWLAMFAW bit 4: 0: lamfwl_w dependent on B_stend and VZ1 gate
                         1: lamfwl_w: independent of B_stend and VZ1 gate
Sorry guys. I'm tring here ???
And I think:
KFLAMKR- 0x19097
KFLAMKRL- 0x190BB
Again, sorry guys, I'm tring here ???
As always, any help understanding FR/finding maps greatly appreciated.

I just wanted to bring KR based AFR tuning to a conclusion as it proved spectacularly successful in my case.

My observations:

I suspect that factory S4 M-Box tune (other S4 tunes might be the same) contains unintentional "test" version of M-box from factory or Audi engineers went berserk and tuned the car based solely on BTS + ATR basis leaving KR AFR corrections essentially disabled. The bit0 for CWLAMFAW which governs what corrections are used for KFLAMKRL (Lambda corrections during knock), is set to opposite value than all the other tunes for turbo audis effectively rendering this Lambda correction path ineffective due to the way knock input for this table is calculated.

At the same time, BTS is overly eager to enrich starting at 500 deg C, which is implies that BTS kicks in as soon as your car gets any boost. Even Stock configuration S4 will run deep into BTS lambda corrections. Stage 3 S4 without modified BTS table will run 0.63 lambda (9.2AFR!!!!) at above 6000rpms at full load.

I've seen my engine reaching 500C anytime I was just spooling up @3.5k to reach fulll boost ramping from there to 800+ and end of run. Now keep in mind that underscaled MAF configurations will not see temps this high since load is lower on these cars and therefore the model temp for BTS will be much lower.

It is noteworthy to add that RS4 tune has the temp threshold much higher (700C or higher) and its BTS table most enriched point is meager 13.0 odd AFR.

Since RS4 was tuned with much less aggressive BTS and it has full blown KR Lambda Correction enabled, it leads me to believe that this is indeed the way S4 should be tuned as well.





What needs to be done to S4 M-Box:

1)  Change bit0 CWLAMFAW @ 0x18ECB to "0" (not set)
2)  Neuter BTS by raising TABGBTS to some high value. I actually just set it to a value that works for my case which is 920. I reached 940C BTS temp at the end of 4th gear run (meth disabled) running at 12ish AFR where ATR (EGT sensors) sttarted kicking in indicating around 15-20C higher temp than BTS on bank1.
3) Adjust KFLBTS table to be more reasonable. I elected to scale it uniformly so that the higher RPM/Load AFR is 10.9 now.
4) Now the fun part. Adjust KFLAMKRL. This is your new LAMBDA/AFR table for ALL load points. You're going to say "wait a minute, it only drives Lambda values under knock...right?". Yes and no. In stock form yes, with modified KR axis it does not. Simply establish KR Corrections table and shift/modify first row to read "0.0" corrections and all of the sudden this table becomes responsible for all load points. Look up the definition of it under "X Axis" of KFLAMKRL
5) Redefine Load axis the same way. I elected to have 40,60,80l,120,168,191 load points.
6) Tune the data points in KFLAMKRL table. You want to leave lambda at 1.0 up to load of 120 at Kr of 0.0 as you should not see any knock until load of 168 (next load point) at stock AFR (14.7) and if you see any, the current AFR will shift to a row with respective knock corrections on it. You can leave most of the table stock except for 168/191  points and maybe massage 120 a little bit if yo uwant to ramp up nicer than just abrupt drop when you expect knock.

The results are superb.

I did several pulls with Meth injection off and settled on -6.0ish corrections at 11.5 AFR (theoretical and real matching) running FATS of 3.05.

When I enabled meth, I settled at -3.0 corrections while running real AFR of 11.3 and ECU fueling at 11.8 running FATS of 2.81.

It works. Should I run out of meth I will be ok since S4 now corrects AFR based on knock while before it would just die miserable death from detonation if -12 corrections were reached (limit, can be changed). With the new tune I would slip to 0.74 lambda which is pig rich imho.

I will probably massage the values a bit to get better AFR with meth but overall it just works since RS4 is doing it the same way!

Here is the KFLAMKRL table I currently run:

Awesome dude!

I am going to have to get this into the s4wiki somehow.

Oh, did you leave LAMFA stock?

wait - am i missing something?  CWLAMFAW is set to 16 for stock RS4.  what does this mean?

This is excellent, great work Julex.

here's an Mbox (Nye's) XDF with CWLAMFAW and the KFLAMKRL Axis that Julex identifies.

thx again Julex    :)

It means bit 5 or 6 is set, 0 is unset since it is an even number. Bit zero means 1 in decimal.

LAMFA is stock since it doesn't have any use anymore. 0.0 knock row from KFLAMKRL  takes over that function but much better since it works with actual load not the imaginary one from gas pedal :)

Edit: Just a reminder. It replaces LAMFA because the lowest lambda is always chosen in computation of final lambda. Should BTS or ATR kick in, they would take over since default ATR's delta for lambda is hefty -0.275. I found that table too so we can adjust severity of ATR (EGT sensors) intervention as well.

DLATRNLN, Lambda, 0x1C50C, 5x1, byte, signed, 1/128 * X
DLATRNLN  X-Axis, RPM, 0x1C507, byte, not signed, 40 * X

I can tell you it would be bit 4, but the effect of that I don't know off the top of my head.

this is the biggest m-box uncovering since the addition of NLS/ALS, imho...  great work!

My mind = blown.  As rob asked above, this theory of KR based AFR tuning would not work well with E85, considering MBT can usually be reached without significant knock throughout the rev range, yeah?

I wonder how long it will be before we start seeing some professional tunes cropping up that utilize this method.

I have a stock (mostly) 4z7907551R and it has CWLAMFAW at 113.

start your windows calculator, punch in 113 and hit "bin" button (XP) or switch to programmer mode (Windows 7), enter 113 and hit "bin" again. It will show you binary representation (bits) 113 represents which is 01110001. This can also be viewed in WINOls by hitting "111" icon on top when in a table of interest. They are reversed order - bits: 76543210. Bit0 is set in "R" to 1.

I checked RS4 and euro S4 bins and bit0 is set to "0" in there. Hence my overstatement, I guess, but then we already determined that US tunes are retarded anyway. I am almost tempted to flash euro bin one of these days and see if I pass emissions.

I already know that certain people charge extra for no lift shift and launch control derived from this site... but whatever.

Anyway, to your point. The whole point of running rich is to minimize knock. If you can run E85 without any knock at stoich 14.7 then great, you actually don't need any lambda control, right? Assuming there is any knock, even slight, then this still can be used but you need to make the table much more sensitive.

And let's not forget the other side of equation. Amount of knock depends on your timing tables. If you're mild there, you won't get much of it anyway. If you have extremely high timing, you will get knock. If somebody tunes E85 and puts 120 deg of timing and their engine blows up... they can only blame themselves here I guess.

I am not saying that my KFLAMKRL  table is the best, it is actually a first educated guess whack at it. Everyone will have to evaluate their goals here and adjust properly.

Cheers.

Awesome work.

What does this mean in the generic sense for someone just getting into self-tuning?

The way I understand it now... there's a map for global AFR (LAMFA), then maps for enrichment via EGT (BTS stuff) and then maps for enrichment under knock.  The consensus seems to be that LAMFA is utterly useless, though, because it deals with driver input, but not necessarily real-time engine load.... which is what we really care about when tweaking our AFRs to provide optimal power / protection.

What is the easiest / most sane path to achieving proper AFRs?  Should I even bother looking at LAMFA?

Reading back from the beginning, there is possibly some benefit using LAMFA if you need predictive enrichment before real load arrives. They potentially all do complementary enrichment.

Edit: LAMFA has best capacity to waste fuel IMO :)

From experience, 91oct is like this, even with water/meth. But if KR correction works, I will be using that instead of BTS enrichment for the rest of the time.

I agree.

IMO using all three gives you the best of all worlds. LAMFA provides basically instant enrichment, KFLAMKR could be main target lambda, and LAMBTS provides further enrichment as needed to combat rising temps.

Lambda will follow the richest input, so you can keep the mixture on the leaner side and adjust as conditions change. Instant enrichment on heavy acceleration, a little richer as load (and boost) catches up, enrich again as temps pass whatever threshold you choose, and finally if KR is pulling timing further enrichment as needed. This way you are only enriching as necessary for best power.

Yeah... I had to go back and reread everything to try and get a grip on things.  In the end, the lowest lambda should win for the lambda that the ECU will try and meet.  LAMFA is the global AFR, where only driver input is taken into consideration and actual load is not factored in.  Then things can be further modified by the BTS tables where compensation can be added for modeled EGTs.  Building on that, the KR AFR tables allow further enrichment based on current knock values.

Where I'm still slightly confused is that julex seemed to indicate that instead of the current approach of using the BTS tables with an artificially low TAGBTS value.. you could use the KR AFR tables to do the same thing and get more of a benefit... but I'm confused on how doing any targeted AFRs, as in "this is the AFR I want when things are working as intended", in a table that deals with enrichment under knock, is the "right" way to do it.  ???

"under knock" doesn't mean the engine is literally knocking... it means the knock sensors are detecting the onset of knock...

the beauty of what we have here is muddled by the complexity of it all.
here's my stance on the order of tuning now, and i think there's still a good bit of work to be done before everyone sees eye-to-eye on this stuff.
0)  start with a bone stock m-box, code out your egts and rear o2s and cats, to whatever degree you want/need
1)  scale mlhfm to your maf, either bosch or hitachi
2)  eliminate fuel corrections.  set the following maps to flat / 1.00 until rough fuel tuning is done:
       KFLF (partial)
       FKKVS (returnless fuel system correction)
       KFKHFM (maf correction factors)
3)  reorganize LAMFA, re-axis and at the least enable the percentages to be:  50/60/70/80/90/100
     set TABGBTS to 750 / 800  (like the RS4), and setup KFLBTS to have afrs in the 10-11 range, like a pure safety map

4)  get KFMIRL / KFMIOP sorted out
5)  set KRKTE and TVUB
6)  repeat 5 until LTFT's are zero'd out

7)  NOW you can turn on KR-based AFR's...
8.)  start tuning your timing and use KFLF / stft's to averge out your corrections
9)  repeat steps 8 and 5/6 until your corrected LTFT's are zero'd out.

10)  your car is an animal

Let me start by saying I have no idea how "sensitive" knock sensors are. And I'm fully aware of the "100 ways to skin a cat" adage, but I thought the idea was to keep the engine out of knock?
Which to me seams logical to do this;

LAMFA > BTS > KR

But the consensus here seems to be

LAMFA (if at all) > KR > BTS

Somebody school me.

Edit: My damn question was asked and answered^^^, sort of. You all type to fast, or maybe I'm not fast enough!  :P

Any steps here that would change if you were using a 1.8T?  I can't imagine there would be, but just curious.  Also, while we're on the subject... is there much to do in the way of tweaking the stock MAF table if you're on a stock MAF?  Should one even worry about KFKHFM if they aren't using a non-stock MAF?

before moving to 7, i'd make sure my target lambdas were being met during open loop with extensive wideband logging.

No, unless your intake is modified.

You guys are missing the point. You can use Knock based exclusively so long you establish 0.00 knock row. If you do that and stick in any lambda below 1.00, this will become the lambda car will follow as the lowest lambda takes over.

As such, you can ignore LAMFA, use BTS only for extreme temps and let KR path drive no-knock lambda with 0.00 knock path and then slip to lower lambda on higher timing corrections.

Keep in mind that table doesn't really indicate knock but timing corrections ECU is establishing TO PREVENT KNOCK.

This may work with better gas, but with Cali 91 I find that the instant enrichment provided by LAMFA helps immensely to prevent knock. Also, I don't really see the point of practically disabling BTS.

Why not use all of the tools available to us?

LAMFA > KFLAMKR (no KR) > LAMBTS > KFLAMKR (with KR, hopefully not needed)

To me this provides the ability to safely maximize power.

I think at this point we can agree to disagree :)

IMO there is more than one way to do things, and as long as we all understand the tools, I think we can all choose which strategy is best for the goals we have..

So it sounds like you're implying that by adding in a 0 knock row, you would shape your lambda curve, vs RPM, for what you want to see during a WOT pull.  I can't see how else having a 0 knock row, with only RPM on the other axis, makes sense any other way.

Again, that seems like an awfully odd way to utilize a protection table. O_o

KFLAMKRL is load and average ignition retard, it is offset by DLAMTANS based on IAT, and scaled by KFLAMKR based on load and RPM.

Too many acronyms.... can you break that down a little more? :D

Simply saying it is not RPMs on the axis but Load. As such, it can be utilized to lower lambda when it is needed which is under boost and ignition correction due to knock prevention mechanisms kicking in.

I don't like BTS lambda tuning as it is very in-discriminative in its nature. You either have it enabled for a given load/rpm or not depending if you have triggered it via TABGBTS.

If it is triggered, any value at given rpm/load point is your final lambda regardless if other conditions which would either allow the lambda to be actually higher (lack of knock) or lower (impeding knock) and as such is pretty inflexible.

It is important to run at the highest possible lambda as everyone knows that the most power is obtained at 12.6 AFR (0.857 lambda).

With BTS you have to tune to the lowest denominator to mitigate knock which is not ideal for all conditions and prevents the car to reach all of its potential. With BTS you just have to use low lambda to ensure a batch of bad fuel plus running out of meth (or system failing) doesn't land you in higher AFR than your system can take for current timing.

Anyway, as said before, there are more than one ways to skin the cat. This just seems like the best one. With 0.00 timing retard row in KFLAMKR BTS becomes completely redundant in all but extreme temperature conditions.

What happens if you were to run lambda>1 in this map to squeeze out better economy?

It would have no effect.

Read this:
http://nefariousmotorsports.com/forum/index.php?topic=1408.0

Thanks phila_dot, I do remember that thread along with this one.

 http://nefariousmotorsports.com/forum/index.php?topic=530.15

I forgot about it... :D

This of course got me thinking that just maybe we could investigate assembly code and see if the instructions to clip lambda at max of 1.0 can be altered to allow higher AFRs across the board... 1.1 would still be reasonable and allow the car to run fine.

Interestingly enough, even though there are numerous spots where lambda gets clipped to 1.0, I see that car is capable is to run at higher lambda when in VA mode (deceleration).

Yes, keep closed loop possible, but still allowing for 1.1 lambda in certain scenarios is a worthy goal.

julex - could you possibly share the following tables with us:
KFLAMKR, KFLAMKRL, LAMFA, and KFLBTS?

KFLAMKR - above
KFLAMKRL - stock
LAMFA - stock as it is useless to control lambda
KFLBTS (screenshot attached both in ECU format and AFR view of it):

1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00
1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00
1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   0.98
1.00   0.98   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   0.96
1.00   0.97   0.98   0.98   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   0.98   0.94
1.00   0.96   0.96   0.96   1.00   1.00   1.00   1.00   1.00   1.00   1.00   1.00   0.98   0.96   0.95   0.91
1.00   0.96   0.96   0.96   0.98   0.98   0.98   0.98   0.98   0.98   0.98   0.98   0.97   0.95   0.94   0.89
1.00   0.96   0.95   0.96   0.97   0.98   0.98   0.98   0.98   0.98   0.97   0.96   0.96   0.94   0.91   0.88
1.00   0.95   0.95   0.96   0.97   0.98   0.98   0.98   0.98   0.94   0.93   0.93   0.93   0.92   0.88   0.84
1.00   0.95   0.94   0.95   0.96   0.98   0.98   0.98   0.90   0.86   0.85   0.84   0.83   0.81   0.80   0.79
1.00   0.94   0.93   0.94   0.95   0.97   0.97   0.89   0.84   0.80   0.79   0.78   0.77   0.77   0.76   0.75
1.00   0.91   0.91   0.91   0.94   0.95   0.89   0.83   0.80   0.78   0.77   0.76   0.75   0.75   0.74   0.74

And remember, for this to work both CWLAMFAW bit0 must be set to 0 and TABGBTS must be set to semthing much higher than 500C. I have it at 920C, 20-30 degrees before ATR system kicks in (EGT sensors trigger), checked with logs as my load/maf is exactly spot on and reflects real life values.

Closed loop at 1.1 would be the goal, which means normal operating conditions :). I don't see any other scenarios when you would care for higher lambda, certainly not under any serious load.

With my limited experience, its hard to believe that Bosch doesn't have something, somewhere to allow closed loop lambda>1. As flexible as Me7 is? Don't get me wrong, I'm sure everybody has searched,... that's just nuts.

If I understand correctly, open loop dictates lowest lambda available is used? So in this instance anyway, knock sensors would have no effect on AFR. Would it be possible to run open loop at low loads with higher lambda via Ricks post in the above thread mentioned, then switch to closed loop after certain load to take full advantage of KR tuning?

How would you get closed loop 1.1 with narrowband O2 sensors?

err...  http://nefariousmotorsports.com/forum/index.php?topic=141.msg14594#msg14594

I am confused, are you editing KFLAMKR or KFLAMKRL?

Its been jumped back and forth for the entire discussion both here and on other related threads.  What map are you editing?  Because the RL map you posted is for sure edited from what I have with stock mbox.

As from what you all told me, you can't. What I'm saying is disable closed loop at low loads, run lambda>1. Then at elevated load, switch to open loop and run fueling as suggested here via KR, BTS or however you like.

I forget the map name to disable closed loop, but Rick mentioned it in the post I referenced above ^^^

Edit: Found time to look and see what map I was referring to; "RLLRUN". Is this idea not feasible? Somebody enlighten me.

RLRUN - I can't find such map in any full OLS files.

I found a way to run closed loop at higher AFR (by telling the use to use different switching point of o2 sensor than 0.445v which is 14.7), look at me separate thread titled "Lean Burn......"

Sorry, mentally flip flopped the maps. Obviously the screenshot tells you which map is modified.

Sorry, my mistake. I believe the map that Rick was talking about is RLLRUN. I fixed the above post as well. I looked in a couple OLS files and found it.

I'm not sure that I'm totally sold on recalibrating the "sweet spot". I have read your thread, and its intriguing. I have not been able to locate the map that you referred. I have to do some more reading.

Can anybody tell me what the pros and cons are of running closed loop leaner AFR as opposed to open loop leaner AFR?... Well besides the obvious, that closed loop would be with sensor input.

I am totally new to this, but I was attempting to read the function and data sheet and noticed the following on p. 676 regarding the stochiometric ratio (it seems to imply that it can be adjusted (rich or lean) away from 1 through LAMSBG_W [fuklamsbg (1515A in 4Z7907551R)]:


Variable Source Type Description
LAMSBG W LAMSOLL EIN Desired Lambda limitation (word)
NMOT SWADAP EIN engine speed
RK2 W GK AUS relative fuel mass Bank2
RKA2 W LRA EIN additive adaptive correction of the relative fuel amount bank 2
RKACO W EIN Additive correction of the rel. fuel mass for setting idle-speed CO
RKA W LRA EIN additive adaptive correction of the relative fuel amount
RKTE W TEB EIN relative fuel part of the purge control
RKUKG W ESVST EIN rel. fuel mass transition compensation
RK W GK AUS relative fuel mass
RL SWADAP EIN relative air charge
RLP W BGRLP EIN rel. air charge predicted for injection calculation (Word)
FW GK 13.10 Fixed Values
Parameter Value Description
FB GK 13.10 Detailed description of function
The function GK calculates the relative fuel mass rk w necessary for the predicted relative air charge rlp w of a
cylinder, for combustion at Lambda = 1.0. The standardisation of the two variables rlp w and rk w was chosen such that, at
100% air charge 100% fuel is also required for combustion with the engine at operating temperature and where Lambda = 1.0.
The stochiometric ratio of air mass to fuel mass in the cylinder is designated here as lambda combustion chamber,
as opposed to lambda sensor, which is measured on the lambda sensor and may deviate from lambda combustion chamber due to the
introduction of secondary air. In normal engine operation lambda-combustion chamber = lambda-sensor.
The function ESVST delivers the pre control values fgru, fst w, fnswl w, fwe for lambda-combustion chamber = 1.0.
This lambda combustion chamber can be shifted to "rich" or "lean" by way of the desired value of lambda LAMSOLL to improve
engine running (engine protection, lean running limit) or to comply with exhaust specifications.
The function GKRA includes mixture adaptation (rka w, fra w), canister purge (rkte w), canister purge diagnosis and
lambda control (fr w).
The continuous lambda controller controls each bank to the required lambda (lamsbg w, lamsbg2 w), which is
formed in the function overview LAMSOLL.
During secondary air the input for lambda controller is lamsbg w =lamsons w,lamsbg2 w=lamsons2 w, lambda-combustion chamber
is # 1.0.

What you are refering to can never be leaner than lambda 1. It will always follow the richest input and has lambda 1 values hardcoded.

The point is that open loops' AFR could really be anything several % points either way of what you think it is based on fueling tables. You will run few tenths of lambda either side of desired amount... and god forbid your maf curve, or more precisely the *clusterfaq* (had to use that word...) KFLF and KFKHFM is (some insane person calibrated these), doesn't match your intake. If you changed ANYTHING on the intake path, MAF diameter, turbos, intake pipes, cone filter, etc, these maps essentially don't apply anymore. They are calibrated for stock intake. When you forfeit using closed loop, you start to exclusively rely on them.

If you really want to see how inaccurate they are, log the car and do some mild acceleration through the RPM range and look at lambda corrections... you'll be scared once you realize that if not for the closed loop, you'd be hanging 10+ % on either side of lambda 1.0... that's 13...16 afr. Closed loop ensures that the system self regulates to stick to the o2 switching point which is 14.7 with narrowband o2 sensor...

One more thing. If you see ANY long term fuel corrections, it means that you have exceeded 10 or 15% (I forget what the threshold is) of lambda corrections in the past.

So... if you force open loop for all the time and you flash that, then it means that:

1) you disabled clsoed loop
2) your system will never store long term LTFTs
3) you might be running REALLY off the target fueling.

Just make sure you wideband o2 hooked up to monitor real AFRs.

On the side note, the KFLF and KFKHFM are a mystery to me. More precisely, the mystery is why they subtract from one table and add to the other creating overly complicated relationship where just doing KFLF would do.

I know, somebody will say "but if you just do KFLF then you will inbalance something in the ECU as you're playing with fuel mass correction etc, etc". Well, just go and look at RS4 factory map. The way they did that one makes far more sense. They left KFKHFM alone (defaults to 1.00 for all points) and only adjusted KFLF. You can finally see the full picture when looking at just one map.

I think I will reset my MAF corrections map as well and only do KFLF.

Cheers.

If you look at  flow diagrams for lambda paths, you will often notice logical gate where it says "MIN". Its input values are "1.0" and some lambda variable value from maps or other modules. This is where the ECU chooses lower value from two inputs.

I think you just realized what that means?

It means that given a lambda request/variable which is larger than 1.0, the ECU will choose lower value which is a hard coded "1.0". Ot of the window goes your anything higher than 1.0 in a table. When input variable is less than 1.0, the ECU will follow that request since it is less than 1.0.

The only way to sway the system towards running leaner (lambda more than 1.0), is to lie to it via some fundamental sensor input so it thinks it is at L=1 but in reality it is not which is really all we care about. By making the system think the o2 sensor's lambda point is lower voltage than what the stock value is, accomplishes that.

KFKHFM is 1.00 in the RS4 tune exactly like you said.  Also FKKVS is 1.00 in the RS4 tune.  As you suggested, I agree that KFLF is the best way to tune corrections.  My belief is that the correct way to do it is as follows.  Setup a full logging session, ideally 30+ minutes of 10 Hz for all the relevant variables.  Take the following:  Corrected Load vs RPM vs Average of Lambda 1 / Lambda 2.  Thus you'd have a very lengthy time series of these three variables synched up.  From here you take a two-dimensional curve-fitting tool, which bins and self-groups the data to build a surface.

This surface will then have the axis of the KFLF tables, one can visualize not just the local average but also the standard deviations of lambda corrections.  The necessary changes will be obvious and relatively smooth.  Then take this this map and create a blending table.  The blending table takes x% of the value from the "theoretical curve surface" and (100-x)% from the 1.00 constant table.  This is a goal-seeking technique known as "mixing", we'd likely start with x=50.

This multiplicative inverse of this blended table with x% is your new KFLF.  The likelihood is you'll need to recenter your LTFT's after the first KFLF revision.  My guess is that further KFLF repeats of this procedure and effective refinements using this methodology will require progressively less KRKTE/TVUB adjustments.

This is exactly what I was thinking to do but at this point of time I fail on a technical level of finding such tool and properly feeding it the data. I don't even know what software would that be. Some statistical analysis tool?

Heh, no fault there.   MATLAB all the way.    If you get me those vectors, I'll attempt it...    i can try to use an old log today.

I'll dive into this and cry for help if needed. Men don't ask for directions :)

Your method assumes KFKHFM = 1.00 everywhere is correct... which is generally far from the case :(

You are tuning fueling assuming your MAF data is correct (which isn't true).

In fact, I used a variant of what you suggest to tune my KFKHFM table, assuming the fueling is correct (which also isn't true)

If you really want to do it "right" you have to figure out how to tune one without depending on the correctness of the other.

To do it right without relying on "The other one" (depending which one you chose to use) would mean resetting the other one to "1", set the table you want to use with result of multiplication between two tables for all respective cells and voila. Then, just to prove the point, you have to drive the crap out of the car in low/med load conditions. Analyzing the logs afterwards and adjust as needed.

Looking at RS4 tune it all makes sense. Looking at S4 tune it does not. S4's fueling seems to jump all over the place once you combine both tables, RS4 is much more linear. I would like to see some long ME7L logs from stock S4/A6/allroad (they seem to share the same overly complicated fueling tables) to see how lambda behaves. I have no trust anymore in whoever came up with these and I bet the lambda travels around like a drunken sailor :)

Ha. No kidding :)

I reset KFKHFM to "1.0" everywhere,  interpolated "by hand" the table for KFLF using excel "paste special" and "multiply". Load and RPM are close enough. Resulting table looked ok so I loaded it in and proceed to logg the car. I ssed Nyet's Ecux Plot to graph the session (awesome!) and see lambda behavior and sure enough. In spots I initially saw as suspect where S4's table dips in the middle of otherwise normal values, the fueling goes off the track and corrections are made.

Nothing drastic though, it never goes beyond short term +-10% so my long term corrections stay +-1% from 0... I compared the spots I noticed being off in logs to new KFLF map and long and behold, the weird odd values in few spots are responsible for these near 10% corrections...  then proceeded to review the shape of map and compare it to RS4. The aforementioned dips are not in RS4 tune so I smoother the S4 map following the RS4's principle and the car is super smooth now.

This kind of proves the point imho that the more we unravel  US 2.7t, the more dirty laundry we expose.

julex: i'm working on implementing a heatmap grapher for x,y,z data that might help.

it wont be 3d, because heatmaps are easier to generate :)

Ok, so are you saying the suggested method I thought of seems to have improved the fueling accuracy?  If I'm understanding correctly, then we've made a big step here in refining the tuning procedure for fueling (which we all know is near the beginning of a new tune's calibration.)

Anxious to hear your response, lol.

Accuracy? Not likely since now I am using only one map with arguably lower resolution (KFLF). Maybe using KFKHFM would give more resolution but adjusting that map also directly affects load ECU is seeing.
Simplified? Hell yeah. You see how the fueling behaves by looking just at one map instead of going back and forth between two maps.
Does it work? Yes, very well. Just like on RS4.

Previously you could not just follow KFKHFM or KFLF and assume that if a given cell dips in value, the multiplicative product does the same as frequently a corresponding cell in the other map would go up and vice versa.

You have to keep in mind my special circumstances though. I am not running stock intake. I am not even running original Hitachi MAF. I am running custom intake comprising of AEM cone filter embedded in daringtaked stock S4 air box, 3.5" aluminum tubing for mustang 90mm MAF and HPX MAF element. From there it becomes "stock" RS4 accordion hose and then normal allroad/S4 intake to K04s and rest is pretty much stock.

You have to keep one thing in mind though. Audi felt that it is ok to not use KFKHFM table for RS4 equipped with "just" 82mm (or whatever it is) bosch maf and regulate any irregularities of engine fueling exclusively via KFLF map.

IMO they realized that having an accurate load just isn't that important EXCEPT for open loop fueling...

i think with a proper wideband setup, almost none of these crazy corrections would be necessary.

So is this thread going to pioneer the integration of a WBO2 sensor now as well?  :P

I would absolutely LOVE to have that!

I saw some Audi TT CB box maps where KFLBTS is all 1. So how is this box providing enrichment at higher loads other than through kfdlbts and kffdlbts (which i guess is active only when the engine knocks).KFLAMKRL and  KFLAMKR also is all 1. So what if there is no knocking.
Also supposing my FBSTABGM = 0.5, kflbts = 0.7 , kffdlbts = 0.6, Kfdlbts = -0.64 ,how will I calculate my LAMBTS.
Thanks

The 0 CF row will define your fueling if no knock.

Lot's of people seem to be not understanding this very crucial piece of info. :). This is what makes fueling via KR viable as main fueling path.

Yes, I can't imagine anyone thinking this was working properly when seeing lambda 1 until you hit CF activity or your EGT target. It's working nicely in my tune now, I like it. I still think LAMFA has it's place at higher RPM points where load transitions happen very quickly under fast shifting.

dunno about that. The fact is that you can only shift from higher to lower load in an instant. The other way around takes time. However, even if true, you're assuming ECU is somehow lagging in its load calculations which if true, would ruin your engine many times over to date.

The ECU calculates load out of mainly MAF flow and then does some modeling as to how all that air behaves before it even reaches our cylinder. Injection time is also a real time calculation affair which is calculated by looking at air flow and tons of other variables including all the lambda paths. Simply there is no such thing like fueling "lag" which you're trying to use as an excuse to employ LAMFA.

I used LAMFA only for couple of days and not as main focus of fueling effort (only to pre-fuel the engine when testing KR feling), like you are trying to, and I believe that I could not really use it properly as that map seemed to fall victim of multi-point interpolation where I wasn't getting as low of a Lambda as I wanted in my table but something higher slowly falling with time spent at the driver's requested load level. Many maps don't use absolute values at a given point of table but are interpolated and mean weighted with the adjacent points so if your LAMFA falls to say 0.75 at 100%, it won't immediately dump 0.75 value into Lambda path once you hit 100% driver load  but will actually lag and gradually approach the 0.75 you want. But it might take a while.

Again, that was my observation, I believe, but maybe I am all wrong about LAMFA after all. It just has no use anymore with "0.00" knock path in KR lambda

Sorry, I know the ECU isn't 'lagging', my word choice was poor. When desired lambda goes to a rich target *before* the load hits hard, wouldn't the transition be weighted more than not?

The question is why do you want to go rich BEFORE load ramps up uncontrollably at that (because you will set the fueling blindly without any knowledge of actual fueling conditions) and not DURING the load ramp up... All you need is DURING - hopefully controlled so that you get as close to 12.6 as you can where you get best torque out of cylinder.

But to each their own. I like the KR because it allows some degree of flexibility for ECU to choose the highest AFR, table allowing, not just bringing everything to lowest denominator of "worst case scenario (lowest) AFR I feel safe with" as other ways of fueling usually are set up.

two words.

91 oct

I'm currently using Julex's KFLAMKR method of KR AFR tuning on 91 oct (granted running less timing than he is), check out my logs here and feel free to comment: http://nefariousmotorsports.com/forum/index.php?topic=1537.msg15243#msg15243

Guys I have no clue what you are discussing. what is 0 cf  ???, can you give me a link or something so that I can keepup.

CF is "correction factor" aka timing retard

just a quick heads up.  i'm going to merge my nyet-20110825 with NLS / ALS and this M-box valentines day surprise.
i'll update my XDF on the appropriate page and link it to here.  will update linkage when finished.

tables will be set to default values and i'll provide exact suggestions on values people have been generally using.

more to follow...

I would like to thank all the members here for the on going research. Really, this is an immense help. Going to try to test this out tonight.

Updated version of Nyet's 08/25/11 map pack including ALS/NLS and the developments from this thread:

http://nefariousmotorsports.com/forum/index.php?topic=736.msg15323#msg15323

Also, can someone assist with the correct tunerpro screenshots to add the table KFLAMKR?    That still seems to be missing.  Julex can you get screenshots of the actual KFLAMKR table values you are using?  I know you already posted your KFLBTS and KFLAMKRL, as well as telling us that you are using LAMFA set to all 1.0.

KFLAMKR stays stock. It is a multiplier for KFLAMKRL table which allows you to fine tune response at whatever RPMs/Load point you want.

How is that possible?

Unless my definition is wrong, KFLAMKR is mostly zeroes and values less than one.

EDIT: FWIW my definition matches the specs that Tony posted.

Why not adjust axis making the 2 nodes around your desired transition point very close to each other? e.g.
if you to go from 1 to .75 AFR after 80% load make axis
RL -> .... 40 50 60 70 80 82 100
               1  1  1  1   1  .75 .75


Assuming the axis is not used for any other map.

S4 M-box KFLAMKR for your viewing pleasures is attached.

Just to add to this... I recently looked into an AWP (1.8T) ECU where I noticed this method was NOT used for fueling.

Just food for thought, looks like BTS is the way fueling is done in that ECU. 

Not saying one way is wrong/right... just there is always more then one way to skin the cat :)

Thanks Julex. I have the same address. I'll have to double check my conversion and major order when I get home.

I have the same settings with much different results. Screenshots below are the same in both versions of M box that I have.

(http://i845.photobucket.com/albums/ab15/phila_dot/image002.png)

(http://i845.photobucket.com/albums/ab15/phila_dot/image001.png)

I apologize, I must have inherited this from tony's tune. You're right, stock S4 KFLAMKR is useless and needs to be altered. FWIW RS4 KFLAMKR is 1.0 in all cell.

I was wondering whether all this is valid for 1.8t engines. Please validate my understanding of fueling as follows.
IN my stock hj ecu  say if I floor the pedal at say at 1000rpm, then immediately lambda goes to about .95 from the lamfa map for acceleration enrichment .
And if there is any degradation in timing (onset of knock I guess)  then KFFdlbts and KFdlbts starts enriching.

And as the EGT's go above  900 (FBSTABGM is set to 0 at 900,0.5 at 920 , 1.0 at 940 and above) extra fuel is added for component protection by kflbts.
I dont understand how the fueling based on KFLAMKR and KFLAMKRL is any better. On my car CWLAMFAW bit zero is set to 0. And I am attaching my   KFLAMKR and KFLAMKRL to me it looks all disabled, please confirm that.
What I dont understand is the difference between Knock enrichment by KFFdlbts/KFdlbts and KFLAMKR/ KFLAMKRL.
Hope somebody can help me understand this As I have been struggling with this concept for quite some time. ???


 

bts is EGT based, not knock based

Plainly, as I understand it:

Lamfa = Fueling based on pedal position. Does not relate to actual loads.

Kflbts = Forced fueling based on egt. If set at stock egt or raised threshold levels then it will be your component protection by dumping fuel, your set lambda, once threshold is reached. Forced fueling by low egt disables this component protection. Kffdlbts is factored in to Kflbts as lambts = KFLBTS + ([KF]DLBTS * KFFDLBTS)

Kflamkr = Fueling based on knock recognition, it is preemptive. With CWLAMFAW set at zero, which not all ecu's are, KR fueling is enabled. You make the car follow kflamkrl based on knock. If you don't knock you are following the 0 column. The values in the table are lambda; use a calculator to convert to AFR if you tune based on AFR. The values on the left side are load. Change these to represent your assumed load values or follow julex's on page 12 of this thread where you max at 191.250. Your car will now adjust AFR based on load vs knock recognition value. However if there is knock recognized you are now able to fuel based on degrees of knock beyond the first 0 column.

Fueling within the entire system will follow the richest set point where ever you may have set it within any of these variables.

Someone correct me if I am wrong.

Thanks I understand it a little better now. So in my stock map  KFdlbts = 400°c , so bts is activated early on so ..is it not that  KFFdlbts and KFdlbts is doing the function of knock enrichment as the value of multiplier Kfdlbts depends on the degradation of timing , and will have the same effect as using KFLAMKR/ KFLAMKRL or is it better to overcome my fear of KFLAMKR/ KFLAMKRL and use it. In the stock form its load axis is so weird it scares me  :).  Please bear with me.

If you still use BTS for fueling, you run into a couple problems. Either you dont get it because you have not reached temperature threshold. You reach temperature threshold, but now that you have your BTS fueling you have no component protection. (irratic in my case) It is better to have, in my opinon, fueling from kflamkrl while still having bts for component protection.

I have been working all kind of tuning methods for fuel for the last 10 months. KR fueling is the best I have come by as my car is nearly spot on and is 100% better. I do of course have the others tailored to where I want them for a few tweaks.

So obviously KFLAMKR/ KFLAMKRL is disabled in my stock file as the max load is 90 and all values are 1 and stock enrichment is all through bts, can somebody confirm this.

Can someone show a 2d image of KFLAMKR and KFLAMKRL

Look at the first post on this page.

you'd have to check CWLAMFAW to see if it is really disabled or not. Having "1"s everywhere though ensures that even if CWLAMFAW is "0" (which enables KR based fueling), the output lambda from the table will always be "1" which in practical terms means "disabled".

having load at 90 max only means that beyond 90% load, regardless if it is 90 or 190, that value will be used for whatever the table is used for. That's why we frequently re-define column header values to different load values to get more control in high load scenarios.

Thats what is interesting CWLAMFAW is set to 0 but function is disabled by setting both kr maps all to 1.

just one of the ways to skin a cat I guess.

which is the theme of this thread ;)

Bit 0 of CWLAMFAW does not enable or disable this function. It only changes how dzwwl and wkrma are evaluated.

this thread is making alot of progress.  [let's gather the screenshots, explanations, and anecdotes to prepare for the s4 wiki...]

In the tune I posted, I altered KFLAMKR relative to stock. In stock form KFLAMKR is mostly useless.

I'm glad this thread is still going. I think it has grown by four pages since the last time I checked.  ;D

Let's not be anal about it. The net effect is that it is effectively disabled due to the way it is calculated with bit set to 1 :)

So, are we tuning the kr map or not?  Julex have you tried a stock kr table and seen what your krl changes do?

Just trying to make the point that you can see enrichment regardless if CWLAMFAW bit zero is set or not. It just will not be very predictable.


KFLAMKR needs to be modified. In stock form KFLAMKRL is useless.

too much information on this thread!  everyone is confused...   lol!

OMG... I know in stock form the RL map is useless.  There has been mixed info in KR this whole time.  People keep exhanging them as one in the same.

I was trying to say KFLAMKRL is useless with stock KFLAMKR.

lamfawkr_w = 1-(1 - (KFLAMKRL + DLAMTANS) * KFLAMKR)

(http://i845.photobucket.com/albums/ab15/phila_dot/image002-1.gif)

CWLAMFAW = 0

dzlamfaw = min(0, min(0, dzwwl) + wkrma)  This is the x axis for KFLAMKRL

dzwwl = KFZWWLRL + (KFZWWLNM * FZWWLRLN)

KFZWWLRL  - nmot, tmot (coolant temp)
FZWWLRLN  - rl, nmot
KFZWWLNM - nmot, tans (iat)


(http://i845.photobucket.com/albums/ab15/phila_dot/image002-2.gif)

ok almost there.  now we need to take julex's advised set of tables and create a similar picture.  lemme see if the info is here yet...

please verify julex.

KFLAMKR table screenshot forgot to mention the following conversions:
row:     3*x/4
column:     40*x

map-pack will be updated soon.

phila_dot can you please include table definition information for DLAMTANS?
julex, is your DLAMTANS all 0?  if not please upload the screenshot.

very close to cleaned up here...

row is .75 * X conversion on kflamkr

ok thank you, I finally correctly defined it and it makes sense to me now.  you must mod both to get knock based dynamic fueling.

I had to find tonys conversions

DLAMTANS (Air temperature-dependent enrichment)
            - 0x1C36B signed conversion X*0.007813
x (tans) - 0x1C367 4 columns conversion X*.75-48

dlamtans stays stock 0 all across.

Unless you want to offset lambda for IAT...

OK, great work.  Here's the map pack with the most recent torque maps, dynamic KR fueling, and nls/als + misc code-words discussed in recent months.  [obviously an assembly modified bin is required to have the nls/als]  [old news]

Updated wiki to reflect KR and LAMFA based fueling

http://s4wiki.com/wiki/Tuning#Open_loop_AFR

comments welcome!

Ok, thats retarded.

Using my basic algebra I skills,

1-(1-x) =  x

So isn't this equivalent to

(KFLAMKRL+DLAMTANS) * KFLAMKR?

[edited to fix stupid algebra error :)]

Given ...
KFLAMKRL = 11.7
DLAMTANS = 0
KFLAMKR   = 1

1 - (1- ((11.7 + 0) * 1))

1 - (1 - 11.7)

1 -  (-10.7)

11.7

that makes no sense :( KFLAMKRL is in delta lambda not delta AFR

Ok... plug in .85

1 - (( 1 - ( .85 + 0 )) * 1)

1 - ( .15 )

.85

Adding DLAMTANS makes it more clear

1 - (( 1 - ( .85 + -.03 )) * 1 )

1 - (( 1 - .82 ) * 1 )

1 - ( .18 * 1 )

1 - ( .18 )

.82

Edit : The correct formula is 1 - (( 1 - (KFLAMKRL + DLAMTANS)) * KFLAMKR), so if you choose to offset for IAT then DLAMTANS needs to be negative.

Oh, i'm stupid

1-(1-x) is x lol.

LAMFAWKR, did anyone else find this variable funny?

Inevitable happened today. After getting a tank of 93 octane fuel I proceed to floor it on the highway and all of the sudden I dip to 10.3:1 AFR during all out WOT... that's with meth squirting...

On a normal car it wouldn't be anything alarming unless of course this would be a result of bad misfires, but on my car it is indicative of severe KR fueling intervention. I quickly logged the car and I clock -8.5 corrections which is what I would normally get if I run out of meth on 93, but meth is squirting as verified by running pump on manual and the fact that the level dropped during next run.

This only means that either I dozed off and pumped 87 octane or something, not likely, or the assholes at gas station are cheating badly on fuel.

Conclusion is that if I had fixed BTS fueling I would had much heavier corrections at a target AFR with possibility of maxxing them out altogether and pinging he engine..

Can you clarify the above statement? I don't understand what you mean by "fixed" BTS.

Scary shit though...

KR enrichens more and more the higher correction factors are used.
BTS is effectively fixed in that respect. You'll run the same AFR regardless of knock.

Personally, I don't enrich via KFLAMKRL beyond my zero row until ~-8 because of DZWWL's influence. On a typical pull, DZWWL will offset dzlamfaw by -1.5 to -3.


Only true if you have disabled LAMBTSZW via DLBTS and KFFDLBTS.

I thought dzwwl typically offets dzlamfaw the OTHER direction (hence setting CWLAMFAW bit 0 to 0)

If load is greater than ~60 and IAT is greater than ~39* c, DZWWL will be negative.

http://nefariousmotorsports.com/forum/index.php?topic=141.msg15921#msg15921

Any suggestions for wording describing that for the s4wiki?

Though BTS' timing corrections would have been more heavy handed with degrees pulled, corrections via pulling timing in general are "safer" (reduce knock more quickly) than AFR corrections, no? So, assuming that you didn't hit the CF limit, BTS corrections in this same case would have been more conservative, right?

everything depends on where the TABGBTS value is set.  if its set high enough that timing and and fuel intervention are occuring at the same time, the answer isn't quite as clear.  as we recall, the knowledge from this thread was that TABGBTS needs to be set at a sufficiently high model temp as to not intervene in normal fueling based on knock.  therefore we'd see the following progression:  normal [0 axis row on KFLAMKRL table]-->  cf-based fueling [negative valued rows on KFLAMKRL table]--> omfg help mode: reduce immediate timing, add to stored memory of knock events, dump fuel to cool down. [KFLBTS]

everything is in delicate balance and has to be done correctly.  has anyone experimented further with the TABGBTS value?  I currently run 900 with no problems.  if the car isn't warm or rlsol gets out of control, the fueling and timing controls just shut the game down immediately.  its perfect.  if you were lucky enough to have logged, you can see where and when the fueling / timing were off, and make adjustments to your [KFLF] or [FKKVS] or [MLHFM] or [KFZW] or [KFLDRL] map, depending on what you believe caused the over/under abundance of timing/boost/fuel w/e your log shows.

is this clear enough for the wiki?

now if we could only figure out the torque model epsilon bounds.
say, has anyone ever seen that site from a few years ago where some team of engineers made an exact model using Excel of the 2.7tt engine?  throw me a bone anyone please?

Thanks for the response.  Looks clear enough for the wiki to me (though maybe I understood it because of the weeks and weeks of reading and experimenting I have done ha.)However, my reply was to the hypothetical I quoted ("if I had fixed BTS fueling"), as if there was no KR based fueling (so, a different, lower TAGBTS).

No idea what you're talking about with the excel sheet btw.

You shouldn't be using t he BTS function on a modified car. You have no way of correctly modelling the EGT

Rick

Sounds like a good excuse to use it for main fueling then.  ;D

hahahah, this made me crack up.  elrey, any chance you could upload your KFLBTS screenshot/table?

I don't claim to be a tuner. Just a hobbyist just playing around with my own car. (the car btw -> http://forums.vwvortex.com/showthread.php?4260387 (http://forums.vwvortex.com/showthread.php?4260387)

(http://creativeion.com/rey/vw/help/bts_main_fuel.gif)
(http://creativeion.com/rey/vw/help/bts_main_fuel_text_afr.gif)
(http://creativeion.com/rey/vw/help/bts_main_fuel_text_lam.gif)

no way dude, don't be bashful, that post was hellllla sick

wait what are we talking about now???

i currently us Lamfa, bts, krl in conjunction.  why not use all when we can?

This

I can't get EGT beyond 930°C even on long 4th gear WOT runs. Never had any problems and not seen any LAMBTS interventions in ME7L logs.


Holy crap! I'd love to see that. Nye would probably puke at the sight of anything done in Excel but I'd get a boner! ;D

TTQS

oh my god the horror :(

lol!

Is this what you are looking for?

yes...  **** YES

All fueling maps of this combination on the same post [screenshot for posterity]?

Holy cow, that took someone a lot of time/effort.  Would be interesting to potentially add in the current options (different Garrett's, Tials, ER IC's).

Use LAMFA for desired fueling and use KFLBTS as a 'net'.
KFLBTS is a savior when you are running BT's.

KFLBTS = component protection, and that's how you should use it.
Some tuners disable it for stock turbo tunes, but I wouldn't. It only comes on when EGT's go over certain threshold so there's no need to disable it. You should leave it on as a safety feature.

Indeed. A very interesting piece of work. I actually thought it was modeling an ME7 ECU, i.e. someone had built all the key maps, characteristics and constants and then was feeding them with the various inputs required to produce output curves for torque, etc. That would be something, i.e. a desktop model of a Motronic variant.

TTQS

Of course, hadn't been on my laptop...

This strategy is for 91 oct, keep in mind this is on a car with a vertical FMIC, no fans, at 6000 feet ambient and often being driven/tested very hard at 7500 plus feet (about 10,200 max) and 7500 rpm at 22-29 psi.  My biggest issue up here is the deformation of boost hoses at high AITs for long duration after heat soaking the car while sitting, i consider this fueling conservative.  For race gas you can run way less fuel, with meth injection you don't need to think about afrs ever really in regards to the tune, just hoses prey meth nozzle.  With nitrous you don't need to worry about afrs just fuel.  This is a daily driver who knows what I might get for fuel and no frills or power adders/helps sort of system that works extremely well.  With even something like c16 this would still be a monster file as you wouldn't see knock.  i have tested this with q16 and e85 but run out of fuel on the corn, going to re-vist e85 tuning this summer when its easier to buy.  If i ran meth injection I would basically always run a race style strategy.
____________________________________________________________________________

I try and dump a little fuel on hammer down with the lamfa, nothing much, we are talking race gas short run afrs here just to start the process of cooling the charge before boost starts ramping the line pressures.  On my BT car if I punch it bellow boost threshold it does indeed just dump useless fuel but not enough to stop building tq/boost.  just punishes me a little for driving lazy.  Above boost threshold its dumping it down to optimal tq afr before krl or bts can have a say as it is able to jump immediately back into boost.

On boost krl is being used with tonys kr map, it is pretty broad and works well with basically any setup since load is load.  I have krl running high 11s in the 0 row for no knock and this has been fantastic, this is the theoretical peak power afr for a 2.7t under boost.  I quickly drop through the range and settle at 8 cfs to 11.1 afr which is where the flame front and tq are all but dropping away and this stops detonation.  Since setting this up my car has never logged more than 8-9 cf and only for a short duration, it always recovers very quickly and gets out of det and just rides the line pulling hard and clean with minimal knock that cannot be avoided with 91 but settling in around 3-4 cfs and a nice powerful afr.

Then for when I just cant seem to run out of road which is sort of rare or i am abusing the car with brake boosting and the like I have BTS coming on late (assuming my/your maf stuff and calc ect/load is right, if it is scaled low you will not have the safety net at all especially with no real egts, too high and it defeats the purpose and robs power) to cool it all down, sort of like the egt trigger.  I have no cats and high end components/turbo/manifold so I let it get hot.  It dumps the afr below the usable flame speed range and just wastes fuel for the sole purpose of shutting down power without literally shutting down the engine like with other interventions like throttle cut.  I max my normal fuel system around 7.5:1 afr so there is decent head room here for me.

whew... long but hopefully helpful, bold and italics are meant to be helpful for points to focus on and not to seem pretentious.  ;D  Adapting any of these or all of them to another car is really easy, just base it all off your boost profile, hot side components like cats and your fuel / fuel system.

here ya go:

Love the picture name ha.  So, after this screenshot, did you then convert all of those values to lambda for the ECU?

nope, its all in the conversion factor you use.  i prefer to visualize afr numbers in my head and not lambda because when i think lambda i think volts.

hint- look at the different bts maps in the common xdf, one is afr one if lamda, same parameter, different way to display it, the conversion factors to display each apply to other fuel related maps.  if you dont like trying to tune lambda numbers just tune with afr by editing your xdf. ;)

NOOB ?  What did you do to the XDF to get it to convert to AFR instead of Lambda?

Yeah, I'm retarded and should've caught on that you just changed the xdf multiplier.  Cool idea that I might follow, cause, like you, .81 and whatnot is nowhere near as intuitive for me as AFR numbers.  I've just been trying to force myself to make lamda second nature ha.

Just right click the parameter inside of TunerPro and click edit XDF parameter.  On the last tab IIRC is where you can edit the conversion factors for what all of the data shows. Just add a *14.7 at the end.

in general, for fuel maps that display Lambda values a conversion of 0.007813 * X will be used, by changing it to 0.114844 * X it will display AFR

thanks!

I too am retarded, err... handicapped. I've been thinking of doing this for a while, but since everybody talks about lambda, I was trying to get used to it. Man, that makes life so much easier. This whole time I've been converting it in my head. ::)

instead of for example "0.007813" use "1/128" in tuner pro. It will give more accurate value without any rounding.

There are other values used in XDFs that are approximations, you can easily tell when you divide "1" by that value and get something very close to one of 2^x numbers. For exmaple, 1/0.007813 = 127.9918085242544. It is obvious that they are really using 2^7 divider here (easy on ECU, doesn't have to waste time doing complex calculations).

You'll find quite a few of these in use. 1/512, 1/32768 etc.

Also make sure the tables display values with as much precision as you can fit in a cell.

Why this is important? TunerPro will round up/down for you when you copy paste stuff without you knowing if you don't have enough precision forced on the table.

Had this happen to me on numerous occasions.

True, the rounding thing especially on maps that are all around 1 or less with like 5 sig figs. If you copy/paste not in hex display mode, it's likely more than half of the table got rounded to the wrong value.

Ok, run the full tank of crap fuel down to vapors, fueled with quality gas this time and my engine is back to tip-top shape. To recap:

Got a tank of "93" that was anything but:
- heavy CFs in -9.0 range with KR fueling pumping 10.3 AFR out
- large +4 +5% corrections to fueling  - makes me think that there was something in the gas that had much lower stoich than gas but not octane benefit?

Re-fueled with legit "93" and:
- CFs hitting -4.5 max with fueling riding at 11.6
- LTFTs back to -+0.5% max across all trims.

Lesson: You never know what you're going to get in your gas. I got something really, really bad. Since my CFs were so bad at 10.3AFR + Meth injection on, it makes me think that traditional fueling would run into serious problems without additional KR fueling kicking in. Imagine the same situation with car tuned to 11.6 flat, it would no doubt hit -12 CFs.

It seems to me the lamfa camp is saying use lamfa because you can have LAMKR fueling.
Why can't you have KR fuel when using BTS fueling? LAMFA = 1, and LAMKR < 1.

The root reason I created this thread was why fuel based on driver requested vs actual load.

Here's the same question from a different direction:

Current load input in LAMFA is mrfa_w (driver desired load). Would it be better if we changed that to rl_w (actual load) [and axis values to reflect >100]?

That way we can use BTS for what it is meant for. And for big turbo cars, we don't have to dump fuel in before car needs it.

Great idea; it doesn't seem that it would be that difficult to change.

Not sure if there would be other side effects though.

I don't really want to re-tune my car just to point something out but I vaguely remember that my Lambda was not following driver's desired load when I had LAMFA table in use on my tune, I think it was followinf actual load...

It wouldn't be the first time FR was wrong about things.

I don't really remember as I was really testing BTS at that time. I had LAMFA set to lambda lower than 1 at very conservative 80 load and I wasn't seeing that when pedal was floored in low RPMs and desired load was definitely over 80. Only when engine started actually getting loaded then I started seeing Lambda falling down.

But I might be wrong. Please experiment and see when LAMFA is actually kicking in.

Is the LAMFA delay set to zero for all platforms, or just turbocharged?
TLAFA=delay time [in seconds] for activation of lambda by driver.

where's this even located on the mbox?

I saw it in the FR and it is in my 551R (BEL) @ 0x1930F

I have confirmed mrfa input into LAMFA both thru disassembly and testing with low TALFA (032HS/032LP/518AF boxes). It's hard to see the direct correlation between driver desire->lamfa->actual afr with a small frame turbo + TALFA + lowpassfilter at the end of LAMFAW. With the quick onset of actual load with a small turbo, it's hard to tell the difference between actual and requested load. Throw in a slight delay by the means of TALFA and lowpassfilter, and it makes it even harder.

The question is still out there.... Is there an advantage to driver desire fueling vs actual load fueling? Why did the engineers decide to go this route?
I under stand for NA cars. But with turbo cars where load above 100 depends on spool time of turbo, I don't see the merit. Again, this may be only an issue with slow spooling turbos.

Sorry for using torque and load interchangeably when I shouldn't. But I think you get the gist.

I am not following what you all are trying to say here.

I have used LAMFA in conjuction with BTS for a while now and it works perfectly. I rescaled the mrfa_w axis to 50, 60, 70, 80, 90, and 100 and enrichment follows mrfa_w as it should. I recently implemented LAMFKR in addition to LAMFA and BTS, but I haven't gotten the chance to log yet.

The point of implementing LAMFKR for me was to include actual load in target AFR before BTS activation. This way I can target a leaner AFR and enrich further based on condions.

Currently, I'm enriching slightly via LAMFA on high torque request, further via LAMFKR once load catches up, when EGT threshold is exceeded via BTS, and finally for knock via LAMFKR and BTS. You can also offset lambda for extreme IAT's via DLAMTANS.

mrfa_w is torque request btw.

I'm not trying to say, I'm trying to ask: Is 'torque% request' based fueling better than actual load fueling?


Seems you are saying you use LAMFKR+LAMFA as your base fueling where as I bring up using BTS for base fueling. Seems you've done this in part because LAMFA by itself was not perfect for base fueling. This supports my concern that LAMFA alone is not perfect. We differ how we compensate for this I understand.

Why is LAMFA not perfect? I don't know how many more times I'll have to ask this question.

Another reason I like BTS over LAMFA and/or LAMKR: map resolution.

LAMFA and LMAKR are 8bit maps with only 6 load/torque axis nodes. Look at BTS. yummy. I'm considering not only changing input for LAMFA from mrfa to rl, but also changing/relocating map itself to mirror BTS map structure and hex lookup sequence. In other word replace LAMFA lookup code with a copy of BTS lookup code.

phila_dot, what turbo are you running? Stock? Why do yu feel you need fueling BEFORE actual load? Why does a car need fueling < 1 before any significant actual load? This is where my tuning knowledge lacks a lot. Does a turbo engine produce more torque @ 0psi with lambda < 1 than with lambda = 1? I have a feeling it does which explains my obvious confusion.

bah. if you want BTS-like fueling, just do BTS fueling :P

(http://nyet.org/cars/logs/typical_20120412_124024-bts-only.png)


on 91 oct, pre-emptive fueling helps A LOT. by the time KR correction kicks in, its too late.

anybody on 91/92 octane needs to run stock timing during fuel and maf calibration phases as a strict consequence of this.
this has been my experience in oregon even with low IAT's [due to cool wet conditions].

LAMFA is extremely limited. At WOT mrfa_w = 100 almost instantly, so you are only really using the last column.

I only use LAMFA for a slight enrichment to prevent knock and KR on initial acceleration and it makes a big difference.

Stock turbo here.

Just a reminder since some might have missed a subtle point I made in my post about KR fueling.

The reason why KR fueling is superior to LAMFA junk is that you can re-define KFLAMKRL table so that first row is for "0.00" knock. When you do that, the LAMBDA will be calculated for normal operating condition without knock.

Since lowest LAMBDA prevails, KR fueling then becomes your fueling path.

Many are belly aching about LAMFA being in-appropriate in that it uses driver's indicated load instead of actual engine load, some want to alter assembly code and generally look for stuff they can easily get by making that slight alteration to KFLAMKRL table!

KFLAMKRL uses real load. Just stick your desired AFR/Lambda into "0.00" knock row/your load threshold column and voila. With "0.00" row there is no "by the time KR correction kicks in, its too late" situation since it is real time (like BTS for a given EGT temp) and instantaneous fueling.

You then use rest of table to react to knock/CFs. I still use BTS for temp over 900c to seriously douse the engine even if knock is not large enough for KR to already accomplish that by then.

There is also ATR system which acts on physical EGT sensors readouts, as a last resort.

This still doesn't address 1 thing that 'some' say they want -> a high resolution map. not only in axis nodes but also in value increments. 16bit lambda value allows for smaller increments in target lambda values than 8bit lambda values.


And I believe I caught your point if you read my response.


I not saying one way is better than another. Through this discussion I hope pros and cons for both methods are fully brought to light.

I think we all understand LAMKR. I believe elray's point was about map resolution and nyet was referring to actual knock regulation dwkrz etc.

Why set BTS so high basically duplicating ATR?

I want to BTS to kick in just before ATR to hopefully prevent ATR from engaging. ATR kicks in at 950c physical. I went through great pains to ensure that my fueling and MAF scaling is as close to real value (not underscaled) and actually logged BTS vs ATR while torturing my engine. In my tune, there was only 10c difference when temps entered ATR reaction zone.

Otherwise I don't want the BTS interfering with anything.

I feel like we are all talking and working in circles here...

Julex and I are obviously on the same page.

I feel like my fuel strategy post got over looked by a few because if they would have read it and grasp the concepts involved the last page or so wouldn't have happened.

Not to tooth my own horn since its all based off what I learned here other than my standard knowledge of VE, AFR and boosted engines in general but I just gave you guys a bitchin way to use the capabilities within our ecus, go freaking try it.   ;)

Remember our systems follow the lowest AFR request being imputed by a number of different maps, you need to picture it all in 3d / realtime. Resolution is not something to get caught up on.

Would you be happy if your timing map had same resolution as your LAMKR map?

You need to log it in process and see the resolution that is added to the maps as they work together.  Think of it as a sum of all parts.  You get the resolution from our sophisticated, redundant inputs and outputs.

Tune all the maps to compliment each other.  my strategy was cooked up in my head, flashed, driven 2 or 3 different occasions to find holes, fixed those holes and even in a non fine tuned form it is flawlessly smooth in all aspects.

So basically.. to sum things up.. (in my head, after reading countless of pages..)

i can use KFLAMKRL as "main" fueling path.. at column "0 degrees", and this map is lambda value, with actual engine load% as the other axis?(this axis wont go over 100%, right?)

..then i add more fuel at higher "degree" columns if knock activity raises and more timing is pulled..

i can then use LAMFA, which is rpm and requested torque based, to add preemptive fuel at spots where i know the engine is prone to detonation.. ie att the tq peak.. leaving the rest of the map at lambda 1 (for the KFLAMKRL to override as primary).

i then have BTS kick in at high calculated EGT(850-900ish) to cool things down if pushed too hard, i.e long pulls at the track.

ATR is actual EGT-sensors and regarding those maps?


have i understood things correctly? or are there more maps i need to fiddle with regarding the KR based fueling?

i have been following this interesting thred for quite some time now, thumbs up for all the time spent looking into this, keep up the good work guys  :)

correct, precisely said:

KFLAMKR/L - new main fueling map governed my 0 knock row...

LAMFA - slow-responding afr-driver's request, nice to have targets for pre-fueling effect

BTS - TABGBTS is model temp toggle switch between LAMFA and KFLBTS for component protection, set to 850/900/950 as fueling safety

ATR - actual EGT, goverened by TABGSS / TABGSS2, set to 1100 to turn off + turn off egt dtc's

rl_w will exceed 100.
mrfa_w in LAMFA will not exceed 100%.

Yes, just remember that this axis is not considering only knock regulation. It is also includes dzwwl which will offset wkrma a few degrees.


Personally, I have tabgbts set to 650 and plan to adjust it accordingly from logs.


KFLAMKR - multiplier for lambda in KFLMAKRL
KFLAMKRL - target lambda values
DLAMTANS (optional) - offset lambda for IAT
CWLAMFAW - clear bit 0 to disallow positve offset from DZWWL

My CWLAMFAW is 36 in decimal, if I put 36 in calc and hit binary, the first number(bit?) from right is 0.

Does this mean my CWLAMFAW bit is set to 0?(as we want it to be for using KR fueling?)

ok, thank you for clarifying, and this is actual load?
why im asking is my axis in a me7.5 032HN box looks like this:

20.25
39.75
60.00
69.75
80.25
90.00

which is totally useless then for this KR-based fueling method..
and you would think this would go beyond 100 even in the stock tune.. yet it doesnt..
is there a reason why it looks like this? which other relevant MAPS share this axis? (if i am to modify it..)


DLAMTANS, can this one be tuned to i.e add extra fuel at IATs higher then +50c? (originally it seem to be configured for extreme cold conditions)

How did you change the column header on the DLAMTANS?

Column units

I guess I asked the wrong question.  Mine reads 8.25, -48., -48, 50.25.   How do you change those values?

Either axis address is bad or an option called "Step" in the table definition is set to default -4 or whatever tunerpro likes to do. my TunerPro likes to reset these on some of my maps for no reason resulting in weird looking axes.

The address step for DLAMTANS axis should be 1 as it is 8 bit.

Address step is 1 for 8 bit values and 2 for 16 bit values. If you set it to 0 it will revert to -4 and not display correctly.

THank you!  Its fixed now.

Here's what I had to do for future reference:
 I had to change the label source to "internal pure".  This allowed to to edit the address step.  I then changed the address step to 1 in both rows and columns.  it was at -4.

what are the experiences using LAMFA as WOT fuel-enrichment. can it accelerate building boost in low rpms?

Generally, you are trying to use AFR to control knock, not change spool characteristics.

What problem are you looking to solve?

I want earlier spool of course ;) and I think Lambda <1 will help before rl is reaching values >100.

yes, but you will have to pull a lot of timing to get decent results... and you may lose some torque in the process...

in any case, the short answer is yes: you can absolutely use LAMFA to get very early enrichment, far more selectively (e.g. based on pedal position) than KR or BTS fueling.

at the AFRs i'm running (10.8-11.4) it is unlikely that additional BTS fueling is going to save anything :)

is there a way to alter timing during that enrichment? based on pedal and not on rl?

do I find some logs in the forum where someone made some spooling tests with lambda and late ignition?

Wanted to add a little bit to the thread...

1. Why set KFLAMKRL first axis value to 0 instead of -2.25? It is my understanding, that due to the way maps are looked up, it will always read the first row anyway, when the retard is -2.25 or less. I don't think setting it to 0 is in any way a pre-req for enrichment happening. At least this is the way every Motronic ECU I've worked on has worked so far. Also, you want to constantly run around -1.5 retard anyway, so that you are getting maximum performance at all times.

2. Setting TABGBTS and TABGSS really close does not make sense to me. You don't want to run 900+C EGT's if you can help it...
I find that there is not much difference in performance between about 12.2 AFR and 11.3 AFR, if the timing is advanced properly. The EGT's are smaller with higher enrichment though.
I think the 750C for TABGBTS set in the RS4 is exactly right. At that point you want to move fueling to the richer side of things, but without severely hurting performance.
The limit set in TABGSS, is the "oh shit" limit, where you want to dump fuel and protect the engine components from destruction...
FBSTABGM can be used to progressively enrich the mixture towards the "oh shit" point.

3. It is a pretty good idea to use LAMFA as WOT fuel enrichment, but not at low RPM's, otherwise you'll hurt economy quite badly.

Obviously there is no "right way" to do things, and opinions are just opinions, but I thought I'd just throw my thoughts into the mix...

Btw, those that use KFLAMKRL, what do you guys do with KFDLBTS?
These basically duplicate each other.

I cant control WOT Fuel. Can someone tell me if I am doing something wrong. I've attached a screen shot of the tables edited & a log.

Set KFLAMKR to 1.00

The whole map? Its set to 1 on high load & rpm. I used Tonys values

nvm

Julex can you please help me understand this? Im confused.

Does the axis on KFLAMKR need to be changed too? Or is it just KFLAMKRL?

Some notes regarding FBSTABGM.

My KFLBTS is basically flat RPM wise.
Meaning I just select a lambda based on load.
And that lambda matches what my KFLAMKRL table sees.

Now I want to use FBSTABGM for mixture enrichment, instead of mapping it manually via RPM.

As I understand it, the way it is calculated is:
Lambda = ((KFLBTS - 1) + LAMBTSZW)*FBSTABGM + 1

So this means that FBSTABGM is not exactly a multiplier for KFLBTS alone, but until LAMBTSZW kicks in, it is technically a multiplier for (KFLBTS-1).
So let's say if you wanted a 0.8 lambda to start with, and then you would like it to be 0.75 at 900 rpm, then to calculate FBSTABGM, you have to do like this:

(0.8-1) = (0.75-1)*FBSTABGM
-0.2 = -0.25*FBSTABGM
FBSTABGM = 1.25

So this is pretty far from simply a percentage, as rather high values are required to make a difference.
I will log this tomorrow and confirm...

Quick question as I read through this 20 times already.    On the kflamKR table does it matter which axis has rpm?  Mine is backwards as compared to all the screenshots I have seen.  I have rpm on the y instead of x.  I have input the values in there coresponding cells of x and y location.  Just wondering if the axis being reversed matters.

I found a very good example how KFLBTS and LAMFA should be used - it's BFV engine (Audi TT Quattro 240PS). I like those rich best torque values at WOT. The way they configured looks better than in BAM engine.

Hi

I try to use KFLAMKR and KFLMAKRL based fueling on my 4B0906018CG ecu but during road test i am guite sure that those maps are located wrong on .ols which i am using.

Can somebody please check data and axis locations for those values?

How do you go about changing the axis?

http://s4wiki.com/wiki/Tuning#LAMFAW
http://nefariousmotorsports.com/forum/index.php/topic,141.msg9068.html#msg9068

Awesome, spent ages last night reading, that link has shed some light on the matter, thanks  ;D

hi
I dont understand problem with LAMFA axis , I had read this topic and Wiki 1.8 T tuning :/
ori file in attache
x axis is 1D8E6 factor 0.003052 16 bit LoHi 
and I have got on axis  85.01 87.51 90.01 92.51 95.01 97.51
but in Wiki is written :
" the stock LAMFA load axis is (incorrectly) restricted to 0.5%-1.0%"

That's the S4 wiki :O

One of the few things that only applies to the 2.7t.

fixed, hopefully.

Now I have got it ;)

I'm trying to understand how does BTS work, but a little confused by 26 pages of the thread  :P

lambts = KFLBTS + ([KF]DLBTS * KFFDLBTS)

For example LAMKR is disabled, LAMFA = 1, retardation is 0 CF
I attached BTS maps.

So here are my calculations (rl = 138 on 6000 RPM)?

lambts = 0.9219 + (0 * 0.8672) =  0.9219

for retardation 12 CF:
lambts = 0.9219 + (-0.2813 * 0.8672) = 0.9219 + (-0.2439) = 0.6779

Am I right or totally wrong? I think I'm wrong because it doesnt work for 190 load. Please throw me a bone.

The input to KFDLBTS is detazwbs, not CF.

This, it's ignition angle efficiency.

You can have no timing retard and poor ignition angle efficiency.

Thanks for reply, I'm not sure I fully understand how detazwbs works, but looks like I got it.

So the difference between optimal and actual ignition angle converted to percents(ETAZWG and ETAZWIST) via ETADZW map?

mean etazwist = etazwim

After that:

"The difference between etazwg(Efficiency at basic ignition angle) and etazwim(Mean efficiency at actual ignition angle)
gives the deterioration in the efficiency detazwbs. Depending on detazwbs, an additive
enrichment can now be performed by means of the characteristic DLBTS."

Right?

And I was wrong only with CF?

Yep. Sounds about right to me.

Thanks for your confirmation! That's a theory, but what values does detazwbs usually contain? Is it possible to log it?

And please tell me is my calculation of AFR right?
For example if KFDLBTS = -0.2813

lambts = 0.9219 + (-0.2813 * 0.8672) = 0.9219 + (-0.2439) = 0.6779

I'm confused because on high RPM and load, AFR should be 0.15-0.30 according to my calculation  :) and it can't be.

Did you bother to check your ME7L ecu config file yet?



have you logged lambts yet?

It's the difference between desired ignition angle efficiency (from zwgru) and actual ignition angle efficiency (from zwist).

It will vary depending on coolant temp, KR, IAT...

I typically see < 3% in logs.

You are looking at worst case scenario numbers.

Thank you guys!
I was too tired to understand I just need to check detazwbs into ecu file.

detazwbs was found by ME7L
detazwbs        , {}                                , 0x3848D8,  1,  0x0000, {%}       , 0, 0,          0.5,      0, {Delta ZW-Wirkungsgrad fr Bauteileschutz}


I havent logged lambts actually, because EGT sensors are dead and disabled. I'm going to resolder contacts and activate the sensors, after I assemble the engine  :D
Thats why firstly I would like to understand how it works. But I think its clear for me now.

lambts has nothing to do with actual EGT's or the EGT sensors; it uses an 'estimated' EGT value at the O2 sensor.

Hello guys. I study the fueling in ME7.5 and I have some questions. In the 180hp stock file the fuel is controlled with lamfa and when the tabgbts>400C with kflbts (am I right?). I've downloaded an OLS from a 225hp bam file and lamfa is the same with 180hp file but the kflbts is deactivated (all 1) and the tabgbts is 820C. How the 225hp controls the fuel?

Read ATM ;)

What's ATM?

ATM: "33.50 Abgastemperaturmodell"

Thanks a lot for that mate I read the ATM and from my understanting for 225hp engines I tune lamfa and if I want additional enrichment I enable the bts. Am I right?

BAM (225bhp) would use lamfa until the threshold TABGBTS is crossed.  Then it would use BTS fuelling. 0.97/0.96 fuelling.

Sure its a combination of multiple maps too when on enrichment via BTS.

Yes you're right. When BTS enable, Lambdabts = KFLBTS + (KFDLBTS * KFFDLBTS).

Thank you. Now I need to understand the torque model :-)

Isnt it simpler to just fuel with BTS as its a much larger table so you can have a more defined control over fueling, i use BTS and it works great, i cant see the point in reworking the lamfa axis when you can just leave it as is and use bts...each to there own though

And I assume you've taken KFFDLBTS into consideration?

KFFDLBTS all = 1 (deactivated)
LAMFA all = 1 (deactivated)

Lamfa = 1  Deactivated ?

... NO !

My bad thats wrong as 1 would mean 14.7

Seriously you confuse things .. Please read more.

KFFDLBTS is a factor , LAMFA is a value

Yes. KFFDLBTS is a factor for BTS.

I guess KFFDLBTS = 0 diactivated. But KFLBTS is still worked.
LAMFA = 0 diactivated  :)

LAMFA = 1 deactivated ...

KFFDLBTS is a factor for DELTA lambda for ignition angle efficiency. A zero factor gives a zero offset, so no affect on KFLBTS.

LAMFA is a lambda request, so lambda 1 would be no request essentially, but lambda 0 is not what you want.

I'm just kidding)
But seriously if LAMFA = 0, AFR will be 0 or it has limit that protects from very rich or lean AFR?

I'm asking cause I've seen a lot of tuned files where BTS is unbelievable rich, but I guess fuel pump(injectors etc) cant provide so much fuel? ME7.5 has wideband O2, so I know real AFR and its leaner than requested AFR.

There are a few rich and lean maps.   See %LAMKO in the FR.

Hello,

I´m having some issues to get the enritchment on my 1.8t wideband ME7.5 to work properly in the lower gears. In third, fourth and fifth the target lambda is what I request in KFLBTS. But when pressing the pedal in second gear the target lambda never reaches what I have in KFLBTS.

Previously I was using LAMFA more, with 500 degrees TABGBTS, but this resulted in knocking and a melted exhaust valve when accelerating in second gear. I have understood that there is a function slowing down how fast LAMFA is allowed to change target lambda so I assume this was the problem.

Now TABGBTS is 100 degrees, but still when pressing pedal in second gear I never reach my requested 0.83 lambda. Attached is a log over acceleration in second gear and my KFLBTS. KFFDLBTS is set to 0 but KFDLBTS still has some values in it since it is stock, not sure if that affects anything? As soon as I hit over 190 in load I would like to have the requested lambda, not like now when its a loooong delay.

Any suggestions?

Sorry, forgot the log...

Which model is your car? Did you change FBSTABGM?

Hello, the car is a A4 2003, B6 model. Regarding FBSTABGM I have to check that, not sure at the moment. But there seems to be some timedelay on KFLBTS also?

The delay is FBSTABGM. It disables KFLBTS until 850C (or thereabouts, I am not looking at your file)

There is also a factor flbts_w which influences enrichment. It has initial value 0 and then raises to 1 with delay TVLBTS and a speed constant ZLBTS. See LAMBTSENABLE section in FR. It's similar to how LAMFA is delayed by TLAFA and raised by ZKLAMFAW. Additionally, if you have KFFDLBTS enabled i would also look at dlambts_w and its speed constant ZDLBTS (section LAMBTSZW).

Hello,

This seems to have solved the issue, I put all 1 in the FBSTABGM and now I get quite close to requested labda also in "fast" transients. Should be more safe for the engine now and maybe it will even stay in one piece. t was disabled up to 850 deg, reading the FR better would in hindsight have been well spent minutes.

BR. Kenneth

Anyone have the address for LAMFA in C box thought i had it but all the numbers are completly wrong, want to try with LAMFA and see how it compares to BTS

SW:350093
1B8D0
Rescale %PED axis if you want LAMFA to be active.

Why are you using C box?

Beacuse i have C box on my S4 and want to use that, i have a D box that i was going to flash a M box .bin to but having issues with that but id rather put the effort in and use the C box,

If you can't find maps yourself, you are better off using M-box...

You're not saving any time/effort staying on C box.

Great thread.. Been reading 2 times now to understand.

What about E85?

This seems to only implies for pump gas ( i.e. 91 -93) and not E85 since it doesnt knock the same way. As i understand it fueling via BTS is the simplest way to go i running BT + E85 setup.
There will be no engine protection though.. but thats life when you running a very modifyed car isnt it?

 ??? :o

I use both for E85.

How doer KR fueling handle that? E85 Doesnt knock as Gas?

Are you asking if the KR mechanism detects E85 knock correctly?

Well nyet if its possible to detect knock on E85 and there is a mechanism for that it would be greate to learn more about. :D  I am between two options then.. On one hand it seems more simpler to go with BTS fueling for my project. On the other hand it seems more "Correct and optimal" to go with the factory type of tuning for fuel..  Concerning being more safe with BTS as a "safety net"  I have my own built external kind of safety system. Im running an arduino based boost controller with WBO, EGT, IAT that would cut boost and warn me if temps go up. What path would you go nyet?..

Not sure what you're asking here :(

The first column in KFLAMKRL will be used when wkrma <= the axis value ( absence of KR). Six load datapoints coupled with 6x6 KFLAMKR is effective.

Assuming I understand what you're saying...

As i understand it
KFLAMKRL (fuel@knock) = Enrichment during ignition angle retardation. Retardation occurs when knock.. E85 (not the same knock caracteristics as pump gas) = U dont get enrichment = Problem

Reread his post dude.

"The first column in KFLAMKRL will be used when wkrma <= the axis value (absence of KR). Six load datapoints coupled with 6x6 KFLAMKR is effective."

Hmmm im looking into KFLAMKRL and the first column nr 1 = 0.00..  Ok so that can give an load based enrichment?

is 0<=0? :P

IF 0 <= 0 = TRUE  ...Wich Means when Average value of the individual cylinder ignition angle retardation:  "wkrma" <=0: KFLAMKR give enrichment via first column.. But thats just 6 points?

KFLAMKR and KFLAMKRL are different maps.

sorry ment KFLAMKRL

6 load point in KFLAMKRL weighted by 6x6 load/rpm KFLAMKR.

Just pointing out the options, there's alot of different ways to combine all of these maps to get the behavior you want. It's up to you to choose how to use them.

Thanks for sort that out...
I think I will go down with KFLBTS path and measure with my external EGT sensor. Or use enough LAMFA to drain my fuel economy :)

Is the 6x6 not sufficient for your needs?

I don think I understand that correct.. I thought it was only the first column in that map that gave me the fueling.

I have been running on E85 for a couple of years now the whole year around.
E85 almoust never knock and if it does it is mostly unfinished combustion or going too rich.
It never triggers EGTs either. I have never seen it over 800 deg C.
So you can leave BTS and MKR fueling as a safenet, tune only Lamfa and you will be good to go.

then it goes to the 2nd map, which is 6x6

Nice info and thanks for that Mocke!

Nyet.. by second map u mean KFLAMKR wich is 6x6? So that map can add extra fuel?  Sorry for being a bit slow..  ;D Bare with me :)

Please refer to the FR.

What are the inputs to KFLAMKRL?
What are the inputs to KFLAMKR?

dzwlamfaw, rl -> KFLAMKRL
nmot, rl -> KFLAMKR

:)

There's your answer.

 ;D ;D Thanks for guidance.. I guess i need to re-read whole thread once more and try it on my experiment car.. 

I think i understand how it works. "Think".. I post this just to see how much i have understood.

1. I looked into CWLAMFAW and its: 00110000. First bit = 0 (Default from factory)
2. I changed tha axis data.
3. Enterd some values into KFLAMKRL..
4. Edited KFLAMKR with "0" and left the rest "1.00".

now.. as in can understand the lowes lambda will be the boss.. KFLAMKRL will now act as a Load based 6x6 map above 40% load.

Can someone comfirm this.. 

you should edit your lamfa axis something like 50 60 70 80 90 95

you only want krl enrichment starting at 9.75 ignition retard?

also, KFLAMKRL and KFLAMKR shares the same load axis.

Thanks bro! i noticed ive forgot to change that axis..

Why did he set his CW to 48?

I could really do without these last 2+ pages or atleast have them transferred to n00b forum, they are OT and not even interessting since you will not see E85 knock until it's too late. Why do you think that e85 ignition tuning is done by looking at torque instead of knock.

Jim as said many times, you need to read more before asking.

Take a calculator and switch over to "programmer"  > select "Dec" > type 48 > select Bin.. There you have it.

Ok with me.. "Moderator! fire at will"..

Wideband it's useful.

Don't know if anyone already suggested it but there is one more alternative to already known fueling methods.
More info @ lamfaw-lamwl. I am currently succesfully using this method.

Basically set KFLAFWL to whatever enrichment offset (from 1) you want.

For example if lambda 1.0 -> 14.7 AFR then KFLAFWL @ some cell with value -0.1 would mean final lambda value of 0.9. Easy, right? Only catch is you have to ensure all the other LAMFAW variables (lamfaws_w, lamfawkr_w, lamrlmn_w) are set to 1.

Interesting. You have tested it and it works?

Yes. That is what I am using right now.

Please just stop.