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

cobraman at insightbb.com cobraman
Mon Apr 9 18:03:26 UTC 2007


I'm off the wall again. Is it feasable to fudge the correction factors from throttle position or TPS and intake vacuum? or delta TPS?  Accel enrichment? Steady state could use 0 factors and others estimate acceleration rate. Whadayathink?   Tom

----- Original Message -----
From: Bruce A Bowling <bbowling at earthlink.net>
Date: Friday, April 6, 2007 15:35
Subject: Re: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage
To: Mike <niche at iinet.net.au>, diy_efi at diy-efi.org

> >
> >mmm, I am guessing that a linear interpolation and table lookup 
> for accel/decel add/sub would be far quicker and use less
> >register space & memory etc ?
> >
> Guess again. Here is the actual implementation:
> errt = dt3[ICint] - dtpred;
>  ....
> // alpha-beta-gamma filter prediction
> dts = dtpred + ((inpram.alpha * errt));
> tddts = tddtpred + ((inpram.beta * errt));
> t2dddts = t2dddts + ((inpram.gamma * errt));
> dtpred = dts + tddts + t2dddts ;
> tddtpred = tddts + t2dddts;
> Three multiplies, 6 additions, one subtraction. One temporary 
> storage location. No division.
> The 'alternative' method is to use a Mx + B form, with a table 
> search lookup to find a acceleration factor to apply.  
> First build up "M" (time derivative). Can be done with time 
> period calculation subtaction, current point from previous. Save 
> result. Next, take another subtraction to determine the change 
> between the last delta_t and this one, and use to perform table 
> lookup function. This means a loop and comparing a value against 
> a list of values (note that this list lives in memory, taking up 
> space). When the value is bracketed, grab the factor and either 
> add or multiply, depending on implementation. This "list" needs 
> to be sufficiently populated to deal with the wide range of 
> possible correction values required for the range of delta-t's 
> experienced. Anywhere from a few microseconds up. The more 
> values the more potential checks and the more memory space 
> required to hold the compared values and the factors.
> Go ahead and implement this. Then deal with the fact that either 
> the "factors" are coarsely-spaced to save memory and hence the 
> acceleration error will build up (integral windup, been there, 
> done that), or the table becomes huge with lots of comparisons. 
> Also - in an earlier you stated that a predictor-corrector setup 
> was not needed. Guess what? The "Mx + B" is really an linear 
> interpolation, using two measured points to predict an event 
> into the future. And the two last obtained points are the 
> correction update. You have just come up with a predictor-
> corrector scheme. But then you said it is not needed. But here 
> it is nonetheless. 
> - Bruce
> _______________________________________________
> Diy_efi mailing list
> Diy_efi at diy-efi.org
> Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi
> Main WWW page:  http://www.diy-efi.org/diy_efi

More information about the Diy_efi mailing list