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
More advance under hard acceleration
Moderators: JeffC, rdoherty, stieg, brentp
This one is interesting
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.
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
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
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
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
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.
About the de-acceleration. Why?
Right about now you or
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.
-
- Posts: 68
- Joined: Mon Sep 13, 2004 8:45 am
- Location: The Chalfonts
- Contact:
Calculation acceleration
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.