[Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage

Bruce A Bowling bbowling
Tue Apr 3 20:35:06 UTC 2007


>
>This is needlessly complex and a complete waste of time.
>

I think you missed the point. Agreed that the best tach pulse is the actual one (causal), not a predicted one. In fact, the past history of crankwheel pulses does not strictly dictate when the next pulse comes in, and the actual measured crank pulse (corrector) overrides the predicted pulse.

Here is a pleasant example. I tie (someone) to a tree and blindfold them. Then I take my fist and punch their face. I throw a new punch once a second, contacting the face each time. I do this for hours (I am really mad). The person who is receiving the blows to the face, after a while, will come to expect (predict) that the next face smash will happen a second after the last one - after all, this is what has happened for the last hour or so. But, in reality the next punch may come sooner, or later, or never - it takes the actual punch to be absolutely sure. 

Now, back to the crank wheel, if we had the luxury to have a crank wheel with 360 teeth, and a resolution of 1 degree for ignition and spark, then we are golden, just use the actual pulse inputs and correlate events to them. Finished.

But, there exists in the real world the situation where there are less teeth on an existing crankwheel. And there exists the possibility where a ign/injection event occurs in-between teeth. In order to accomodate this the need exists to interpolate between teeth. How is this done? A simple way is to predict the desired event point based on the last two teeth time events, i.e. last interval. Works fine. Except when the wheel experiences an acceleration/deceleration. In this case the last interval prediction will not be correct. How much depends on the acceleration, number of teeth, and RPM, and the actual interpolation point. 

So how do we put in the acceleration component in the prediction? Simply take the rate of the change in computed velocity. Note that these are time-derivatives, requiring storage of past event times, and in most impementations subtractions and divisions. It works fine, but it chews up CPU time - especially for a micro which does not have natine division support. But there is another way -

You obtain position, velocity, and acceleration from the a-b-g tracking filter. 
This is why it is used. No so much for noise elimination, yes there is noise. But events like acceleration are so much more of an effect to the final result. 

Does it help to add the velocity/acceleration components to the prediction in-between teeth? You bet, and we have real measured engine data to prove it, the error in event timing is reduced when the acceleration component is added. In fact, on every MS-II datalog there is a DTPredErr, which is the prediction error of the next crankwheel tooth update event (remember the face-punching example, this is the error from when one expects the next punch to when it actually happens).

And it turns out to be less computationally-intensive, and requires less storage space, to use this form (which is in fact an IIR filter) than to build time differences and perform divisions to determine the acceleration component (see the MS code for details). 

Again, for high tooth count wheels, this is not required, simple linear prediction works fine. But for low tooth count wheels, having higher-order predictions can help reduce overall timing errors. Also note that errors deviations are greater at low RPMs compared to high RPMs.

>Me thinks the issue with Kalman filters is like the paradigm of trying to
>recycle the energy of the back emf from an injector - I viewed the latter of
>this on the MS group (of which I am a member) and its a complete nonsense,

WTF??? The MS hardware does not harvest back-EMF to dump back into the battery. Well, actually, it does during PWM current limit mode (and not final flyback), but not for energy harvesting purposes....

- Bruce




More information about the Diy_efi mailing list