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

[Mike]

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

Would be good if you defined the labels precisely, see note at bottom of email

I feel there is an even easier way to do it - start by keeping it binary centric, ie perhaps 4
samples instead of three, lookup table in need not be any more than 16 entries, I doubt if any
driver would know whether its 16 or 4 or if the acccel "predictor/corrector" scheme was even active.

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

What I am suggesting is do a blind trial as per previous email, I dont expect this complexity is necessary to handle
instantaneous acceleration - perhaps, except with some acceptable granularity which wouldnt use up
much processing time in relation to the driveability metric,

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

Well sure you can tell me to "go ahead" but frankly I'm not interested in that I dont have the equipment, I dare
say if I did and some spare time in lab then I could well flex the intellect,  I do that sort of thing for a living and hobby engines
that I am dealing with have 1deg crank resolution already. What I am interested in is getting a feel for the problem
and getting to grips with why people go down a particular track and clearing the deadwood, in that respect most
things are so easy to simplify by clearing through the keywords. Sorry to sound like a smug jerk but I implemented
a fuel injection controller in a ford escort kent motor around 1982 for my Engineering Thesis final year, we had
a console between driver and passenger running a Z80 with the CP/M operating system. The Non Maskable interrupt
was the sync from the distributor which simultaneously switched memory so the o/s could continue in background
as if it was a standalone computer. Trouble was we couldnt write to floppy if engine over 1000rpms but that was a minor
headache. In that environment with limited processor power, memory and register space we routinely arranged maths
in a binary centric way to absolutely minimise multiply and divides and the type of problem you describe is so akin
that our experience. In respect of your solution to the 60 crank tooth problem,
I'm really interested to know if the driver can feel if its on or off - in a proper experimental trial ?

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

Really Bruce,  you dont need to complicate the maths by using phrases/keywords to add a sense of mystery ;)

y=mx+b is fine for me

:P

mmmm, Actually the "corrector" keyword you use has me puzzled, isnt it just applying the estimate to the
next impending ignition event, on the next full cycle you should be careful what terms are carried through as you
might have any number of events unsettling the algorithm, therefore keep it simple... ie. I dont see the value
of retaining much except the previous 4 timing crank tooth periods to gauge the speed and acceleration and only
for the expected *one* ignition event...

note:
<hrrrrm> I cant see from your psuedo code above if you do retain much cycle to cycle, can you clarify ?




Regards from


Mike
Perth, Western Australia
VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, guaranteed  !
Twin tyres for most sedans, trikes and motorcycle sidecars
http://niche.iinet.net.au