Hi-resolution Crank angle sensor

[dn]

> >Not necessary. Add one sensor instead.
> >
> >
> >  *     x
> >  _   _   _   _   _   _
> >_/ \_/ \_/ \_/ \_/ \_/ \_

Peter Wales wrote:

> This doesn't make sense. For every peak there will be a trough and each
> sensor will detect the same thing.

Ah, but the key is in the phase difference between the two sensors.  This 
will only work if the tooth is asymmetrical, ie the peak is much narrower 
than the trough.  Assuming that this is the case, sensor waveforms will 
appear like this:
                 _       _       _       _
Sensor A   _____| |_____| |_____| |_____| |_____
             _       _       _       _       _
Sensor B   _| |_____| |_____| |_____| |_____| |__
             _   _   _   _   _   _   _   _   _
 A + B     _| |_| |_| |_| |_| |_| |_| |_| |_| |__   (logical OR of the two)

Voila, double the output frequency.  This is very similar to the system used
in optical encoders, but in the encoder the two waveforms (A and B) must be 
50 % duty cycle, and separated by a phase difference of 90 degrees.  It is 
then possible to discern rotational velocity, relative position, and 
direction by determining whether A or B occurs first.  Of course, you are 
not interested in direction, if the engine starts turning backwards you've 
got other problems :)

This brings up an interesting point... Hewlett Packard makes a chip 
specifically for reading optical encoders, which may work great with this 
type of system.  Assuming you can get the 50% duty cycle waveforms as 
mentioned above, (you could have some sort of sensitivity adjustment on
the sensors so it picks up the tooth halfway up and down each ramp) the
chip takes care of the quadrature decoding and has a built in 16 bit counter
which will totalize pulses until you read it.  As an added bonus, it 
multiplies the resolution of the system by 4 because it counts each rising
and falling edge from each sensor.  Thus, on your 150 tooth ring gear,
you could get 600 pulses per revolution, and eliminate interrupting your
processor for each tooth and save a lot of software overhead.  Just read
it on a fixed time basis, and the CPU could easily calculate rotational
velocity based on the number of pulses per unit time, and position based
on the number of counts.  

You cannot, however, determine absolute position based on this approach, 
so you would have to have a third sensor which would interrupt the processor 
once per revolution to keep things synched up.  It should be easy to predict 
when the next spark event will occur by calculating the difference between
the latest count and the previous count.

The chip I am referring to is the HCTL2000 (newer version is the HCTL2016)
and is around 15$.  I have used these in a position sensing application and
they are a piece of cake to interface to.  You'd only have to read it once
per second and you'd be able to keep up with about 6500 RPM.  Of course,
you'd want to read it a lot more often to keep up with things, but it 
would take a big load off the processor in any case. 

regards
dn



--
---------------------------------------------------------------------
 Darrell A. Norquay              Internet: dn at dlogtech.cuc.ab.ca     
 Datalog Technology Inc.         Bang: calgary!debug!dlogtech!darrell
 Calgary, Alberta, Canada        Voice: +1 (403) 243-2220            
                                 Fax:   +1 (403) 243-2872            
    @ +                                                                
     <                                                         
    __/    "Absolutum Obsoletum" - If it works, it's obsolete    
 --------------------------------------------------------------------