[jonbill]

Maybe your wheel isn't machined 100% accurate, or maybe speeduino ignition schedule calcs vary a little with trigger angle (I don't know). But given you set the trigger angle empirically, there's no practical problem, right?

[miker]

I've had a quick look and couldn't see, do you have per tooth timing enabled? What happens if you disable it (or enable of not already enabled)

Where's it's the -1 in relation to the angles you quote, eg it's the -1 at 170 degrees, 50 degrees or 300 degrees?

[metcap]

I've new ignition mode enabled, it was scattering quite a bit without new mode enabled. Sorry I didn't understand your second question.

[miker]

You have a trigger wheel that is 12-1. In this thread your reference 0 degrees and 180 degrees. I'm asking where in relation to the 0 degrees is the -1 (the gap) in the trigger wheel?

As you haven't got the paid version of tuber studio we can't be sure you've got the polarity of the writing correct. Have you tried switching the wires round (honestly don't think this is a problem as I'd expect 0 degrees and 180 degrees to show the same issue unless it's related to where the missing tooth is and you have that at 0 or 180 degrees)

[PSIG]

…we can't be sure you've got the polarity of the writing correct. Have you tried switching the wires round …

If (big if) the probing was correct for the o-scope images, then polarity would appear correct. However, more data should appear if the polarity is reversed, both to prove it, and to gain insight for the reversal effects, IMO.

[metcap]

Vr sensor polarity was checked using the analog meter method. I think I mentioned my tooth reference in post #66157, is it what you're asking?

However, more data should appear if the polarity is reversed, both to prove it, and to gain insight for the reversal effects, IMO.

You guys are giving me heaps of homework

[metcap]

Maybe your wheel isn't machined 100% accurate

Ok first off I just wanna say jonbill was right with this. Thinking about what he said I did a scope of the trigger signal and measured each of the tooth trigger edge referenced to tooth#1. With my 12-1 wheel each tooth trigger edge should come out at 5ms, meaning referenced from #1 then tooth #2 (30deg) should be 5ms, #3 (60deg) 10ms....#7 (180deg) 30ms.

As you can see my trigger wheel has some variation and coincidently #7 is measured at 30.20ms and that equates 200us of error.
Since I was seeing somewhere around 280us delay previously so most of this delay was from my trigger wheel and the remainder seems is from Speeduino and downstream setup. I broke out my ardustim and fed the trigger signal (should be perfect signal) into Speeduino and found some of the delay within Speeduino(measured about 40us) and some from Speeduino to my spark plug totalled 60us.



60us seems insignificant but 60us at 5k rpm is 1.8deg. Ya I know many have replied that we're working with relative values here and we just need to focus on getting the power at the correct timing whatever the numbers should fall at. I've no problem with that but I just think with so many users with countless setups, cumulative delays will add up and if Speeduino has a setting for ignition latency compensation it'd benefit many.
Right, I think thats all I have for this thread. Thanks all for many helpful inputs.

[JHolland]

At low RPM your engine will accelerate and decelerate as it goes through the cycles so that isn't a very accurate way of measuring it.

[PSIG]

Perhaps this is an opportunity to see a new feature that could be helpful as a troubleshooter diagnostic.

A feature that could calculate the current internal lag/latency, and representative error in crank degrees expected, for a baseline value. This could be compared to actual results, allowing the user to instantly determine if lag is inside our outside (input/output) of the ECM.

In this user's case, let's say it reports a log graph that reaches 1.8° error at 5000 rpm. The timing light check should confirm this. No worries. But, if the lag is greater, the user knows to seek either input issues, or output issues, or both. It would simply be an indicator of external or compounded issues that may need attention, such as the OP's tooth error and coil driver lag. It could also avoid the requirement of an oscilloscope unless greater error is found with the timing light.

Thoughts?

[EDIT] As we don't like to add bloat to the code (even "good" bloat), another option is to create a sketch to run on a second Arduino, specifically for this task, or as part of a sim program. Load the code on an Uno or something, connect jumpers to Points A, B, and C, and run the sketch. Output could be to serial as a simple degree-at-rpm value, TS, MLV or the Arduino IDE Serial Plotter for a graph. Hmm.

[metcap]

At low RPM your engine will accelerate and decelerate as it goes through the cycles so that isn't a very accurate way of measuring it.

Tests were done on bench with a trigger wheel mounted on a 775 motor running fixed rpm.

[EDIT] As we don't like to add bloat to the code (even "good" bloat), another option is to create a sketch to run on a second Arduino, specifically for this task, or as part of a sim program. Load the code on an Uno or something, connect jumpers to Points A, B, and C, and run the sketch. Output could be to serial as a simple degree-at-rpm value, TS, MLV or the Arduino IDE Serial Plotter for a graph. Hmm.

Good idea, integration into the existing ardustim architecture is a good feature since there's already an arduino doing very minor duty. Knowing total delay in your system/setup helps troubleshooting.