Crank Angle Sensor resolution - Re: Old 486 ..

[Diehl, Jeffrey]

Actually, this was my first thought on the topic, but I had some questions
that bothered me... Here goes.

If the clock frequency stays constant and the RPM ranges are all the same
size throughout the power band, the number of clock counts per flywheel
event will change with RPM.  However, if this counter value is used to
access a memory to look up, lets say, ignition timing, then we will waste
much of the memory space because the counter will skip many of the
locations.  That is, while the output of this logic will be linear, it will
also have holes in it.  I was hoping to not have to deal with this
situation.  That is why I proposed the (inferior) system below.

I'll bet there is a better way.  Suggestions?

Mike Diehl,
MR-2, '87na

-----Original Message-----
From: Peter Gargano [mailto:peter at ntserver.techedge.com.au]
Sent: May 08, 2000 3:41 PM
To: diy_efi at diy-efi.org
Subject: Re: Crank Angle Sensor resolution - Re: Old 486 ..


Diehl, Jeffrey wrote:

> For every rpm range, you use an appropriate frequency to run a counter.

No! In practice, you'd use a counter of appropriate width (8, 10, 12, 16, 
24 - whatever) bits that's clocked at a fixed frequency to give you the
required 
resolution at the highest RPM you expect. The counter's width defines a
minimum
RPM at which things work (eg. for 4 uSec counter, to timer over a 250 mSec
period, you need to count to 250,000/4 = 62,500 => width of 16 bits. A
250 mSec period may correspond to 4 events/Sec or for a 4 cylinder, say 
2 revs/Sec = 120 RPM, a not unreasonable speed to expect to be able to
generate a reliable spark count).

> This counter is started by an event from the cam/flywheel sensor.  So, you
> know which tooth triggered the event.  You know that the given frequency
> will divide the event into N intervals.  So, you can develop positioning
to
> any desired resolution.

Yes!

Without trying to confuse you, the (hardware) counter does not really need
to be 
as wide as I calculated, as long as the software is prepared to do some of
the 
counting itself. For example, to time 1/4 sec with the above 4 uSec clock
rate, 
and using just an 8 bit counter, the software must be prepared to count the 
first 255 "overflows" of the 8 bit counter, and then set up the hardware
counter
to produce an output somewhere on the 256th count.

A micro like the 68HC11 has multiple 16 bit counter/timer registers that can
be 
set to clock at 4 uSec, and produce an output pulse at a future time - These
are
called "output compare" events. The corresponding input side of things is
called
an "input capture" regsister, and can be setup to capture the system's 16
bit
counter whenever an input event occurs. So, to produce an output pulse at a
future
time, with an accuracy of 4 uSec, the micro just waits for the input capture
event
(notified via an interrupt), adds the number of 4 uSec periods required, and
then
plugs this value into the output compare register. The hardware does the
rest. 

Peter
----------------------------------------------------------------------------
To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org

----------------------------------------------------------------------------
To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org