Page 1 of 1

More advance under hard acceleration

Posted: Thu Dec 15, 2005 1:04 am
by 4600cc
About half a year ago I asked for feature suggestions for my configuration program, I got a nice one from E. Maurice. Actually it was a megajolt firmware feature more than configuration software feature. He stated that under hard engine accleration of about 2000 rpm/sec timing could be advanced even more without harmful detonation.

Now that I'm back in business with megajolt, I actually have time to implement something like this, both in firmware and configuration software. I have many ideas, all of them are very simple and straight forward. I need to know more about how this stuff works.

Calculation of actual timing advance will be based on something called an acceleration index. Acceleration index is a difference of new engine rpm and old engine rpm over 1 clock cycle. Based on this acceleration index timing is calculated by taking advance value from table and adding the timing index from accleration index table.

Now the question is about the acceleration index table. How big should it be, what should it account for...

My question is, if engine acceleration is sustained and rpm increases, should timing increase or should it stay constant?

Another one, what is the minimum rpm/sec required for this feature to work?

Another one, how many engine acceleration rates should be considered? e.g. 1000 rpm/sec, and from then on 200 rpm/sec increments. In other words, what is effective?









AL

This one is interesting

Posted: Thu Dec 15, 2005 1:24 am
by brentp
This one is interesting because it can be implemented in the existing firmware- as it doesn't require an additional sensor input. It would require some juggling of the memory as the RAM is currently maxed out... but I have some ideas there.

On the surface- offer 10 'slots' to specify XXX rpm/sec acceleration rates, with each slot having a + or - modifier; then add linear interpolation to smooth out the curve between the points.

10 slots could be considered arbitrary; 4 might be just as good.

Let's take 4.Is what you

Posted: Thu Dec 15, 2005 1:31 am
by 4600cc
Let's take 4.


Is what you saying it should be like this?


RPM/SEC......BTDC
1000.........2
1400.........3
1600.........4
2000.........5


So if accleration index is below 1000 rpm/sec, data from table is unmodified, if it is between 1000 and 1400 rpm/sec 2 BTDC is added to data from table, if it is between 1400 and 1600 rpm/sec 3 BTDC is added to data from table, and if it is 2000 or more rpm/sec, then 5 BTDC is added to data from table?



AL

Yes, basically

Posted: Thu Dec 15, 2005 1:38 am
by brentp
Yes, basically that.

RPM/SEC......Degree Advance
1000.........+2
1400.........+3
1600.........+4
2000.........+5

Not sure if you'd want to map de-acceleration as well as acceleration..

RPM/SEC......Degree Advance
-1000.........-1
1400.........3
1600.........4
2000.........5

About the de-acceleration.

Posted: Thu Dec 15, 2005 1:56 am
by 4600cc
About the de-acceleration. Why?

Exactly. Is there a good

Posted: Thu Dec 15, 2005 2:23 am
by brentp
Exactly. Is there a good reason to have it? Out of completeness?

Right about now you or

Posted: Thu Dec 15, 2005 3:08 am
by 4600cc
Right about now you or someone else needs to explaint to me if retarding timing on deceleration does anything? And yes, how and why? I have a basic idea about detonation and acceleration, but when it comes to decleration I have no clue.

Calculation acceleration

Posted: Thu Dec 15, 2005 10:47 am
by Oliver Sedlacek
I added acceleration measurements to my version of the firmware because I wanted to estimate torque. I took it out again when I found torque estimation too difficult. You could perhaps just put in a simple linear factor of 2 deg per 1000rpm/sec.