Any general discussion around the firmware, what is does, how it does it etc.
By noisymime
#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
Image

Worst result
Image

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):
Image

Typical result:
Image

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.
By Ned
#2955
I'm guessing i'm one of the guilty parties of talking about timing accuracy not being up to scratch (all documentation i found said it was far worse than it actually is BTW)
Either way, i'm super happy you sat down and had a look at what the system was like, and the numbers are actually pretty decent. Nothing to complain about at all for the application at hand if you ask me. I'm being converted more and more as each day goes by ;)
By noisymime
#2956
Hey Ned... You may have been involved in the thread I was looking at :lol:

All good though and I welcome any scepticism! As far as I recall, I made that 100uS comment in the talk 2+ years ago (And it was accurate when I said it), but I don't think it's still mentioned anywhere on the site at all. If it is I will definitely get it changed! :D

Great to have you on board!
User avatar
By KaxLon
#2967
Thanks for taking the time to do this post Josh. I think the timing is right on par with OEM ECU's, if not better than some too.

I will do a similar scoping of some ECU's when I get a multi channel oscilloscope. I'm leaning towards a Hantek 1008C at the moment as it fits my tight budget.
The ECU's I have at hand is Mitsubishi so-called 1G ECU that were in the pre-EVO era cars. Good old HC11 based ECU. The other one is a MS2 v3 ECU.
I will post up the results once they are in. It will be a while before that happens though.
User avatar
By DavidAndruczyk
#4297
I'm most interested in timing lag/error during RPM TRANSITION, i.e. not necessarily at steady state, but while the engine is accelerating or decelerating. i.e. motorcycle engines can go from 1000 RPM to 10,000 RPM in well under a second (revving in neutral), some much faster than that, does the timing advance hold true during this or does it lead/lag depending on the rate of change and slope (increasing or descreasing), and if so, how bad is the effect ?

How about during cranking? (very low RPM), where the potential for timer overflow is much higher, does the firmware handle this gracefully? I don't want sporadic sparks way over advanced kicking my con-rods to pieces... (megasquirt has done this to some people)
By klotzy_550
#4349
For benchmark, the Bosch OEM grade ECU's that I use at work have an injection and Ignition timing accuracy of 0.75°
By noisymime
#4351
klotzy_550 wrote:For benchmark, the Bosch OEM grade ECU's that I use at work have an injection and Ignition timing accuracy of 0.75°
At what rpm though? The timing error is typically a fixed period of time, so 0.75 degrees at 1000 rpm is very different from 0.75 degrees at say 14,000 rpm

I'll hopefully get some time over the break to look at how the accuracy looks under acceleration.
David you're without a doubt the man when it comes to Ardustim. Does its sweep function reflect the kind of acceleration you're talking about or does it need to be less linear?
By klotzy_550
#4405
noisymime wrote:
klotzy_550 wrote:For benchmark, the Bosch OEM grade ECU's that I use at work have an injection and Ignition timing accuracy of 0.75°
At what rpm though? The timing error is typically a fixed period of time, so 0.75 degrees at 1000 rpm is very different from 0.75 degrees at say 14,000 rpm

I'll hopefully get some time over the break to look at how the accuracy looks under acceleration.
David you're without a doubt the man when it comes to Ardustim. Does its sweep function reflect the kind of acceleration you're talking about or does it need to be less linear?
Confirmed today, 0.75deg at 12000rpm.
By tausday
#13615
Hy,

thanks 4 u're test.
I have read carfully that u write top Line is ignition and bottom Line is Crank Sensor.
I'm right that u set up ignition to 0 degrees so that Crank and Ignition should start at the same time?

If i right interpret the diagramm the ignition comes to early and not to late? right? Or have i see Someting wrong?
Is thats true and u have a hard ignition Map that can knock sometimes all right?

By the way what Hantek do u use?
202402 firmware and Realdash

Hello to everyone. I have a 0.4.3c board and recen[…]

That PCB design wouldn't pass the design rules for[…]

Suzuki RE-5 EFI Conversion

Hello again, Added some voltage corrections to in[…]

Tach output and RPM sensor issues

Small update. I just came back and unsurprisingly[…]

Still can't find what you're looking for?