Timing lag?

[Haudi]

So I was out to dinner the other night with some guys I know that work for a high end standalone/aftermarket EFI company. The conversation inevitably progressed to "our stuff is better than MS" and "ms is ok on the street and has it's purpose in life, but anybody who runs it on a high stress race car is an idiot". I listened politely and explained that based on my 10 MS installs I must just get different results than thier testing. We all agreed that we are all heavily biased and moved on to topics that brought back our smiles ;-).

Ok, the meat. They told me that the #1 problem is that the ignition timing algorithms can not keep up with rapidly changing RPM and can be off by multiple degrees for short periods of time. I'd like to conduct some tests of my own at some point. Until then, has anybody tested this with a decent level of accuracy? They claim thier system to be accurate to 1/4th of a degree ALWAYS with no chance of it wavering. I'm thinking the easiest way to test is a scope on the crank trigger wheel and the secondary of the #1 coil. I can then lock the timing at whatever and do whatever need be to change RPM as quickly as possible and see if it wavers. I can't see any reason why testing this on the stim wouldn't give the exact same results as on a car, but on the stim you can obviously change RPM much faster. Trouble is that I only have an old school stim so I can't check the MS3X setup I've got and my MS1X setup doesn't use a DB25 anymore so I can't use that either.

[prof315]

Well while I've never measured the timing under load I can tell you this. We have campaigned an SCCA GTLite car running MS for the last 3 years. Just finally did a teardown to the 14 to 1 motor that turns about 7500 rpm(after 3 seasons of racing so about 175 hours total) and other than a worn set of valve springs we could have left things alone. If there had been any kind of timing issues the bearings would have been worn to the shell, been there done that with dizzy fired race cars. Sounds like product jealousy to me.

[GintsK]

I think statement about timing instability is true regarding MS1. Later MS2 and MS3 should be much more precise when used together with multitooth wheels: then timing is calculated from last possible tooth.
Anyway guys are right in some aspect. For engines where thousands of $$$ are spent it is wise to chose management of same level. Usually high end systems have much more functions to protect high budget stuff.
I still offer even MS1 for race. But for durable engines with no deep modifications. Like you have engine tuned with $500 spent - here is system for it.
Once such engine is knock limited, then better to chose more precise MS2 or MS3. But if knock can lead to high $$$ loses, let the owner to choose somewhat more advanced

Gints

[VolvoGuy50]

MS1 isn't very accurate compared to MS2 or MS3, so maybe he was referring to MS1's specs. MS3 has a within 0.1 degrees of timing accuracy, which is on-par with any of it's competitors. There are many people I know who run MS2 or MS3 in their street cars that have $7K built motors, likewise, there are others like myself who run MS3 on motors with 193K miles.

[muythaibxr]

The guys claiming that timing is always accurate to 1/4th degree don't have a clue. Engine speed can change between teeth; there is no way around that. There is no algorithm that 100% all the time has the exact commanded timing. If the engine speed changes between teeth, the timing can and will be off. Even prediction algorithms require tuning (like alpha beta gamma) and are at best helpful but not perfect.

The MS algorithm is at least as good as what "the big guys" use; we use every tooth and that is more or less the best you can do.

Ken

[Benkku]

The guys claiming that timing is always accurate to 1/4th degree don't have a clue. Engine speed can change between teeth; there is no way around that. There is no algorithm that 100% all the time has the exact commanded timing. If the engine speed changes between teeth, the timing can and will be off. Even prediction algorithms require tuning (like alpha beta gamma) and are at best helpful but not perfect.

The MS algorithm is at least as good as what "the big guys" use; we use every tooth and that is more or less the best you can do.

Ken

Don't agree. Ignition timing could be much more accurate in fast angular speed changing situations, if timing 'done right'. For example - newer Motorola cpu's has ETPU unit which handles timing quite nicely - if done right. Likewise algorithm implementations and usage of capture/compare unit versus general interrupts does greatly matter. Don't know what you mean by big guys, but 'really big' guys (Bosch, Magneti Marelli etc.) has definitely done this right - no such an large algorithm nor implementation specific jitter.

