Accurate timing under rapidly changing RPM? Algorithm Q
Read the manual to see if your question is answered there before posting. Many users will not reply if the answer is already available in the manual.
If your question is about troubleshooting, configuration, or tuning, you MUST include your processor type (MS-I or MS-II) and code version in your post. If your question is about PCB assembly or modifications, you must also include the main board version number (1.01, 2.2 or 3.0). For tuning/troubleshooting questions, please attached a datalog and your MSQ file to your post.
If you have questions about MS1/Extra or MS2/Extra code configuration or tuning, please post them at www.msextra.com Such questions posted here will be moved to: a temporary MSextra sub-forum, where they will be removed after 7 days
The full forum rules are here: Forum Rules, be sure to read them all regularly.
Accurate timing under rapidly changing RPM? Algorithm Q
I haven't determined how exactly MSII determines when to fire spark but from a programming point of view, there are at least two ways to do it.
One is to measure RPM and rate of change of RPM and set an Output Compare timer for the necessary dwell and advance and then let it execute independent of the CPU. This is a predictive "fire and forget" method that, under steady-state conditions, will be perfectly accurate. If things are changing, such as rapid acceleration or deceleration, there will be some error.
Another approach is to set the output compare as before but at the last crank tooth encountered before spark, re-compute advance and adjust the value in the Output Compare timer. This, in theory, would provide more accurate timing, given that it was updated as late as possible.
What method does MSII use? The first is simpler, akin to how injectors are fired. Given that the input used in the first method is only one revolution "old", is timing plenty accurate? Am I over-thinking this?
Thanks!
-
- Super Squirter
- Posts: 2951
- Joined: Sat Jul 03, 2004 11:35 am
Re: Accurate timing under rapidly changing RPM? Algorithm Q
Thanks, this does help.
Is the source code for this section available or is it proprietary? I understand what it's doing from the link you sent, in that it counts physical teeth to get as close as possible to the firing point and then estimates only the last portion prior to the next physical tooth. What I'd like to determine is how it is implemented with the output compare modules. My guess is that it sets up the output compare for a delayed start (thereby estimating the point at which to start charging the coil), puts in a spark time and updates this spark time as it gets to the last tooth. Would be nice to see the details.
Regards,
Adnan