EFI Algorithms

[peter paul fenske]

>
>Unless I'm missing something, if you use input capture on a 68HC11, your
>resolution should improve as the speed decreases (period increases)
>
>         RPM =   Constant/ pulse_period
>
>         dRPM ~  Constant/ (pulse_period^2)
>
>At low speeds, minor changes in speed equal larger incremental changes in the
>period.
>
>My personal experience with input capture was less than satisfying, but it does
>work, although you have to keep track of overflows if your period exceeds 
>2^16 E cycles.
>
>
>Cliff Ducharme
>
>P.S.  I did finish my EFI B&S, and at the ripe old age of 44 have my BSEE.
>(If anyone is interested, I'll put my project paper out on the Web.)
>
>Tnx Cliff. 
>The algorithm I wish to use would be a linear number between 0 and 255
>representing 25 rpm increments. Anyways works on paper but have yet to
>try it. The previous algorithm works by returning a no between 0 and 15
>each number representing 400 rpm increments. A fraction is also returned
>This worked on a running motor. Yes the overflow is tacky but is only
>envoked when you do the switchover from start mode to runmode and
>the engine revs between these two modes. (depending on divisors)
>Am curious did you find any conflicts between the interrupts.
>I ended up using RTI at a 160 rate for most of the calcs and
>the input capture. More interrupts more often then not scrambled
>everything which in a running motor could be exciting.
>Very interested in all efi software cliff. If you can't post it send
>it to me direct at pfenske at direct.ca
Tnx much: peter