Speeduino is now on Github Sponsors (Rather than Patreon): https://github.com/sponsors/noisymime
Any general discussion around the firmware, what is does, how it does it etc.
By 241e668100
#50100
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.
By theonewithin
#50106
No images attached...

60 teeth is a bit much for the mega. It has a limit on how many teeth it can process. You will find that limit somewhere (7khz i think?) so running the 60 teeth that high is not going to work well with the Mega.

36-2 is the best to go with and if your pot can't give a steady RPM, why not just enter a value manually?

Or can that not be done anymore?

Oh and nothing has been attached to your post...
By JHolland
#50107
I've seen similar results on a Mega based Speeduino, mostly 4us or less but with outliers at up to 95us. its inevitable because of the way that Speeduino schedules the ignition - nothing much can be done about it because the Arduino Mega doesn't bring the Output Compare pins out so you can't drive them directly from the timer. From what I've seen of Ardustim it uses the same scheduling method so you are likely to get some scatter from that as well so overall it may not be quite so bad as it looks although the Ardustim processor should be less busy which will reduce the scatter.
I wouldn't consider 4us to be good, even an old 80s OEM ECU can mange 1us, I understood that there had been code changes, fairly recently, that improved the resolution.
By pazi88
#50108
If you use teensy or stm32, you will get significantly better results ;) Also there is big difference between new and old ignition modes. There is still "issue" that the calculation is accurate within 1 degree. But GitHub already has PR improving that.
User avatar
By Chris Wolfson
#50120
I'm not the type of guy who personally knows any byte that runs through a processor. Nevertheless I have a good idea what it does and how it affects my work.
I once talked to a guy who really knew something of the "inside the code" that ran the Weber Marelli IAW Motronic's ( roughly used 1984-1996) because he worked there. This ECU uses only 4+1 notches at the crank plus one at the cam.
He told me that the biggest problem was to use these few dynamic (changing with rpm) signals and generate an output timing better than 1° for the ignition. Ignition timing was highly important for reliability with turbocharged engines. He said it was a very unique solution at the end, as it ran on only a 128kB EPROM and a Motorola Prozessor. This ECU picked 6 rally world championships an is used on some iconic cars. The last version had 256kB EPROM and Euro 2 emissions.

So the problem is nothing new.
By JHolland
#50123
The issue of calculating accurate timing with a low resolution trigger is quite different, that just adds more inaccuracy. If you run the scope with the persistence set to 100% its easier to see the scatter and the density of scatter, its mostly around 4us, fading out up to around 20us and then less frequent out to the occasional hit at 90us or more.
The way a conventional ECU works is to use the a hardware timer function (output compare) to toggle the pin when the timer reaches a specific value so the accuracy is whatever the resolution of the timer is. Similarly measuring an input is done with an input capture channel which saves the timer value when the input changes, again the accuracy is whatever the timer resolution is.
Because the Arduino mega doesn't bring out the right pins to the connector the way that Speeduino works is that it generates an interrupt when it sees a cam or crank pin change and then reads the system timer or when the timer reaches the value that an output should change at and then it sets or clears a pin. The problem with that approach is that if there is already an interrupt in progress then the code execution is delayed and the ignition channels have the lowest priority. With other Arduino projects that I have done I have found that the system timer causes the most timing problems because it interrupts around every 1ms, disabling it or moving it to a 16-bit timer reduces the issue considerably.
The 4us comes from the timer being set up to allow a 720 degree cycle, which older ECUs did not support, that became more of a thing when engine 20 and 24-bit engine control timers became the norm. They usually run 0.1 degs/1us resolution.
If you were to make a board with the processor mounted directly on it then you could move cam/crank and the ignition and injector outputs so you could then rewrite the software to use input capture/output compare with the timers synchronized; you could even even software extend the timers to get a higher resolution. I did some work on this but ultimately the ATMega processor is very expensive for its limited capabilities so I just moved to a different processor, its a bit mad that, in low volumes, a Mega2560 processor costs more than an Arduino 2560 complete.
User avatar
By Chris Wolfson
#50124
Maybe someone can give me an answer. I ask my self if a Teensy with included DSP could not be the future of Speeduino. The DSP could be used to integrate detonation detection without external hardware. It's processing power should leave the Mega behind. At least it does not seem more expensive. Is there a mistake in this idea? Also Arduino is quite old now. Too old?
Teensy seems to have CAN bus too.
User avatar
By Chris Wolfson
#50128
I know that some use it, but it seems experimental to me.
My primary thought is the DSP to filter the engine noise, found nothing about it. Also, just using a faster CPU without really taking advantage of maybe 100x more processing power is not satisfying if the Mega powered Speeduino suffers from speed problems.
I have decided to quit programming at a time many of you writing here where not even born. (someone know programmable calculators, Casio? Sharp? Basic?) So I can not do it by my self, but maybe give others some ideas.
By theonewithin
#50130
You are making a pretty interesting assumption there on people's age...

The teensy is not experimental. It is what will be running the Dropbear.

If anything the STM is the unofficial "experimental" side of things.
Auto Transmission Controller

That looks interesting. What trans have you te[…]

What is controlling the coil? are you driving it d[…]

IAT and A0 with trimpot

Got it, thanks

Setting crank trigger up

Your phone is not so good, or the blurring is from[…]

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