Firmware
---
1.2.15 experiment with KNOCK_ALTERNATIVE
Upgraded on car from good-working 1.2.11. Upgrade process was fine, only had to set lambda sensor type LSU 4.2
Only config validation warning left were EGO correction limits which is suggested between -25..15% and I used to have +-20%
Knock view group in VemsTune 1.5.10 showing knock values (instead of individual power, just as it supposed) when wokring on car online, but it's not working when reviewing the logs offline.
Engine started up fine, and seemed to work OK, but later found a major issue, related to excess fueling. It is felt at idle as engine is bogging a few cycles and lambda gets very rich. It is only a half second event at idle and goes back to normal idle for seconds after, but continously repeating. At light load cruising it seems as a heavy fluctuation in lambda and can be felt in acceleration power as well. I cannot see it in logged injector pulsewith.
Log:
http://nexus.dynaweb.hu/~lezsi/vems/fw1_2_15/v3.3_n002211-2013.08.10-22.20.04.vemslog
---
1.1.81
The car now running on 1.1.81 fine.
Interestingly fuel mapping gone rich around idle (from 1.1.80), no changes otherwise.
TPS lag problem resolved.
Still running on 1.1.81 (at january 2012), this time on gasoline, so I'm fighting with very low inj pulsewidths.
Tried to figure out injector parameters, and discovered strange behavior of injector battery voltage compensation.
According to my understanding of Vemstune help, it seems that compensation is between 7 and 19 volts, centered at 13.5V (where compensation supposed to be zero):
Controversially I'm getting ~0.5ms value (according to vemstune calc model) at 13.8V, when battery comp. is set to 208us
http://nexus.dynaweb.hu/~lezsi/vems/fw1_1_81/v3.3_n002211-2011.12.29-11.20.03.vemslog
or 0.2-0.3ms at 13.3-13.7V when compensation is set to 544us.
http://nexus.dynaweb.hu/~lezsi/vems/fw1_1_81/v3.3_n002211-2011.12.03-17.16.43.vemslog
It seems that it never gets close to zero or become negative(?)
It is [at least was in 1.1.5x times] centred @13.2V And value is adder @7V. So if your INJ open time is 1000us@13.2 you should get 1700us@7V and 300us@19.4V with 700us Injector Voltage Compensation configured. I never did not find it properly documented in English. Might be my empirical findings are usable: http://www.vemssupport.com/forum/index.php/topic,661.15.html see post #21 and #33. GintsK
---
1.1.80
Succesfully tested 1.1.80
Fuel injection timing seems fine, my engine like the limits: 210 or 720 degrees (and around) gives nice idle, but middle-area like 400-500 degrees results in missfire and jerking.
Slow TPS refresh problem confirmed here also.
Check http://quasar.dynaweb.hu/~lezsi/vems/v3.3_n002211-2010.07.31-16.25.24.vemslog
It causes latency in inj pw change also when changing from deceleration to acceleration, so the changover can be felt a bit 'rude'.
---
1.1.75 - 1.1.78
I've succesfully upgraded to 1.1.75
working 60-2 + cam sync 6cyl config:
1.1.78 firmware with your config and works fine.
logs of cranking (this was with experimental 1.1.78):
http://quasar.dynaweb.hu/~lezsi/vems/fw1_1_7x/v3.3_n002382-2010.06.20-17.51.17.vemslog
http://quasar.dynaweb.hu/~lezsi/vems/fw1_1_7x/v3.3_n002382-2010.06.20-17.51.48.vemslog
---
1.1.56 - 1.1.70
I'm running on 1.1.56 (non-ps2) for quite a long time now, with general success (however current vemstune releases cannot show anything for alt. boost target for this fw. version), still. it's a good working version for me.
One of the weak points is coldstart with E85, which lead me to go for 1.1.70.
I've tried to review all the forms in vemstune, after upgrading, still somehow the engine is appearently very-very lean (stuttering, stalling and so) -with same injection/VE values.
I had nice idle with lambda ~0.95 using 1.1.56, but cannot get it to stay running (idle) above lambda ~0.80 with 1.1.70
I've got configs and logs here : http://quasar.dynaweb.hu/~lezsi/vems/vems-1170-upg.zip
First config is my nice working 1.1.56, using fully sequential siemens deka 870cc injectors, 2x3 Bosch wasted spark coil.
The next one is after upgrading to 1.1.70. The following ones are slightly playing aroung with it -without any success.
The first log is for the working 1.1.56, second is for 1.1.70 which is erratic up to the point where I make it very rich ( by rising req_fuel), and it gets erratic again, when I lower it back.
Third log has been made after downgrading back to 1.1.56 -it's fine.
I need your help, what could be wrong?
Thanks!
About 1.1.53 (non-PS2)
Observations:
- Idle smoothness is noticeably improved over 1.1.50 (why?)
- New cranking PW table allows only 100-495 (5x) range. I used to have 10x range for -40..+77C before.
- "inject additional fuel at cranking" allow 5x5x=25x for first revolutions.
- Thanks, it is probably OK (can't check at summertime), but I can't see the difference on PW values in logs.
- "inject additional fuel at cranking" allow 5x5x=25x for first revolutions.
- it seems that there's no afterstart enrichment or it is behaving very differently(?) and couldn't find the way to adjust
- New cranking PW table is at the same time is afterstart enrichment.
- can't see that "inject additional fuel at cranking" is doing anything
- see above. read more here http://www.vems.hu/wiki/index.php?page=MembersPage%2FAndrey%2FCranking
- Now I see, I had to re-read a few times to understand. Thanks!
- see above. read more here http://www.vems.hu/wiki/index.php?page=MembersPage%2FAndrey%2FCranking
- boost alt dc is slightly more than zero when reference and PID is all 0. (Still in 1.1.56) Plus in absolute mode it ignores "valve off below pressure" value (in relative mode seems OK).
- lcd refresh speed is still broken (from 1.1.4x?), especially at startup
- boostalt ref table shares kPa scale with ignition this makes relative boost scale unusable in situations, and dangerous
- PID boost uses gear-based boosttarget scaling well, but ignores gear-based reference pos (originally based on boostalt table's bottom rows), instead uses the old fixed reference positions. I'd really prefer the original table-based ref. pos. logic, as many monster-turboed drag cars tend to build overboost with rpm and I couldn't handle that with a fix ref.pos. + PID in the past.
- Yes it is correct, rows was dropped temporarily with boostcontrol development, i'm thinking about configurable that feature without brake of altboost. -Andrey
- That would be fine!
- Yes it is correct, rows was dropped temporarily with boostcontrol development, i'm thinking about configurable that feature without brake of altboost. -Andrey
- Cranking VE% is ignored. I could change to any value (tried 10, 127, 254), no change to effective crank-PW
- there is bad config, bad cranking rpm, etc. "inject additional fuel at cranking" will not work too.
- Just found that "cranking" status bit is always inactive in my logs, even when I'm cranking around 250rpm while cranking RPM is set to 300. However, cranking PW table is applied. Logs, config and firmware data here: http://quasar.dynaweb.hu/~lezsi/vems/fw1_1_53noPS2.zip
- Resolved. Original problem was that rpm (in logs) started with a high value (like 700) before settling at 200-300, and 1.1.53 thinks that the engine was over cranking so it doesn't apply cranking pw later. 1.1.56 works again, it always apply cranking pw if rpm is in the cranking range.
- Just found that "cranking" status bit is always inactive in my logs, even when I'm cranking around 250rpm while cranking RPM is set to 300. However, cranking PW table is applied. Logs, config and firmware data here: http://quasar.dynaweb.hu/~lezsi/vems/fw1_1_53noPS2.zip
- there is bad config, bad cranking rpm, etc. "inject additional fuel at cranking" will not work too.
- Vemstune flags getting wrong status values (shift-cut, ign-cut) when a table-editing window is opened. Sometimes it blinking like a disco-light.
- TPSacc value in logs is between 0 and 0.5, I'm not sure whether acc. enrichment is working properly at all.
- read http://www.vems.hu/wiki/index.php?page=MembersPage%2FAndrey%2FFuelFilm
- Got it, and -based on engine behavior- it works. But in logs I cannot see sane TPSacc values, what are these 0-0.5 numbers mean? Could it be changed to more friendly values (PW?) just like in old firmwares?
- It is already in milliseconds, i have same 0-0.5ms for 380cc/min inj, but digits are correct for me, and some note, simple fuelfilm is not a part of acc, and does not go to log for a while because i forgot about it, positive part of film will be added to tpsacc at log. Disable simple fuelfilm calcs for advanced checking and compare PW with or without acc active. - Andrey
- OK, will check. Including fuel-film values would be also fine!
- It is already in milliseconds, i have same 0-0.5ms for 380cc/min inj, but digits are correct for me, and some note, simple fuelfilm is not a part of acc, and does not go to log for a while because i forgot about it, positive part of film will be added to tpsacc at log. Disable simple fuelfilm calcs for advanced checking and compare PW with or without acc active. - Andrey
- Got it, and -based on engine behavior- it works. But in logs I cannot see sane TPSacc values, what are these 0-0.5 numbers mean? Could it be changed to more friendly values (PW?) just like in old firmwares?
- read http://www.vems.hu/wiki/index.php?page=MembersPage%2FAndrey%2FFuelFilm
- Is max-TPS flood-clear mode still existing? Cannot see, injectors always squirt disregarding my TPS value.
- Seems you have broken crank mode, it could be fw bug or bad config, because i use another FW with experimental features, and a have all work, crank and floodclear work up to specs, see at [this] picture as example. So investigation needed, put your logs and msq, and yes i use MT only - Andrey
- Definitely, check my logs linked above! Thanks!
- Seems you have broken crank mode, it could be fw bug or bad config, because i use another FW with experimental features, and a have all work, crank and floodclear work up to specs, see at [this] picture as example. So investigation needed, put your logs and msq, and yes i use MT only - Andrey
- After decceleration, idle RPM is left at ~2000rpm sometimes(?!) - normally it is 1000rpm. Still in 1.1.56 and 1.1.57, in more cars. After kicking the throttle slightly it always settles to correct idle RPM. Can't see any problem in logs; IAC-DC,spark,lambda,TPS is similar to good idle values.
![[this]](http://www.vems.hu/files/MembersPage/Andrey/CrankSettings/crank.PNG){kind=link}
Observations by MembersPage/GintsK.
- I want to use 1.1.5x but can't do it without Megatune.
- Some days ago i tried 1.1.53 on real car and found huge mismatch between Lambda values on LCD and Megatune. Vemstune was better. definitely MT have bug. I found error in vemsV3.ini for MT: lambda= { (egoADC + 306) / 470} should be replaced by lambda = { table(egoADC, "WBlambda100MOT.inc") / 100.0 }.
- Confirmed: megatune 1.1.53 shows false lambda values (always around 0.9)
- Due to above problem I tried different firmwares on bench. In reality LCD and MT/VT do not mach in Lambda/AFR values. At lean LCD reads 1.13, MT 1.10. Leaner - error is larger. LCD 1.25 MT 1.19... At n/a typical power peak LCD and MT shows about same 0.90 At rich LCD .079 MT 0.80...0.81.
- Tested and present in 1.0.73final, 1.1.27, 1.1.44 and 1.1.53 (except MT where error was huge). None reported it before. I guess because no easy way to get rock stable lambda reading for comparing. I performed it with gas soldering iron on the table.
- So big question which one is right?
- According to Marcell, firmware (hence LCD) uses slightly different interpretation of the Bosch LSU4 sensor curve than megatune. I can confirm that LCD has always slightly higher value in the lean end. Would be interesting to calibrate to a 4-gas analyser.
- Next problem - lack of output channel for Boost alternate PWM. Without this building a Boost PWM table takes much longer. And yes - boost PWM table must have own rpm/load bins!
- I agree - 10x cranking is a must in cold countries. I do not like LCD start up since 1.1.4x. It's broken.
- se above, 25x possible, Andrey have perfect engine start from half revolution at -35 Deg
- Also some clarification of temperature curves adjustment method necessary. Some reference needed. Easiest - voltage drop over NTC at 17 points. I suppose these points ar not temperature as Vemstune presents it, but 17 fixed ADC values. Or?
- It is temperatures, for 17 ADC values, 0-0V, 17-5V.
In overall 1.1.53 is full of useful improvements for both - extreme race and street engines. MembersPage/GintsK
I've made some experiments with 1.1.50 non-PS2 (gear-boost in theory)
Firmware was uploaded and verified by latest vemstune, settings, logging were made in megatune for 1.1.50 (hacked to support 16x14 which is the only supported fw I guess)
So first I tried to use boost_channel only (the PID based one), boostalt was disabled all the time. Still,
alternate boost's "mode" setting seems to alter the PID boost_channel's general behavior.
- And it seems it has nothing to do with gearboost yet?? Strange to me.
OK, so my test-cases:
1. Absolute boost
there's no change of boostDC excepting a very slight decrease at extreme high map
2. Relative boost
there's no change of boostDC excepting a very slight decrease at extreme high map
3. Simple closed loop boost
boostDC seems to follow closed loop reference from boost refDC table (rpm/map based), however boostDC gets lower than it is specified in the table's reference values. One more interesting thing is when boost target is getting close, boostDC gets down to zero (it's fine) but after MAP has passed the target slightly, it jumps back to some higher value.
4. Simple open loop boost
there's no change of boostDC excepting a very slight decrease at extreme high map
above the target MAP level boostDC jumps back to around refpos (from zero). annoying.
Just tested 1.1.53 (PS2 version, will test non-PS2 later). Boost target calcs and outputs seem to work
- there are some gear related changes since 1.1.50 so 1.1.50 will never be supported
- the quasar.dynaweb.hu configs contain very strange values. P=I=D=1, all TPSscaling=100
- see [test config] - MAP kpa unit = 4 kpa mode is useful for testing, it allows up to 1020 kpa/5V MAP voltage.
- see GenBoard/UnderDevelopment/FirmwareChanges for boostalt simpleclosedloop note (uses TPS scaling array for different purpose, therefore even PID boost does not use it
- simple openloop and simple closedloop is just compatibility (behavior unchanged, and will not be changed) for users who used it before. Relative or absolute mode recommended for new users for boostalt output (and/or PID for boost output of course).
We suspect that the confusion is caused by mt vemsv3.ini. Please use vemstune 2009-04-24 or newer at least to review all boost related settings.
Please confirm behaviour with above considerations.
Also pay attention to
- boost output disabled below ... kPa
- boost decrease above ... MAT
- boost decrease above ... EGT
Another tests have been made using BOOST ALTERNATE only (no PID boost_channel used here) with 1.1.50 PS2 firmware.
5. BoostALT relative
Generally it works, boostref table kPa-scale is annoying, I tried to convert it to the -155..+100kPa range (not sure it was correct). Later I realized, that it changed SPARK ADVANCE bins also! My boost-build characteristics were as expected, excepting that target somehow seemed to be ~180kPa instead of the 230kPa set (and 224(why?) in logs).
6. BoostALT absolute
It works fine, just like in 1.1.4x firmware.
For both boostalt setting, I was really missing some boostaltDC variable in logs, and gauge in megatune, as boostDC is for PID-boost only(?)
Obsolete
2006.04.18.
Finally went to firmware 1.0.38 which controls BMW idle solenoid nice. (Previous used versions were 1.0.14rc, 1.0.30rc2 - both hacked for iac)
Upgrade was not easy as car was going like shit (very weak) thanks to new ALS variables, which I wasn't able to disable completely, and retarded my ignition to hell.
I suggest to everyone to double-check changed new-old variables with comparing mcd outputs, and don't expect that FF always means disabled, like I did...
Now it seems ok.
Obsolete 2
Since I need to have customized code for IAC, tried to compile new firmware. This is not so easy in windows.
There's a great howto at MembersPage/JohanEriksson/VerThreeFirmForDummies but I had problems
When I tried "make all" from cmd.exe:
...
make (e=2): The system cannot find the file specified.
make: *** [vems.o] Error 2
I get the same from cygwin's sh.exe, and in sh.exe from unxutils
I've found that it was nothing to do with the shell and make.exe, but with avr-gcc.exe which wasn't found. (Since it was not in path)
I've found that spaces are not welcome in winavr's path, and Marcell said that if 'lib' environment variable is set (to anything) that confuses make.exe, so I made a batch file which sets the environment before I can say "make all".
It is like:
set lib=
set path=%path%;D:\VEMS\winavr\bin\;D:\VEMS\winavr\utils\bin\;
After that I was able to compile the firmware succesfully. Thanks for the ideas Cell and Ben.
About setting prog.pl under win32:
- Had an ActivState perl installation
- Had to download SerialPort.pm, it's in Win32-SerialPort-0.19.tar
- Had to download and install win32-api pm, which was in Win32-API-0.41.zip. This one really need to be installed not just having copied into lib directory.
- To install: > ppm
- >add repository name_of_the_package_folder
- >install win32-api