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

[Bruce A Bowling]

>
>The word is _extrapolation_. You can only interpolate between known
>points. :-)

You are correct, being a bit lax on terminology.

>
>As a side issue, although desirable, there's no need to maintain
>"human units" inside the machine, especially once a timebase has
>been settled. Obviously it requires good documentations and
>subsequent programmers to be able to "think the machine".
>

Yes, its just an implementation decision. Luckly, processing power is becoming such that it is possible to maintain desired units while getting the embedded task accomplished.

>Note that when between two points as with input capture against a
>free-running counter, that one already has an angular "velocity"
>(well, period, actually) for the crankshaft. The first difference to
>expected that is captured is a measure of the acceleration when
>taken in proportion to the period.
>

This is the key point to all of this. The calculation shows that it is not enough to simply take the last two time events to extrapolate into the future under an acceleration, rate-of-change of the time events should be included, and even rate-of-change of this is useful.


>The problem is the resolution and the mechanical effects that may
>cause the captured value to be incorrect.
>

These are other error sources indeed, and all contribute, there is no question. 

>Also, because of the timer resolution and the need to add/subtract
>two values based on that resolution, the error of the result doubles
>so the notional error of any derived result is also doubled. This
>introduces an error that may creep (accumulate) in one direction for
>a few cycles until the feedback of the measurement "clicks over" and
>the error can start again, perhaps from as far as the other end of
>the error bounds.
>

Yep, and this is an effect that becomes noticeable very rapidly. To add, one needs to maintain precision in intermediate calculations.

>> degrees. To make this total worst case we assume the crank
>> (non-physically) increases at the rate of 8000 RPM/sec. We have
>> seen many datalogs of small engines exceeding this rate by a large
>> margin in unloaded situations.
>
>That's a very rapid change of rpm, but of little *use*. :-)
>

It's of total use if you happen to have an engine like this :). The real data we worked against was taken from an operational jet ski, where it experienced revs approaching 10,000 RPM/sec.

>Those errors are quite a bit larger than my calculations. I'll go
>back and check them in detail, then verify using other methods. 

The derivation was from a physical standpoint:

First, to convert rpm to degrees/sec:

  theta_dot(deg/sec) = (revs/sec)*360 = (RPM/60) * 360 =6*RPM

For example, the time to go from 0 to 180 deg with no acceleration is:

  T180 = 180 deg / theta_dot = (30 / RPM) sec

With constant acceleration we have:

  theta_dot_dot = 6 * RPM_dot

  theta(T) = theta(0) + $ theta_dot(t) * delta_t,         (1)

With the synbol $ being integral from 0 to T

Also,

  theta_dot(t) = theta_dot(0) + theta_dot_dot * t.      (2)

Combining these:

  theta(T) =  theta(0) + theta_dot(0)*T + $  theta_dot_dot* t * delta_t

           =  0  + 6 * RPM(0)*T  +  theta_dot_dot * (T**2)/2.

For theta(T) = 180 deg, we get:

                6*RPM_dot  * (T**2)/2  + 6 * RPM(0) * T - 180  = 0.

This is a quadratic eq in T (= T180 since we took theta(T) = 180.)

Divide both sides by 6 and we can write the solution as:

   T180 = [ -RPM(0) + Sqrt(RPM(0)**2 + 60 * RPM_dot)  ] / RPM_dot, in sec.

>
>You can't turn noise into signal :-)
>
>Small signals (differences) wrt error produce a lot of noise in the
>result.
>

Absolutely. As does other factors, such as the resolution of the comparative timebase, etc. One has to be aware of all error sources.

>
>In terms of guessing the position of the crankshaft, the injector
>duty cycle only becomes significant with direct injection;
>especially compression-ignition as injection is ignition timing.

True. 

>
>0.1ms would be borderline for ignition timing, spark or compression,
>especially at idle and at higher rpm.

It is borderline. The extra code uses 50 usec for timing resolution which is also a bit coarse but the limitation is in the implementation on the existing hardware.

>
>Decreasing the noise introduced by coarse resolution is a good
>thing. 

It (lack of resolution) really helped the MS1 box a lot. The increased resolution in MSII ended up creating some control loop stabilization issues in the beginning. 

- Bruce