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

Mike niche
Wed Apr 4 05:22:18 UTC 2007


At 04:35 AM 4/4/07, you wrote:
>>
>>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.

not in terms of the accurate terminology of the basis for a Kalman filter which is to asses a series of data points
and adjust one or more first or second order filter coefficients...

What's being done is more akin to basic interpolation albeit with a few smarts, linear or quadratic...

>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. 

<cough> Drives the point but the ready paradigm of violence doesnt help your case ;)

I would prefer to think of it as a basket of fruit delivered in round robbin fashion. :)

>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.

Well most engines (afaik these days) have just that level of resolution or even better.
The Crank Angle sensor on a RB30ET motor and the later derivatives have a discrete
pulse edge on each deg of its rotation and as its on the cam, then its equivalent to 0.5 degree of crank
which is satisfactory.

>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. 

You mean to say the real world of el cheapo crank triggering methods.

The technique you are talking about could be termed "divisional instantaneous interpolation" but
as there is no filter in respect of first or second order sampled data systems its not a Kalman
filter in the truest sense of the word.

There are several 'real world' examples of interpolation of a similar paradigm to that which is
referred to in resepct of 60 teeth on a crank ring gear that was in use before Kalman...

>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. 

Ah ha, you might well use a Kalman like technique to arrive at rotational acceleration as a factor
to use (perhaps) for additional injection in the same vein as an accelerator pump for carby systems...

ie. its "Kalman" like because you use the previous time samples between pulses but you are not
using it to change a filter coefficient etc. Your a-b-g filter is really a predictor isnt it ?

>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).

This raises a question, do you need to know instantaneous changes in rotational acceleration within
the 6 deg period of two adjacent crank pulses ?

Is it not sufficient to measure the period of time between those 6deg pulses, other than to
inject a bit of extra fuel for acceleration, what else do you need it for ?

>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). 

There are easy binary functions of shift/mask/rotate etc which can give a good approximation
with little granularity. 

>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.

Sure, but effectively you are using either linear or quadratic interpolation of a data set,
that doesnt automatically make it a Kalman filter, such interpolations have been around
before Kalman in analog systems etc

>>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....

Thank god for that, there was some considerable list noise on MS years ago re that subject, worrying about
a few mA here and there, glad its been much simplified,

cheers

mike




Regards from


Mike Massen
Network Power Systems
Lab 08 9444 8961
Mb 0438 048961
Perth, Western Australia
* VL/VK & VN/VP/VR GMH Commodore Fuse Rail that wont warp or melt !
* RB30 Skyline/Nissan/VL Milspec ignition drivers with diagnostic features now in economy trials
* Twin tyres for most sedans, trikes and motorcycle sidecars
* Industrial grade PolyVinyliDeneChloride (PVDC Copolymer) in bulk, the best
  oxygen and water protective barrier you can find for circuit boards.
* Special equipment on offer, 60KVA UPS with large battery cabinet - AUD$12K
Web site under construction   http://niche.iinet.net.au




More information about the Diy_efi mailing list