Let's think about this for a minute. As an example, let's use an extreme situation where I'm hovering an aircraft with the engine turning around 5000 RPM. When I advance the throttle to pull out of the hover I surely don't want the engine to stumble or quit. Now let's assume that the software requires 2 revolutions to correctly measure the engine RPM in order for the ignition timing to follow accordingly. At 5000 RPM this requires 24 milliseconds. Even digital servos will not respond that fast, plus you have to factor in the time lag for the fuel/air mixture to adjust.

If I understand the proposed algorithm correctly, sensor position only matters for ease of starting the engine. Thereafter the software will determine the instantaneous RPM (dR/dt)every revolution based on the interval between pulses and adjust the timing accordingly. This is why we use a micro-processor in this application.

IF this is the case then I don't see the need to program in any delays when starting the engine. We simply position the sensor to fire the plug at 28-30 degrees BTC. This is a good start position to eliminate kick=back but not the best position for optimum RPM. As we advance the throttle and increase RPM's the microprocessor will automatically advance the timing based on the table of values (curve) programmed in. Prior to starting, the processor calculates an RPM of zero. Once the engine fires the RPM will increase and timing will adjust each revolution. You can hold the timing at the start position until the processor sees a minimum RPM value (e.g. 500). Sparky you may need software filters as well as hardware to filter the measured interval. Noise will be a killer! You may also have to integrate the RPM calculation over an interval to come up with an average value to alleviate the noise issue.

I think SparkyGSX is on the right track here and the programming does not have to be overly complicated- but then again I may be mis-understanding his proposed algorithm entirely!

AlZ