Here is one measurement which is way out of 0.1 degree 'spec', altought not necessarily related to MS3 but MS2 Extra.
http://forum.diyefi.org/viewtopic.php?f=6&t=857

Likewise using next cylinder mode, is one sure way, to throw timing 'out of window'.

[muythaibxr]

Even the eTPU "angle clock" method will have a bit of lag between teeth. The only way to help there is with prediction. That is why you see wheels with 36, 60, or more teeth.

We will be implementing an angle clock on ms3, and even then I don't expect to see much difference in timing accuracy. We are doing it to save time on the main CPU mainly.

Also, quoting those guys with their blatent MS hating isn't very convincing and won't get you very far here. MS2/extra will have a bit of timing lag around the teeth because only 1 processor is handling spark and we multiplexed 4 outputs on 2 interrupts in software. That problem has nothing to do with timing during accel.

MS3 has the same algorithm except the outputs are all done on the XGATE, and on there, there isn't any lag around the teeth.

Ken

[Benkku]

I think that those measurements are 'genuine', technically vice 'no hating' there and it has not (nothing to do in changing angular speed), but those scope traces are from steady state - which is more worrying. It certainly not the reason for 'only one processor', but implementation. Ignition timing accuracy is the most important thing in ECU's, period.

Few degree ignition timing variation, is definitely catastrophic, especially in forced induction engines.

[racingmini_mtl]

Well since you seem convinced that this is 'genuine' and that you know the reason, you should just correct it and make everyone benefit from your superior knowledge.

[muythaibxr]

I think that those measurements are 'genuine', technically vice 'no hating' there and it has not (nothing to do in changing angular speed), but those scope traces are from steady state - which is more worrying. It certainly not the reason for 'only one processor', but implementation. Ignition timing accuracy is the most important thing in ECU's, period.

Few degree ignition timing variation, is definitely catastrophic, especially in forced induction engines.

OK, so how does a single processor running multiple interrupts run 2 things at the same time? The answer is that it does not. When MS2/extra's tooth processing algorithm runs, the spark interrupt cannot. Since we toggle the spark pins in software, they get delayed slightly. The only way around this would be to allow the spark interrupt to interrupt the tooth interrupt. This is not an algorithmic problem, it is a problem of having a high priority interrupt getting delayed by one of less priority. MS3 doesn't have this issue because the tooth interrupt is on a different processor from the spark output.

If you are going to criticize:
1) Enlighten us as to your great and powerful wisdom on solving the issue
2) Actually understand how single core processors work.
3) Yes, on boosted engines spark timing is critical. However the problem you refer to will never cause timing to be early (too far advanced). Instead it will cause timing to be *late* (slightly retarded). This will cause a very slight and brief loss in power as the advance crosses each tooth threshold. It is not dangerous to the engine, and in practice nobody has noticed in dyno testing.

Ken

[Matt Cramer]

Ok, the meat. They told me that the #1 problem is that the ignition timing algorithms can not keep up with rapidly changing RPM and can be off by multiple degrees for short periods of time. I'd like to conduct some tests of my own at some point. Until then, has anybody tested this with a decent level of accuracy? They claim thier system to be accurate to 1/4th of a degree ALWAYS with no chance of it wavering...

Was the system he was talking about Electromotive by any chance?

Because if the system doesn't absolutely require a high resolution crank trigger, there's no way they could guaranty that kind of accuracy. Imagine if you are trying to run a small block Chevy, triggering off one of those dual sync distributors that some of the other systems use. This would update engine position 4 times per crankshaft revolution, making it less accurate under sudden crank acceleration. If the timing chain is worn and you've got a lot of cam harmonics, maybe a bit of wear on the helical gear on the distributor, it's quote plausible to end up with 2-3 degrees of slop in the signal from the distributor sensor.

