Chris Eddy wrote:

> Ah, I don't think that this will work, since my third case of trouble is with
> more than one pulse per spark event.  In this case, my target period of X may
> be split up into x/20 and 19x/20 at most every event.  Instead of one strong
> instance of X readings, I would get equal cases of x/20 and 19x/20.  And thus
> could not choose the right frequency.  Simply add them together?  Well, I am
> not sure that this is going to work under all circumstances.

I prefer uncomplicated solutions. Here's one you could try :

Treat the pulse stream as a simple input. Use an up/down
counter type debouncing routine. Use the current period
between pulses (minus a little bit) as the debounce period.
Your software will only pick up pulses in the 'expected'
window, effectively eliminating noise and double pulses.

I used this technique for bit detection in an rf receiver
where the pulse train length was dependant on the battery
condition of the transmitter.

--
Friendly Regards

Tjaart van der Walt
mailto:tjaart@wasp.co.za

|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
|SMS mailto: tjaart@sms.wasp.co.za  (160 chars max)|
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|