Firmware 1.1.44/ 1.1.47 Cranking kickback

[Sprocket]

When I upgraded to 1.1.44 I suffered kickback during cranking with a 36-1 trigger. Sometimes it was fine, other times it was really bad, while other times there was only a slight kick. As a quick fix I changed to 1.0.79 and the problem disappeared.

There was a suggestion that I should invert the refference tooth table along with the H[2] outputs.

Wanting to take advantage of the better misc outputs, N2O with gear change boost control, I upgraded to 1.1.47. I made sure I inverted the refference tooth table and the H[2] table. I double checked the Trigger before TDC value with a timing light and again found it exactly 10 degrees advanced. I managed to get the engine running. The engine starts much quicker than on 1.0.XX firmwares, however, I still get a slight kick. I don't know how bad this is yet as I have not spent that much time on it.

So the question is, why is this happening??

Do I need to use cam sync with 1.1.XX firmware?

Will cam sync prevent this happening?

I intend to fit a cam sync sensor, but it wont be untill the engine refresh in January as I have to change the oil pump jackshaft.

[GintsK]

As far as I remember kikck back problems persist with camsync too.
Other bug (even more annoying) with 1.1.44 was delayed acceleration enrichment. Do not remeber about 1.1.47
No any of 1.1.5x..6x compilated with "expencive" misc outputs? These firmwares have perfect AE and no kickback problem.

Gints

[dnb]

1.1.5x seems to work much better than 1.1.44 for starting and running.  I've not noticed an AE problem with 1.1.44, but there does seem to be a rich bias in the EGO correction on 1.1.5x.  I calculated it to be rich by 0.03 lambda on average.

[GintsK]

1.1.5x seems to work much better than 1.1.44 for starting and running.  I've not noticed an AE problem with 1.1.44, but there does seem to be a rich bias in the EGO correction on 1.1.5x.  I calculated it to be rich by 0.03 lambda on average.

Can you explain this more detailed?

But anyway - 1.1.44 - all my installations  suffers from delayed AE. It is most notable when tip-in from idling. Rpms for first drops a little instead of immediate rising. no matter how aggressive/non-aggressive is AE settings. No such problem in 1.1.53. Acceleration is as it should be! Crispy! And it can not be due some 2% error in fueling if it persists.

Gints

[MWfire]

1.1.61 has "expencive" misc outputs
with 1.1.47v2 no problem with acc. enrichment
http://www.youtube.com/watch?v=1AdP1n7xH-g&feature=channel 1.1.47 firmware, stock engine.

[dnb]

Can you explain this more detailed?

It turns out that the 1.1.59 firmware had a different translation of "bytes" to lambda value than previous firmwares.  This wasn't supposed to be included in a released firmware for a while yet, so the lambda reading in Megatune/Vemstune logs was wrong.  My analysis process involves creating histograms of lambda error over all the VE bins, and there was a constant error that wasn't there from before the firmware upgrade...

The lambda error is not actually in the ECU - it's purely a logging artifact.

[GintsK]

Can you explain this more detailed?

It turns out that the 1.1.59 firmware had a different translation of "bytes" to lambda value than previous firmwares.  This wasn't supposed to be included in a released firmware for a while yet, so the lambda reading in Megatune/Vemstune logs was wrong.  My analysis process involves creating histograms of lambda error over all the VE bins, and there was a constant error that wasn't there from before the firmware upgrade...

The lambda error is not actually in the ECU - it's purely a logging artifact.

Some time ago I found differences between lamda slope on LCD and tuning program. It persists since ages. Crossing point was somewhere around 0.9 Are we talking about same? http://www.vems.hu/wiki/index.php?page=MembersPage%2FGergelyLezsak%2FFirmWare