Bizzare dyno/tuning results? Tell me what the **** is going on?!
Ok, just spend 4hrs at the dyno with not-my-car.
- EU-model MX-5 94
- stock 1.8 engine
- 125.000mi of which 12 boosted.
- 4spd, 4.1 diff
- Old and tired T25 turbo
- 0.85 bar (12-13psi)
- 5th injector and 7* base timing.
- AFR near 12. - Output: 216rwhp
- Brand new 2860 .86A/R
- 0.80 bar (11-12psi)
- Output: 225rwhp
- AFR near 12 - Output: 225rwhp
The basemap was pretty retarded (in both ways) so it took quite some time to get any power out of the engine. First run with how we got the car gave 200rwhp and we massively increased timing and stopped at 225rwhp.
The weird thing is that we're now running up to 30* timing in the upper load and rpm ranged with no knock. This is a bizzare amount?!
Attached all data I could grab together.
- Is it reasonable to expect more than 220rwhp on an 2860 at 11-12psi?
- What is up with running up to 30* of timing without knock?
- Look at the timing jump we made and how little effect it had (10* jump, 25 rwhp)
The Dtpred_gain value is the gain percentage read in (input in MegaTune above). The dt3 variable is the just-computed time delta. The drpred_old is the last delta time value.
In our case here we control ignition, which then causes the crank acceleration. So we predict the point to fire, and when the spark occurs the crank gets the "kick" to accelerate.
So ... if we have two tach points it is possible to predict into the future with simple "last interval" derivative (compared to higher derivatives) since the change in crank angular velocity is caused by our ignition event. After the explosion the crank accelerates, but hopefully we get another tach input in order to build up a new time derivative to predict where to place the next spark event.
All of this excludes changes in crank angular velocity due to compression, load variations, moments of inertia, etc. And the ignition event and subsequent expanding gases are not an infinite, short step function impulse on the crank (look up mass fraction burned and Weibe function in Heywood).
But this does illustrate the "causality" of the whole crank position problem - you do not know exactly where the crank is positioned until you get the next position pulse event. At least to the positional error of the tach circuitry. After this point the position is just a prediction w/ associated prop error until the next pulse comes in...
There is a "hidden" variable () within the code that simply subtracts the last prediction from the current tach pulse update. In other words the code uses a derivative to compute when the next tach pulse comes in, then later on the actual tach pulse comes in. The error in this is simply the subtraction. See the line of code:
outpc.spare = (int)((outpc.rpm * (dt3 - dtpred_old)) / 16667); // degx10
What this is doing is taking the current delta_t based on the latest tach update and subtract the previous delta_t value (dtpred_old). This value is multiplied by the current RPM and divided by 16667 in order to get the variable into degrees crank * 10. So the result is in crankshaft degrees, and shows the error in the last prediction compared to the current updated prediction.
The result is placed into the spare output runtime variable. Now this variable is not defined in the .ini file so it would have to be placed there. It appears after the egoV2 variable, see the runtime variable list in the code and correlate with the ini file. Be sure to note that it is x10 units. Useful is putting this in the gauge list and the datalog.
Now - some warning on this, since this variable can be easily misinterpreted without thinking what it represents. First, note that it will always be in error whenever there is an acceleration event. The MS code does not have a psychic code mod built into it (yet) so the acceleration event has to be sensed via the tach input stream. So there will be places where the last delta_t does not correlate with the new delta_t with acceleration/decel, and there will be corresponding error. This is why it is a good idea to place your ignition events somewhere close to a point where the latest update occurred.