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

[Mike]

At 08:34 PM 4/4/07, you wrote:
>>
>><cough> Drives the point but the ready paradigm of violence doesnt help your case ;)
>>
>
>But it did catch your attention. 

<hrrrm>
Explanation of the core issue would be quite sufficient thanks, Some ancient
Sufi philosophy has something pertinent to report about the proclivity and type
of analogies chosen by 'some'  people to illustrate a specialised thought process in
the assumption the intended is a complete ass driven more by shock and awe
emotion and  without cognition of the potentials,  but then, I digress... Nuff said.  :o)

>>You mean to say the real world of el cheapo crank triggering methods.
>>
>
>Unfortunately, millions of people are stuck with el-cheapo crankwheels. We agree that its not optimal, but for many its the situation they are in. 

Ok sure, there are many ways to approach this, some darwinian as you have
no doubt observed over some 7 years and some rather more directed with precise knowledge
of information theory and combinatorial methods of binary centric functions and relations  ;)

>>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 ?
>
>What happens if you have one source of data (namely the crakwheel sensor), thats all you have, that has the same statistical variance, and implement a Kalman configuration? There are no other sources of measurement data, other than the one sensor, yielding the exact same error distribution each and every sample. And a linear prediction of an event into the future as your model? The full Kalman reduces to a simple predictor-corrector method. This was done in the famous example in the Maybeck book, but even this example had a few different sources of measurement. To say that a tracking filter is not simply a reduced form of a Kalman filter is incorrect, and the literature is full of references to this effect.

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

Suffice it to say, that assuming best attention to physical layer, then comms layer will have miniscule statistical variance
in a (mostly) deterministic process such as an internal combustion engine and the instantaneous changes in rotational
velocity of the crank tooth gear assembly which forms the core of our attention. 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...

>>This raises a question, do you need to know instantaneous changes in rotational acceleration within
>>the 6 deg period of two adjacent crank pulses ?
>>
>
>You assume that there is always a high-density tooth count crankwheel available, it's siply not the case with many existing installs. Plenty of 12, 24, and tons of 36 (EDIS) setups out there. Again, they are not optimal, but they exist nontheless.

Ok fine, these are conversions I am guessing from non-efi to efi type systems where performance in respect of power
is ahead of that of emissions and as an experimental/educational basis for the participants not necessarily as a plan to
take over the control systems of all lesser beasts for some commercial marketing plan to replace earlier analog controllers en masse !

>>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 ?
>
>
>A few places where Vdot is required. One is to maintain accurate dwell charging of an induction ignition coil. If a coil requires 2 ms to charge to a given energy level, it will always require this (given potenital, R and L are the same). The Vdot term is used to adjust the turn-on time of the coil such that when the coil discharges in the future it will have charged for the requisite 2 ms. Without this correction insufficient spark energy is delivered (fron real-world experience).

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

*grin*

Therefore,

if it was my engine, I would throw away, or rather not use the 60+2 crank timing except as private entertainment and great
method to either create a mausoleum to my time on earth or enjoy the effect it has on further isolating me from non technical female
company, no I do not fear success in that regard but I must observe it does affect many of my colleagues... So I would opt
for either a different engine with inherently better EFI based sensors or cast aside the sentimentality of an older rotating piece of
aluminium and steel in favour of said non technical female companionship. Thus solving the problem at both ends :)

Sorry, to clarify, choose a better engine or attach a better sensor, Audi had something to say about  if I recall 10 years ago !

>Also, the placement of the actual spark event needs to be corrected for acceleration, otherwise there will be spark retard during acceleration due to incorrect placement of the event. Stated again, the amount of error depends on crankwheel configuration, and RPM. 

No need for any kalman or kalman like *filter*, it is needlessly complex as it starts from the wrong end of the problem.

Start with the issue of linear interpolation *and*  add/subtract a factor based on y=mx+b from the graph of rotational velocity
vs time for the last 3 "or so" 6 deg pulse events gated through a suitably high enough base clock and counter which almost 
all micros have in abundance. AND I might *add* that judicious selection of the clock rate, in concert with rpm range and
mass of engine in respect of range of rotational acceleration acceptable might well, with the aid of optimised binary centric
code allow ones timing "fudge" factor to pop out, as it were without regard to any notion of Kalman filtering or even reliance
on any sort of complex and timing consuming maths,

ie. Start with interpolation, add/sub rate of change factor and do a table lookup to save time, gawd knows table lookup is
far more efficient and effective when granularity issues corrected than the time take in maths... ie I dont need a divide waster...!

>I am really not trying to sound like a jerk here, but we have spent over 7 years on the MS system and have researched/implemented many different algorithms. From the real world measured data, for low tooth count wheels a form of interpolation is desired. For high tooth counts it is not. We have settled on a tracking filter mainly because it is easy to implement and the data shows it performs as well as more complicated prediction methods, and is a trivial computation burden with the processor family we have chosen.

Sorry I probably sound like a smug jerk already but what you really mean in above para is its taken 6.9 years to talk about
and identify the problem for old crank style timing and 0.1 years to act on it, though it might have been attempted at various
levels prior to precise identifications resulting in a usable outcome, such darwinian approach is interesting if you have a
fundamentalist approach to the philosophy of technical knowledge but my interest in mystical anthropology gets in the way ;)
In other words religious literalism in defiance of darwinianism is a lost cause in relation to diversity of technical methods...

In my (commercial) experience and that means having to clearly identify the issue and think it through solidly over a couple of
days means it should take a month or so of real effort to arrive at a practical (prototype) outcome allowing for coding, testing
and critical judgement in respect of market suitability. 7 years seems like a political problem and has never been approached
(as if) a strict commercial outcome was any sort of intention...

I could have shortcutted the above diatribe by saying:-

1.    Test the system with basic linear interpolation in a non anthropic environment. ie NO placebo possible effect.
2.    Switch on the acceleration add/sub factor as per y=mx+b and test again, re 1 above.
3.    Compare results and please forget using the word Kalman - in this case it will lead you astray and take up time...


Settle on it as an experience and move on to something more interesting and challenging, and if you really want to make
things work well on an ICE, then remove any basic imprecise measurement methods such as 60+2 and use better sensors
to the CPU time can attend it self o goal seeking behavioous both short and long term for emissions and fuel economy,
in other words get a handle on information theory and maybe Godel if you have the patience ;)

ie. ICE's have chaotic source of energy by first principle, to remove the potential for such core chaotic behaviour to ripple
through a sampled data system and cause discontinuities affecting control system stabilities one must focus on
highest resolution sensors, CPU's with sufficient power for crank by crank goal seeking and sufficient memory for
logging and long term goal seeking driver related responses, interfaces etc...

I'll go back to sleep now for easter,

cheers




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