Target lambda is set to one via a constant if B_falsh, B_lamlash, B_lamlshv, B_lamka, B_lamkh, B_lamnswl, and B_lambts are clear. Basically, if target lambda doesn't need to be controlled for a specific purpose then the constant sets it to one. Changing this constant should not interfere with functional control of target lambda.

The constant first gets moved to lamdiag_w, then ultimately to lamsons_w, lamsbg_w, lamvoa_w, and lambas. It can be limited based on tmot via LAMLGMTM.

I still have not figured out what all of the repercussions of changing this constant are, but it appears that lean target lambda will force open loop. It also looks like it may disable ATR unless LATRO is raised.

I was able to define it in my XDF and change the constant to 1.1. ME7Check reported checksums were corrected and comparing to the original revealed checksum changes.

I have defined for M box as follows:
0x3BFB2
16 bit LoHi
X*0.000244141

This is completely untested at this point, so attempt this at your own risk.

Functions that reference lamsons_w:
DLSH
DLSAHK
DLSV
BGMSZS
LRAEB
TEBEB
LREB
LRKA

Functions that reference lamsbg_w:
GK
Also lamsbg_w is used for axis SLX06TMUW.

Function that references lamvoa_w
ATR

Functions that reference lambas:
MDBAS
ZWGRU

The information I posted was derived from the B5 S4 M box narrowband ECU.

Your input is appreciated though, I'm glad to see someone else has done this.

I think that the only difference may be that the wideband ECU can still operate in closed loop, but I believe that this will force open loop on the narrowband ECU. That may be a good thing though as the narrowband sensors cannot accurately represent these lambda values and calculated fuel mass is usually very accurate as long as injector calibrations are good and there are no hardware issues.

IMO this is much a better approach than changing USR or forcing open loop by other means and using KFLF or FKVVS. This way does not impede any other fueling functions and is only active when lambda would normally be stoich.

Unfortunately, I have a lot of mini projects right now and testing time is scarce.

Agreed, however, closed loop is just as bad if not worse because narrowband sensors cannot operate outside of stoich.

I look at it like running boost above the MAP limit.

Unless we find a way to convert to wideband, this is the best option IMO for those looking to go this route.

Read the original post again.

It is a constant in the code, it is simply a value of 1 and not intended to be calibrated.

You should be able to find it by comparing the hex at the location above in the S4 M box to your file. However, if you are off you will be modifying code and that could be bad.

Set LAMBDIAG, LREBRI, and LREBLE all to desired target lambda. LAMBDIAG is the constant in LAMKO that sets target when there are no other influences dictating lambda. LREBRI and LREBLE are the constants in LREB that enable/disable lean/rich protection.

Lean/rich protection will disable regular lambda regulation (B_lr) if target lambda (lamsons_w(2)) from LAMKO != LREBLI and LREBRI. This function can take action if lamsons_w(2) < LREBRI (rich target lambda) and usvk < USR (lean sensor voltage) or lamsons_w(2) > LREBLE (lean target lambda) and usvk > USR (rich sensor voltage). These conditions can set B_lrnd.

All three constants should be set the same and USR will need to be tweaked to find what your target lambda translates to in O2 sensor voltage. This will preserve lambda regulation (B_lr), but accuracy is lost the further you stray from stoich.

LAMKO constant
LAMBDIAG - target Lambda constant
0x3BFB2
16 bit LoHi
X*0.000244141

LREB constants
LREBRI - Lambda constant for rich protection
0x85DBC
16 bit LoHi
X*0.000244141

LREBLE - Lambda constant for lean protection
0x85DCC
16 bit LoHi
X*0.000244141

USR - controller theshold for lambda control upstream catalyst
0x11ADE
8 bit
X*0.005216-0.2

Not to confuse anyone, the constants aren't assigned labels as they are simply a constant. The names above are just how I assigned them in my xdf.

Again, this is untested.

This is very interesting info, one day when I get my fueling sorted I will look into this myself.

A thought I had was just to hack the 02 sensor linearization, and shift it say, 0.05? The ECU sees lambda=1 but it is infact 1.05.

But now I come to think that would probably not work on a narrowband sensor.

Have you tested this more and how much does this have real effect on mpg readings?

Ditto. And in ME7.1, there is no SAI, and LAMFA is disabled anyway.

Gee, I wonder why?