Some days ago I retune one of my first VEMSed cars. Reworked engine.
And what really surprise me: extremely fast and precise Ego correction!
Here is example with hardly wrong VE map on 1.1.27:
(http://pic2.fotki.lv/photos2/6/W0002996/000299578/000029957735_%23_2_%23_GintsK.jpg)
Since that time many cars are tuned and this awesome response forgotten.
Here is example from 1.1.63 with flat VE map, close to finished:
(http://pic2.fotki.lv/photos2/6/W0002996/000299578/000029957736_%23_3_%23_GintsK.jpg)
What happened? Is it some settings issue? Or firmware? Or what?
Here is closed loop settings from 1.1.27:
(http://pic2.fotki.lv/photos2/5/W0002996/000299579/000029957832_%23_2_%23_GintsK.jpg)
And here - from 1.1.63:
(http://pic2.fotki.lv/photos2/5/W0002996/000299579/000029957833_%23_2_%23_GintsK.jpg)
Gints
could this have anything to do with the smaller lamda table and the fact that the ECU is interpolating??
on the other hand, i see you have as warm up time for the lamda 20sec and on 1.1.63 8sec? how much time is it actually required? I have it on 30sec on mine...
I have been told on several occasions the warm up time should be set to 60sec and not to change it
The other thing thats different is the reactivation time. 17 cycles seems a little too long to me?
ok i see. I had it on 30 from the start, as the base map. didnt change it
indeed reactivation seems to be quite big. In mine is 2 in that field. I have tried with more but i got better results on 2.
Does warmup time has something to do with response?
If this value relates to WBO2 inactivity after engine start - seems it do not work.
Isn't deactivation time means time after acceleration?
In both cases smaller lambda table should not be problem: commanded lambda is same during all rpm range at WOT.
I think crispy Ego Correction was lost before both mentioned values was implemented.
in new firmware step size isn't used, so step of change is only determinated by P factor, speed with engine cyles delay.
can you make it more clear what you mean?
Is P factor the speed with engine cyles delay? or something else?
and which settings affect it most?
Quote from: MWfire on February 07, 2010, 07:23:07 PM
in new firmware step size isn't used, so step of change is only determinated by P factor, speed with engine cyles delay.
What settings you usually use? Can you achieve same quality as my 1.1.27 example?
Also: is it possible to increase WBO2 sampling rate? Now I have 6-7 per second - no matter what is rpm.
Lower the number of cycles before changing correction. That will speed things up.
Step size has the wrong name, that will change..
The report frequency in the logs of the lambda value is the same as with everything else.
I get 15 Hz with VemsTune which works at 19200 bps.
It depends on your laptop and serial port.
Here is small part of datalog. It is cleraly visible - lambda in my logs has 3-5times slower sampling rate than overall datalog rate:
(http://pic2.fotki.lv/photos2/8/W0002998/000299742/000029974189_%23_2_%23_GintsK.jpg)
Interesting but Yes, in my old and new 1.1.27 too...
Engine cycles before correction in old firmwares are 14
Engine cycles before correction in new firmwares are (10 * cyl num) = more times bigger than 14
Andrey, thank you for posting here!
Does your mentioned delays is hardcoded and used as addition to engine cycles before correction?
So for best response engine cycles before correction can be even 0?
Can you also commnet 6 samples per second from WBO2? It is so for ages since 1.0.x firmwares. Seems to me due to some filtering: even with non working cylinder Lambda stays same (more or less true).
Main reason for asking is awkward acceleration enrichment representation in logs. In other circumstances filtered signal is quite OK.
Gints
I made some rework for wbo2 code (function splitting, changes in ADC sampling etc) but sampling rate should stay same as early.
I added "(*cylnum)" part to all cycles in EGO menu for use same settings at different engines, but fogot make note in changelog, so if was 14 cycles at 4cyl engine in 1.0.73, new settinggs will be 3-4 cycles, because 3cycles*4cyl=12cycles, and 4*4=16.
I tried smaller correction steps on 1.1.53 and 1.1.69 - anyway Ego looks keep target faster in 1.1.27.
Seems 1.1.70 is answer!
Quote[1.1.70] - testing
* with the given scheduler priority lambda_target lookup starved (got slow) under certain (very rare, therefore hard to notice) conditions. So any previous (after 1.1.27) is considered experimental and will NOT be released
o This should be fixed in 1.1.70 but we apply more testing specifically about this