Some engine position sensors aren't physically capable of providing the ECU with 1/4 of a degree of accuracy. Anybody who claims their ECU can deliver that sort of spark accuracy under any circumstances, unless the system absolutely requires a high resolution trigger mounted on the crank, has forgotten one of the first rules of programming.

Garbage in, garbage out.

[90dsmturbo]

I'd have to say Ken is correct when saying it would retard the timing and show no signs on dyno graphs. I've run a megasquirt 1, 2 and 3 in my cars and each of those cars on the dyno would be consistent on pulls down to a few hp numbers and at the track it would be within a few tenths each run. This is a high boost 4 cylinder running 38 psi of boost and a 100 shot of nitrous and I've been on the same motor since 2009 with a ms2 in the vehicle.

I trust my motor to megasquirt and the motors of ever customer whose car I've installed them in.

Kevin

[Benkku]

I think that those measurements are 'genuine', technically vice 'no hating' there and it has not (nothing to do in changing angular speed), but those scope traces are from steady state - which is more worrying. It certainly not the reason for 'only one processor', but implementation. Ignition timing accuracy is the most important thing in ECU's, period.

Few degree ignition timing variation, is definitely catastrophic, especially in forced induction engines.

OK, so how does a single processor running multiple interrupts run 2 things at the same time? The answer is that it does not. When MS2/extra's tooth processing algorithm runs, the spark interrupt cannot. Since we toggle the spark pins in software, they get delayed slightly.

Question then, why you do it software? Should you use output compare, for accurate event timing? Obviously by calculating when the event is suppose to happen, accurate timing could be left to hardware. Then event happens when wanted to happen, no jitter.

www.ee.nmt.edu/~erives/308_11/Lecture16.pdf

[jsmcortina]

Question then, why you do it software? Should you use output compare, for accurate event timing?

There aren't enough timers and available timer pins on the MS2 chip.

James

[Benkku]

Question then, why you do it software? Should you use output compare, for accurate event timing?

There aren't enough timers and available timer pins on the MS2 chip.

James

How that can be? One of the eight should definitely dedicate to this. Output compare, timer compare force register usage etc. are only accurate way to do specific timing, when there is no dedicated timing processing unit (like MPC555 series).

[jsmcortina]

Question then, why you do it software? Should you use output compare, for accurate event timing?

There aren't enough timers and available timer pins on the MS2 chip.

James

How that can be?

Because we allow more spark outputs than available timer pins.

One of the eight should definitely dedicate to this

That's all well and good if you only have one output. (That's what MS2/BG does and is shown in the product cross reference table.)

James

[jsmcortina]

But also, why are we talking about MS2 stuff on the MS3 forum? We already made MS3 better than this.

James

[Benkku]

Because if the system doesn't absolutely require a high resolution crank trigger, there's no way they could guaranty that kind of accuracy.

Some engine position sensors aren't physically capable of providing the ECU with 1/4 of a degree of accuracy. Anybody who claims their ECU can deliver that sort of spark accuracy under any circumstances, unless the system absolutely requires a high resolution trigger mounted on the crank, has forgotten one of the first rules of programming.

Crank triggering has 'nothing to do' with timing accuracy. Crank triggering usage is to measure angular speed and speed variations. So you could use minimum tooth count to get speed, but not the latest position, when angular speed changes - as it will change during cycle - less cylinders the more angular speed varies and vice versa. More teeths and using free running oscillator (coupled with overflow flags) to time tooth time changes, only increases angular speed calculation accuracy.
In other words, 'measurement' 'has nothing to do', with event scheduling. It's not 'first rules of programming', but using hardware most efficient way.

[jsmcortina]

Nonsense.

Without an accurate tach input you can use the most precise output compare method possible and it will be utterly worthless.

I stand by Matt's comments.

James

[racingmini_mtl]

Saying that having more absolute timing reference points (which is what a wheel with more teeth gives you) doesn't give more timing accuracy than relying on predicted value is nonsense. You either really don't understand or you are a troll.

Jean