- Tue Dec 03, 2019 9:09 pm
Speeduino does not function like the OEM ignition system, which has only one job. I see the biggest problems being three issues, one is processor response, where it sees the trigger signal on an interrupt, but must then calculate timing from that point to the calculated firing point. This means a delay where it cannot fire any quicker than x-microseconds after the trigger, and so the inability to use the full range of timing to full advance (trigger point).
The second issue being the current rpm, which is calculated off the last known time-for-rev. Due to the speed of accelerations, rpm will be different on the very next crankshaft revolution, but the timing is based on the last revolution time, as it only has one tooth/signal. Finally the last issue (that I can think of offhand) is transitional error, due to a combination of issues 1 and 2. Speeduino already has transitional timing errors, even when it has lots of teeth for predicting crank angle. The situation would typically be worse with only the last full revolution available for timing calculations.
If a co-processor were used, it could certainly perform as well as the factory system, but then it should share data between Speeduino ECM (for timing calculations) and the ignition controller/ECU (for firing solutions). We have been discussing how to structure the addition of added "smart" feature controllers on Slack recently, and this ignition controller could be an example of that.
-= If it was easy, everyone would do it =-