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

[Bruce A Bowling]

>Its interesting you have brought this up as I have considerable experience of statistical variance in measurement methods
>in respect of nucleonic mass flow ore gauges, back then foxboro controllers didnt like much hence the need for an
>intermediate step, but if I elaborated on that I might be accused of saying "size does matter" and I'm not in a boasting mood today ;)
>

I also have considerable experience in stochasic estimation and robust control, both in my graduate work and direct implementation in particle beam accelerator trajectory control with 10,000 control elements and measurement points, with results published in numerous physics journals. The thing about electron-beam accelerators is that you have only one chance to get it right, otherwise you will destroy a multi-billon dollar facility. But again, size does not matter....

>In other words, the 6 deg toothed gear pulse
>is adequate to gauge engine state or rather impending engine 'change' of state. The rush and it appears an overly complex
>rush to the notion of a Kalman filter as the base reference is tangential to a really simple algorithm to interpolate the best
>guess for the start of dwell for an ignition event, ie I stand by my earlier comment, its needlessly complex and I will add
>that a simple binary interpolation will do and easy to add a accel add/sub factor. Its not as esoteric as a "predictor" implies,
>its a simple term in a bit of late high school algebra, lets not make it sound like its a basis for a fields medal...
>

Going back to the original answer to request for information on Kalman filtering, the response was to look at a tracking filter. 

Take a look at this link:

http://www.acfr.usyd.edu.au/teaching/4th-year/mech4721-Signals/material/lecture%20notes/16%20Range%20Tracking.pdf

At the top of page 413 (actually page 5 in the pdf), the statement "The alpha-beta tracker is a fixed gain formulation of the Kalman filter and is still widely used because it is easy to implement [and] performs well in general"

I will forgo the medal, I will take the cash instead....

Another paper: http://www.ee.ucl.ac.uk/lcs/papers2002/LCS078.pdf (see the end of the first page..)

Another one: http://code.eng.buffalo.edu/tracking/papers/tenne_optimalFilter2000.pdf


>Few points,
>a.  It cannot be accurate it is probabilistic and subject to jitter from one crank cycle to the next & subject to quality of algorithm
>b.  If  the progenitor is really interested in precision then throw away the 60+2 crank and use a 1deg or better reference,
>    there is no point in stretching the asymptote of best design indefinitely if the core measurement method has low resolution
>    and many unplanned events such as detonation/preignition/fuel type etc can upset any prediction and on a non deterministic basis too !
>c.  Do we want to be absorbed and engaged in others attempts to extract reliability from an inherently low resolution measurement
>    method in concert with a fundamentally chaotic source of energy with potentially huge variance re long term issues such as
>    wear, noise, owners treatment, value of ones intellectualizing where size of ones interest/ego is not relevant etc
>

Actually, this is correct. As stated before, higher tooth densities are desired. When interpolation is involved, its just guesswork between the tooth positions. And if there are rotational rates of change then there will be error. If I guess with a tracking filter, linear/quadratic interpolation, etc. its just a guess.

I will say that if I was also to implement a crankwheel I would use as high a tooth count as possible. In fact, I find it interesting to see ignition controller specs that advertise "0.1 degree timing accuracy". And at crank tooth update points this may be close (probably not so for other reasons). But you will never see this stated as "0.1 degree timing accuracy over all engine operating ranges".

What I need to do is dig up the mathematical error analysis we performed on crank position estimation a while back (posted on the MS forums), alomg with real measurement results, compared to linear last interval and rate-of-change of last interval (which was originally performed in the code). Also the fact that the tracking filter takes under 4 usec to totally complete on aq 24 MHz HCS12 (contrast this to the fact that at 10,000 RPM a one-degree crank angle takes 16.6 usec). Again, for high tooth count wheels the code defaults to last interval and does not use this calculation. 

And, everyone running MS-IIs right has the capability of performing their own experiment right now. One runtime variable available is the "TimingErr" variable. This is the subtraction of the predicted next-tooth time from the actual next-tooth arrival time, converted to crankshaft degrees. The coefficients alpha,beta,gamma can be adjusted in real time. The gamma value is the one that introduces feed-forward for rotational acceleration prediction. All they have to do is turn on a datalog, run the engine, then plot the results in MLV. Do not be surprised when you see +/- 10 degrees of error in timing for low tooth count wheels at low RPM....

The one thing I have dropped a few times here but no one has questioned is why is there more error at low RPMs?

- Bruce