uS Timing accuracy problems

[bgeisick]

I've got my uS running on my bench for testing purposes and noticed that occasonally the timing would jump around. I decided to investigate this a little bit and hooked up a scope to the crank signal and the timing output from the uS. What I found was that depending on the trigger offset, timing can jump up or down 20 degrees depending on the timing that is being requested. I've attached a picture of the results. Fortunately I wanted to use a 135* trigger offset for my setup, so the timing shouldn't jump around as long as I command a timing value between 5 to 40 DBTDC. Had I chosen my crank trigger to need a trigger offset of another value (110* or 150* for example) and I would have had timing jumping around quite a bit.

Even without timing jumping around and using my 135* trigger offset, the measured timing value is consistantly off by +10 to +12 degrees. Obviously I could shift my trigger offset by about 10 or 12 degrees to address this, but it seems odd to me. Is there something I've done wrong with my msq setup that is causing this?

This is an odd fire engine with 90 degrees seperation between spark 1 & spark 2. I'm using a 10-1 crank tirgger and have the software set to "single crank wheel". I'm not sure if fuel settings would impact my timing in any way, but I have the fuel injection set up to inject 2 times per engine cycle using simultaneous injection. I'm running code version 3.78 on a 2.0 version uS (black board).

[Bernard Fife]

bgeisick,

This is the sort of problem you would expect to see if you were triggering on the wrong edge of a VR crank input signal. So you might want to look into that. See: http://www.megamanual.com/ms2/pickups.htm#vr

Other things that could do it include having the VR input delay setting incorrect: http://www.megamanual.com/mt28.htm#ia

Lance.

[bgeisick]

I am using an optical sensor that generates a square wave Verified with the scope, so I don't think it is the polarity issue. The data was collected at a constant speed (1450 RPM), so the VR delay might explain the +10 error, but it doesn't explain the sudden shift in timing accuracy as requested timing changes.... at least I'm not sure how.

Something that I find very coincidental is that the span of timing values between the jump up and jump down is ~36 degrees, which is the spacing between trigger events of my 10-1 wheel. If the tooth used to find the "last individual tooth interval" has a slightly different shape or dt between teeth compared to the spark tooth, maybe this could happen? http://www.useasydocs.com/details/crankwheel.htm I'm not familiar with the alpha, beta, gama predictor routine, and I think I have my software set to last interval or something similar.

I'll try to scope my crank wheel to see if there are large discrepencies between tooth widths.

[grippo]

I ran your msq exactly as is on my bench and I don't see these jumps. In particular I ran 135 deg offset with advance from 90 deg to -10 deg and the measured timing followed the requested timing spot on at least to the eye. I scoped the teeth against the Ign1 spark falling edge. Noting the teeth are high for 18 deg and low for 18 deg, you can get a good estimate (within a deg or 2) of the angle by eye and I plotted the position on graph paper with 1 large div per 9 deg and everything lines up fine. 90 deg is 10 divisions behind 0 deg and all the other advances are equally spaced in between.

Now there is a limit at -10 deg - it won't move to -20 deg, but this is likely because fuel and spark have to fit within two tach cycles, where the cycles in deg are defined by trigger offset and the no of cylinders. The Odd angle may also play a role, can't remember exactly.

[bgeisick]

Sounds like it must be a problem with my setup then. I have been scratching my head for a while now without any ideas . I've attached two pictures of my scope with the same msq that you tested. The first picture is 5 degrees timing advance and the second picture is 4 degrees. You can clearly see from the picture that the timing signal jumps a whole tooth. I can't think of any reasons it would do this.

The two traces in the pictures are the crank wheel input to the microsquirt (not the ecu pin) and the spark output. The crank trigger is set to "falling edge" to line up with the crank wheel signal's rising edge.

Any suggestions or thoughts why the timing seems to jump so much with only one degree change in requested timing advance?

[grippo]

It may be that you are triggering on the crank input, which would be fine if it didn't have a missing tooth. I always trigger on the spark or fuel output, as that is evenly spaced.

[bgeisick]

When you say triggering, I assume you mean the trigger on the scope? In the pictures above I was using the tach output signal to trigger the data capture on the scope. I have also used the spark output, with similar results showing that it will jump ahead a tooth.

As a side note, I've also used an LED connected to the spark output to visually show where the spark happens relative to the crank wheel (very much like a timing light). It also shows a sudden jump in timing, so I don't think it is a matter of the scope setup.

A few notes on my bench setup:
I'm spinning a crank wheel on a DC motor that has constant voltage applied to it, so the speed is pretty stable. The wheel I'm using is setup to be used with an optical wheel. I didn't machine the wheel, so the teeth very close to the same sizes, but not identical. This is shown by the slightly varying tooth widths seen n the scope traces. Dispite that, I am still scratching my head as to how the tooth widths could change the tooth number that the code uses to begin the timer count down for spark. My understanding is that it only depends on the crank wheel setup and the desired spark timing. It appears to me that the tooth used for spark timing is changing for some reason, but maybe I am misunderstanding something or over looking something.

Is there any way to get access to additional parameters that are calculated in the code? For example, is there any way to set up a log of the tooth and the subsequent delay calculated for spark events?

BTW, I really appreciate your suggestions and time spent reviewing this with me.

[grippo]

There are several corrections to spark advance, such as cold advance or air temp retard, which, if the temps were noisy because they weren't hooked up, could cause noise in the spark output, but it would be random or at least inconsistent from hour to hour and wouldn't depend on a change in the spark advance. Plus this is a huge change, about 20 deg in timing, not just a little jitter.

I have a few questions: When you change timing, do you change the advance table or just the trigger offset ?

Does the ignition advance gauge change by the same amount you changed the timing ?

Is this effect consistent - if you try the exact same sequence several hours later, do you get the same top picture and same bottom picture ?

If you change the vr1 edge polarity and nothing else, what do the top and bottom picture look like. I expect the spark output on the top picture will move by a half-tooth, but after you make the same 1 deg change in timing does the spark output again retard about 20 deg rel to original timing ?

[bgeisick]

I am changing the base timing table when I see it jump. I get the same results when I change the timing offset though.

I have long ago set my cold advance, IAT advance and all other timing modifieres to 0 to eliminate the problem of irratic or drifting temperature sensors. The timing value on the main screen of TS also says 5* or 4* when I change the value in the base table.

I get the same pictures over time. I confirmed this again tonight by waiting two hours and checking the timing several times during those two hours. It was very consistant in the tump that I saw and looked identical to the pictures I posted earlier.

I also took some scope pictures when I switched from a falling edge trigger to a rising edge trigger for the crank trigger (using the optin pins, not VR). I get similar results except the timing jump occurs with 6* and 5* spark timing. The other interesting thing about this is that 5* is a tooth more advanced compared to 6* when using the rising edge trigger. All other timing values change as expected. I also took pictures while measuring the signal at the cpu as well.

[bgeisick]

Tonight I verified that I get the same jumps in timing when I use the VR1 input instead of the optin inputs.