DIYEFI.org Forum

I've been doing some bench testing .. found a few things that are suspect. Based on the dev of my own product, I know that two edges happening at the same moment of time have been sources of bad behavior in the past. Knowing this, it was the first thing I wanted to check in my bench testing. This is the 2.1 extra code - nothing alpha/beta about it. All of my inputs are locked down and I'm powering it from a modern rock solid agilent power supply.

My setup is a 36-1, with 5* nulls and 5* teeth, I've bypassed everything and am feeding right into the (isolated) PT0 pin. The scope is triggering right off the sync line of the fgen .. I generated it on my Agilent 33250 arbitrary func gen:


so my first simple experiment was to have a spark event happen at the same moment at a crank edge arriving:


as you can see, its sort of a bimodal distribution (this is about 4s worth of persistance) .. sometimes it hits right on the edge as expected, otherwise it defers the edge for another 45us (this time is fixed regardless of rpm). So as you can see thats about 2.5* @ 10krpm above.

So this is 9*:


it's actually more like 7.5* actual .. I'll tweak the latency values to see if this gets any better.

and this is 11*:


it's almost 10* - so this must be some latency that I can also try to tweak out ..

so I wonder this ..
1) will latency ever change with my calibration ? I don't want to tweak latency on the bench to only have it change when I change some other thing.
2) if not why couldn't this have been cal'd out before it went to the public ?
3) at least all the error seems to be on the safe side by being retarded.
4) I've also noticed that the error 'creeps' over time and then resets (pulls tight to the original target) So you'll watch it retard over a 5s period then 'snap back'. like a rolling cumulative math error.

so far, the +/-.1 variance around the setting doesn't hold as spec either. not a deal breaker so far, I just had higher hopes. this is my home scope, so I had to use the digital camera for the captures These particular photos are of sparkA (right at the isolated pin), but sparkB exhibits the same behavior. I don't think this experiment could be any fairer or solid than what I've done. If I've overlooked something, let me know. I'd just fix this or investigate on my own... but this isn't oss, so the possiblity of it closing up will exist. So as the alternative, knowledge is power for those who are interested to this degree.

as a quick followup, latency tweaking is useless .. jumps are huge and not consistent. 14us == about +3*, 15->25us == 0 (no change) but 40us == about +6*. so I'll just have to accept what it is.

I also forgot to mention that the likelyhood of even hitting a spark event at the exact same moment as a crank edge arrival are slim in the real world... but I'm picky like that.

EssEss wrote:My setup is a 36-1, with 5* nulls and 5* teeth, I've bypassed everything and am feeding right into the (isolated) PT0 pin. The scope is triggering right off the sync line of the fgen

so my first simple experiment was to have a spark event happen at the same moment at a crank edge arriving:


as you can see, its sort of a bimodal distribution (this is about 4s worth of persistance) .. sometimes it hits right on the edge as expected, otherwise it defers the edge for another 45us (this time is fixed regardless of rpm). So as you can see thats about 2.5* @ 10krpm above.
Looks like the 2.5° error is measured from the rising edge of the crank signal just prior. Am I reading that right?

So this is 9*:


it's actually more like 7.5* actual .. I'll tweak the latency values to see if this gets any better.
Is that 7.5° from the rising or falling edge?

and this is 11*:


it's almost 10* - so this must be some latency that I can also try to tweak out ..
That looks like almost 10° from the prior rising edge, off the left side of the scope screen.

These particular photos are of sparkA (right at the isolated pin), but sparkB exhibits the same behavior. I don't think this experiment could be any fairer or solid than what I've done. If I've overlooked something, let me know. I'd just fix this or investigate on my own... but this isn't oss, so the possiblity of it closing up will exist. So as the alternative, knowledge is power for those who are interested to this degree.

It's great that you did the tests, it doesn't look like you overlooked anything. Tested both spark channels and everything. I just don't understand the edge trigger scheme.

If there were anything else I'd try, it'd be to trigger on the falling edge of scope ch2. Just for the heck of it.

that rising edge on the top trace is exactly 10* btdc, it's width is 5*. the bottom trace is the firing edge.

so as you're moving the firing edge right , you're getting closer to TDC (which is the next rising edge immediately off to the right side), so halfway through that tooth width is 2.5* - 10(my ref edge) == 7.5* 'measured advance'

the top trace is 'locked in' and fixed .. I'm looking at the spark edge relative to that.

/edit - I screwed up on TDC, it was originally btdc

I see now. In your first image (edited below), the MS is set for 10 degrees advance. And in the second and third images the MS is set for 9 and 11 respectively.
I realize the scope is triggering off the arb, I was suggesting to also do the same setups with the scope triggering from channel 2.

I have a question about terms. When you said 'reference edge' do you mean as it relates to the 3 tests? Or do you mean the MS 'reference edge'? I don't know the exact term, but I mean the edge configured in MT that the MS uses to 'countdown to spark' from.

- Jim

by ref, I meant target .. my target is exactly the edge you labeled. you did it perfectly. what more could I learn from triggering off of the spark edge ?

word on the street is to 'not use high tooth count' references .. but isn't that the point to get better accuracy ? .. ugh .. so to disprove the 'high tooth count' argument - my next experiment is 4-1 sometime later this week.

Do 60-2 as well for good measure, that is actually vaguely high, 36-1 is just default if you ask me.

Got it. Just for information, which btdc degree is the MS set to start it's 'countdown to spark' from?

Regarding what you might get from using another scope trigger, maybe nothing. Using other available triggers is maybe another way to say, 'looking at it from other perspectives'. Maybe the results are substantially the same, but maybe also there's something in the different perspective that yields something significant. Besides triggering on scope channel 2, which comes from the MS, maybe also trigger on channel 1 using the missing tooth PW and delayed sweep. It takes a couple of minutes to do, and you never know what you'll see or think afterward.

tooth1 setting == 70*

Hi,
I think maybe which interrupt will happen and be processed is a lotto. I don't think ms is using output compare for ignition discharge seems like it's a regular timer interrupt. Further I don't think there is any interrupt priority or nested interrupts at least not the last time I deciphered some ms code. To avoid this in your own project use output compare for discharge control or nested and prioritised interrupts the #1 function to be accurate is ignition discharge IMO, If your mcu has input capture once you get around to processing that interrupt it still has a valid time stamp. Having more teeth I doubt make it more accurate because once the timer is loaded from the trigger tooth it gets adjusted no more so any teeth between that and the discharge does little to nothing. maybe the rolling is the PID settings? or maybe just the .128ms interrupt mixing with your time base.

After having a quick look in the code I find this comment about the timers:-

// TC0: Input capture (tach) - no pullup (default) for MSII
// TC1: Output compare for injector output - bank 1
// TC2: PWM2 for injector bank 1 / Timer for bit bash spark output
// TC3: Output compare for injector output - bank 2
// TC4: PWM4 for injector bank 2 / Rotary Spark
// TC5: Output compare for EDIS output / 2nd trigger input
// TC6: Dwell timer
// TC7: Rotary dwell timer

So maybe EDIS will be closer? I don't know what speed EDIS will spark until. Maybe the Output compares for injector current limiting idea was not so good and should of been dedicated to the important timing.

Regards
Jay