- Fri Oct 30, 2015 5:02 am
#2954
Long post warning....
OK, so I saw an interesting discussion around timing accuracy as it potentially related to Speeduino and it got me thinking. I'd never sat down and done any end to end timing accuracy testing, that is a crank signal + Speeduino + ignition circuit. The way the scheduler code is written means that the timers are accurate to 4uS, which is a good figure, however all it means is that the start/end of the pulses will be within 4uS of the time that the firmware requests it to be. That doesn't take into account the Speeduinos ability to process the incoming signal and calculate an accurate target angle, nor does it take into account the switching speed of the circuit.
So, I decided to sit down and do some testing. I hooked up a v0.4 board with Ardustim feeding it a 24-1 crank signal with a fixed timing angle that would correspond with a tooth edge based on the trigger angle I set. RPM was turned up to 13,000. On the whole the timing scatter was more than I expected and so is something I will work on, but for all real world requirements for this type of project I think its quite good.
The maximum observed error was around 44uS with the typical error being 12uS. At this speed, that equates to around 3.5 degrees and 1 degree respectively.
At this point I changed the stim over to a 60-2 pattern and ran it back up again, this time to about 13,800 rpm (My rpm pot wasn't particularly accurate, getting the same value was tricky). The maximum observed error was similar (Around 40uS) but it was noticeable that this was occurring less frequently and there were a much greater number of high accuracy results (<=4uS). The images below show some of the results. top line is ignition signal, bottom line is the 60-2 signal (Tooth #1). A perfect result is when the ignition signal is falling when the tooth #1 is rising.
Best result
Worst result
Alright, so that represents the top end of the scale at speeds that are only going to be achievable on some sports bikes. Reducing things down to more common car speeds, I repeated the above 60-2 test at about 6900 rpm. The typical error was now around the 8uS - 12uS mark with the maximum value observed being 32uS. 0uS and 4uS errors were also much more frequent at this speed. Importantly now though, the maximum error of 32uS represents a lower 1.3 degrees and the typical error is less than 0.5 degrees. A few images below of this test (Note the lower frequency value)
Worst result (Edge on the bottom line is right over the left hand side):
Typical result:
Some interesting notes... The keen eyed amongst you will notice that virtually all the error values about come out to be a multiple of 4. This is no coincidence as 4uS is the step value of the timer being used. The fact that the values are all multiples of 4 means that the timer itself is working very accurately (As you'd expect) but that the limitations are in the firmwares ability to accurately measure/predict both the crank angle and speed.
So, make of all that what you will. The results (in my opinion) are neither amazingly awesome, nor are they particularly bad. I will continue to work to improve the timing accuracy, but I think these results demonstrate that the system has enough precision for the typical target user of Speeduino. It is at least as accurate as a good points style ignition and considerably better than most. It is also better than many low resolution OEM OEM configurations. I make no comments about how it compares to other aftermarket ECUs, I can only hope any testing this is compared to is as thorough and as honest. If you require more accuracy than this, please feel free to chip in and suggest areas of improvement, but otherwise I'd suggest the project may not be for you.
Edit:
I meant to mention, there is an amount of fixed delay in the switching that has been taken into account in the above numbers. This comes both from the arduinos switching time and the MOSFET driver itself. I don't consider this to be a major problem however as it is a constant at any given speed and so is not something that leads to variation. Once your ignition map is setup to where your happy, you will get consistent results (Subject to the errors mentioned above), the fixed switching time will not impact you. The only possible time this may possibly make a difference is if you're trying to copy over an existing ignition map from another ECU system, but I'd suggest that this is probably the case between any 2 different ECUs.
OK, so I saw an interesting discussion around timing accuracy as it potentially related to Speeduino and it got me thinking. I'd never sat down and done any end to end timing accuracy testing, that is a crank signal + Speeduino + ignition circuit. The way the scheduler code is written means that the timers are accurate to 4uS, which is a good figure, however all it means is that the start/end of the pulses will be within 4uS of the time that the firmware requests it to be. That doesn't take into account the Speeduinos ability to process the incoming signal and calculate an accurate target angle, nor does it take into account the switching speed of the circuit.
So, I decided to sit down and do some testing. I hooked up a v0.4 board with Ardustim feeding it a 24-1 crank signal with a fixed timing angle that would correspond with a tooth edge based on the trigger angle I set. RPM was turned up to 13,000. On the whole the timing scatter was more than I expected and so is something I will work on, but for all real world requirements for this type of project I think its quite good.
The maximum observed error was around 44uS with the typical error being 12uS. At this speed, that equates to around 3.5 degrees and 1 degree respectively.
At this point I changed the stim over to a 60-2 pattern and ran it back up again, this time to about 13,800 rpm (My rpm pot wasn't particularly accurate, getting the same value was tricky). The maximum observed error was similar (Around 40uS) but it was noticeable that this was occurring less frequently and there were a much greater number of high accuracy results (<=4uS). The images below show some of the results. top line is ignition signal, bottom line is the 60-2 signal (Tooth #1). A perfect result is when the ignition signal is falling when the tooth #1 is rising.
Best result
Worst result
Alright, so that represents the top end of the scale at speeds that are only going to be achievable on some sports bikes. Reducing things down to more common car speeds, I repeated the above 60-2 test at about 6900 rpm. The typical error was now around the 8uS - 12uS mark with the maximum value observed being 32uS. 0uS and 4uS errors were also much more frequent at this speed. Importantly now though, the maximum error of 32uS represents a lower 1.3 degrees and the typical error is less than 0.5 degrees. A few images below of this test (Note the lower frequency value)
Worst result (Edge on the bottom line is right over the left hand side):
Typical result:
Some interesting notes... The keen eyed amongst you will notice that virtually all the error values about come out to be a multiple of 4. This is no coincidence as 4uS is the step value of the timer being used. The fact that the values are all multiples of 4 means that the timer itself is working very accurately (As you'd expect) but that the limitations are in the firmwares ability to accurately measure/predict both the crank angle and speed.
So, make of all that what you will. The results (in my opinion) are neither amazingly awesome, nor are they particularly bad. I will continue to work to improve the timing accuracy, but I think these results demonstrate that the system has enough precision for the typical target user of Speeduino. It is at least as accurate as a good points style ignition and considerably better than most. It is also better than many low resolution OEM OEM configurations. I make no comments about how it compares to other aftermarket ECUs, I can only hope any testing this is compared to is as thorough and as honest. If you require more accuracy than this, please feel free to chip in and suggest areas of improvement, but otherwise I'd suggest the project may not be for you.
Edit:
I meant to mention, there is an amount of fixed delay in the switching that has been taken into account in the above numbers. This comes both from the arduinos switching time and the MOSFET driver itself. I don't consider this to be a major problem however as it is a constant at any given speed and so is not something that leads to variation. Once your ignition map is setup to where your happy, you will get consistent results (Subject to the errors mentioned above), the fixed switching time will not impact you. The only possible time this may possibly make a difference is if you're trying to copy over an existing ignition map from another ECU system, but I'd suggest that this is probably the case between any 2 different ECUs.