Pages: 1 ... 21 22 [23] 24 25 ... 31
Author Topic: Opinions: using KFLBTS vs LAMFA for fuel all the time?  (Read 356546 times)
elRey
Hero Member
*****

Karma: +32/-1
Offline Offline

Posts: 565


« Reply #330 on: April 12, 2012, 08:39:28 AM »

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.

« Last Edit: April 12, 2012, 08:56:50 AM by elRey » Logged
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12235


WWW
« Reply #331 on: April 12, 2012, 09:28:08 AM »

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]?

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

Not sure if there would be other side effects though.
Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
julex
Hero Member
*****

Karma: +78/-4
Offline Offline

Posts: 923


« Reply #332 on: April 12, 2012, 10:00:02 AM »

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.
« Last Edit: April 12, 2012, 10:06:36 AM by julex » Logged
ta79pr
Full Member
***

Karma: +4/-0
Offline Offline

Posts: 103


« Reply #333 on: April 12, 2012, 10:04:40 AM »

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

02 TT tdi (BEW)
2005 allroad 2.7tM (BEL)
s5fourdoor
Hero Member
*****

Karma: +33/-3
Offline Offline

Posts: 617


« Reply #334 on: April 12, 2012, 10:16:05 AM »

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?
Logged
ta79pr
Full Member
***

Karma: +4/-0
Offline Offline

Posts: 103


« Reply #335 on: April 12, 2012, 10:17:47 AM »

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

02 TT tdi (BEW)
2005 allroad 2.7tM (BEL)
elRey
Hero Member
*****

Karma: +32/-1
Offline Offline

Posts: 565


« Reply #336 on: April 12, 2012, 10:41:19 AM »

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.


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.
« Last Edit: April 12, 2012, 10:50:23 AM by elRey » Logged
phila_dot
Hero Member
*****

Karma: +172/-11
Offline Offline

Posts: 1709


« Reply #337 on: April 12, 2012, 11:02:52 AM »

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.
Logged
elRey
Hero Member
*****

Karma: +32/-1
Offline Offline

Posts: 565


« Reply #338 on: April 12, 2012, 11:49:29 AM »

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

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

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.

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.
« Last Edit: April 12, 2012, 11:58:15 AM by elRey » Logged
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12235


WWW
« Reply #339 on: April 12, 2012, 01:52:14 PM »

IIn other word replace LAMFA lookup code with a copy of BTS lookup code.

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



Quote
phila_dot, what turbo are you running? Stock? Why do yu feel you need fueling BEFORE actual load?

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

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
s5fourdoor
Hero Member
*****

Karma: +33/-3
Offline Offline

Posts: 617


« Reply #340 on: April 12, 2012, 02:39:48 PM »

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].
Logged
phila_dot
Hero Member
*****

Karma: +172/-11
Offline Offline

Posts: 1709


« Reply #341 on: April 12, 2012, 02:43:42 PM »

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.
Logged
julex
Hero Member
*****

Karma: +78/-4
Offline Offline

Posts: 923


« Reply #342 on: April 13, 2012, 06:20:22 AM »

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.

Logged
elRey
Hero Member
*****

Karma: +32/-1
Offline Offline

Posts: 565


« Reply #343 on: April 13, 2012, 07:14:56 AM »

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.
« Last Edit: April 13, 2012, 07:21:43 AM by elRey » Logged
phila_dot
Hero Member
*****

Karma: +172/-11
Offline Offline

Posts: 1709


« Reply #344 on: April 13, 2012, 07:17:52 AM »

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.



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?
Logged
Pages: 1 ... 21 22 [23] 24 25 ... 31
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.028 seconds with 17 queries. (Pretty URLs adds 0.001s, 0q)