MembersPage/GergelyLezsak/FirmWare

Firmware


1.2.15 experiment with KNOCK_ALTERNATIVE

Upgraded on car from good-working 1.2.11. Upgrade process was fine, had to set:

Knock view group in VemsTune 1.5.10 showing knock values (instead of individual power, just as it supposed). Both knock channels are fine, after some soldering for correct EC-18 pinout.

Problems on user interface:

IAC dualsolenoid new feature:

Log file: http://nexus.dynaweb.hu/~lezsi/vems/fw1_2_15/v3.3_n002382-2013.08.14-23.04.56.vemslog at positions: 2:33, 3:55, 5:42, 6:02, 7:05, 7:38, 12:59, 13:22, 14:28

-- This section is for 2013-08-08 build:

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

  • (fphil)thanx for noticing the bug, was also with the 1.2.14 version (now deleted), I was installing injection on the biturbo and getting mad
--

update:

-- 2013-08-11 build resolved the problems above, car runs fine!

Here's a log of this experiment:

http://nexus.dynaweb.hu/~lezsi/vems/fw1_2_15/v3.3_n002211-2013.08.11-20.12.27-knock.vemslog 

Normal noise levels through the rev range can be seen at 4:18-4:26. Probably a real knock event of knock3 and knock4 can be spotted at 3:50 -due to my ignorance of temperatures.

No knock action was set here, but this level of noise difference is quiet promising!

 update2:

It is a log where knock action is set with very low threshold to show retard intervention without real knock:

http://nexus.dynaweb.hu/~lezsi/vems/fw1_2_15/v3.3_n002382-2013.08.13-22.56.33.vemslog


Fixed - thanx for the report

Build of 2013.08.29 came up with a very rare but annoying bug: probably ignition event miss a few times in a 5-10min period of normal cruising. It was reproducible, but not easy.

The symptom was finally reproduced, and fixed (1.2.16 fw from 2013-09-23 or later does not have it). An apparently innocent change accidentally caused an order change between using and changing a variable (indirectly via a subroutine)... Delaying fw release substantially

Confirmed: 1.2.16 solved all previous ignition problems. PWM idle solenoid switch-off also can be disabled. Nice!


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):

inj-volt-comp.png

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

around 14:39, 14:47..

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:

http://quasar.dynaweb.hu/~lezsi/vems/fw1_1_7x/v3.3_n002382-2010.06.20-19.35.15-1175alaphangolasOK.vemscfg

1.1.78 firmware with your config and works fine.

http://quasar.dynaweb.hu/~lezsi/vems/fw1_1_7x/v3.3_n002382-2010.06.20-17.56.20_1178_norpm_signal.vemscfg

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:

Observations by MembersPage/GintsK.

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

[Config and logs]

2. Relative boost

there's no change of boostDC excepting a very slight decrease at extreme high map

[Config and logs]

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.

[Config and logs]

4. Simple open loop boost

there's no change of boostDC excepting a very slight decrease at extreme high map

[Config and logs]

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

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

...

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).

[Config and 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(?)

[Config and logs]


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: