Crank Angle Sensor resolution - Re: Old 486 ..

[John S. Gwynne]

   In message <890B12B8398AD211BC6100805FA784A2064BB529 at es04snlnt.sandia.gov>, 
you write:
 
| This is very helpful.  Let me ask a few questions to make sure I understand.
| (6inch skull syndrome)
| 
| For every rpm range, you use an appropriate frequency to run a counter.
| 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.
| 
| This relies on the ability of the timer to change frequency as quickly as
| the motor can cycle through each of the rpm bands.  Is this a reliable
| assumption?  If not, then this system might drift or miss a crank angle
| position.  We also assume that we can measure rpm and make it available to
| the system before it changes noticeably.  True?  Finally, deciding what
| frequency is needed to run the counter at each rpm range can be tedious.  Am
| I missing something here?


I have not closely followed this discussion, but I would like to add
that this is the beauty of using the mc68332 for engine
management. The 332's TPU is an semi-autonomous microcontroller that
can perform these timing tasks without any CPU intervention and with
some degree of error checking for noise on the crank sensor
signal. The TPU will track RPM and appropriately trigger
spark/injector events. For example, to fire a spark, one supplies the
dwell time and the event angle. The TPU will do the rest without CPU
intervention. It will track PRM and interpolate position as
needed. In the case of a 60-toothed position sensor wheel (there are
two wheels under consideration for the efi332 project, I developed the
60-2 wheel approach so I'm biased on this topic), the TPU captures the
time of each tooth on the wheel (actually the gap), and then
recalculates timing values. There are documents somewhere on our
web/ftp site if you would like to know more. IMHO, it would be
difficult to duplicate this type of functionality in a pc
environment (though it maybe overkill depending on what you are trying 
to do)... it _may_ be easiest to interface the "Old 486" to a 68332
just for it's TPU functionality... 

john gwynne
----------------------------------------------------------------------------
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