If you have a registered version of TS, use VEAL, but generally do not ALSO use MLV to massage the tune:
they will fight each other.
(MLV has it's uses: at WOT and high RPM, and for general log viewing/graphing/analysis)
The lamda signal can have a delay at low RPM/load of >3 seconds, and varies with load and rpm.
VEAL/TS has a delay table to account for this, MLV has a single value and small range of delay, so it does not deal well with any acceleration, and then only over a fairly narrow range of RPM/MAP.
(It will "tune" for you anyway, but VEAL will do a MUCH better job of it)
The following is what I determined to be about right on MY setup, YMMV severely.
Lambdadelay.jpeg
This is not documented at all, but you figure it out once you use TS/MLV for awhile.
The delay table is planned for a registered version of MLV
eventually, and a realtime implementation and tools were even slated for MS3-v1.2 firmware (not in TS, in the MS3 code itself, so CLO2 control actually can work
properly) not sure if it's going to get in until 1.3.
Note the lambda delay table does NOT get "loaded" to the MS or msq: It is part of the
TS project, and must be exported>imported if you upgrade FW/start a new project.
(I keep forgetting this little detail and after trying new FW wonder why VEAL suddenly
sucks and wants to change everything ~randomly)
In the meantime, if you have it, IMHO use VEAL exclusively to calibrate your VE table.
The main issue I had with the whole setup was
really verifying the MS and the WBO2 truly agreed.
Analog inputs are ~guaranteed to need some calibration scaling.