Still Getting Ignition Miss. Running Out Of Ideas.

[TheMonkey]

skip actually happened at 1:13.578, where there are only 8 teeth between ignition events (8 teeth, even when you count the missing tooth), then next missing tooth, it takes a break to resync. ignition event at 13.585 happened 1 tooth to early.

is it coincidental, that the ignition event is right at the missing tooth? perhaps something in code forks up when it 'straddles' a missing tooth. it's almost like the wheel stayed synced through the missing tooth at 13.578, but at the same time, it counted the missing tooth as actually happening.... seems that if you look at the ignition event at time=13.585, that occurred only if you count the missing tooth as happening.

hmm....

[TheMonkey]

when i looked at the datalog, i noticed that there was another skip in the data a few seconds later. i located it in the recorded scope data, and the code did a tooth miscount right at the missing tooth again. count the teeth back, and note the similarity, except that signal went high after only 7 teeth (including missing tooth). strangely, the jumper voltage was left hi this time until resync, and it went out of sync right after the wrong tooth count instead of waiting a cycle like the previous miss.

the whole previous rotation properly waited 9 teeth between events, so it's not like the arrival of the missing tooth here was an alert that it came too soon.

[TheMonkey]

here's the datalog from this recent picture book: http://www.mediafire.com/?ltsvcng2ddv

the two misses on the scope happened at 1:13.6ish & 1:16.4ish, which correspond to the two misses in the datalog at 194.7ish & 197.5ish. the scope recorder was turned off at 1:18.x, so it did not capture the third miss in the datalog.

note the trigger+/- data, the 2 misses were treated differently:

the first miss was a trigger+; where the JS10 jumper stayed lo and was 'alerted' by the missing tooth that it came early.

the second miss was a trigger-; where JS10 jumper stayed hi during resync after it went hi after only 7 teeth since prior ignition.

[FixItAgainTony]

Scott,
Looking at the scope trace on the bottom of page two, where you zoomed out a bit is interesting. I would have thought that there would be 4 evenly spaced pulses per every 360 degree revolution of the crank. I printed out that waveform and measured the distance from rising edge to the next rising edge (units don't matter here):

18.4
15.6
19.8
18.8
18.8

Just looking at the Tsel signal, I do not see that much variance (just by eye). With the amount of rotating mass in an engine I would doubt that there could be that much of a change in the RPM over that short of a time. You had also mentioned that this happens at higher speeds => a steadier RPM.

Given how clean your electrical system is and the input / output you have scoped, to me it looks like something odd in the wheel decoder.

Charles.

[TheMonkey]

Charles-

Scoping while probing the JS10 jumper had 2 misses.

"looking at the scope trace on the bottom of page two"
You were referencing the first miss at 1:13.xx. And you are right... while the signal at TSEL looks okay, the JS10 jumper signal looks funky.

I looked at the recording again on the scope, where I can drag markers around with precise measurements, and found that dwell was weird on the missed pulse too.

The following drawing is the first 4 teeth that you measured in the zoomed out picture from the bottom of page 2. It was pulse 'C' that puked. Pulse 'A' and 'B' look like every pulse before it, where dwell was apprx 1.8ms, and was starting/ending exactly 9 teeth from the previous. Pulse 'C' seems to have started 1.5 teeth too soon, and ended just over 1 teeth too soon, with a dwell that longer than the others, at 2.2ms. Then, pulse 'D' looks normal, except that it occurred too soon. The number of trigger teeth between 'B' & 'D' was only 17, so when it arrived at the next missing tooth, it resynced.

[grippo]

This is a large amount of data and I can't argue that it seems to show a perfect signal into the processor. So normally I would be deep into the code to see what could be wrong. But in your case there is nothing unusual about your setup, and the trigger +/- counter is as simple as it gets - it is trigger by a processor interrupt from a signal edge - I have no control over this except to ask the processor to do this at startup and to go to a specified code location. At that point I go to a register, pull out the time it happened at, and out the previous time to get the tooth time. Then I compare it to the time of the last tooth using the tolerance you input. The only wrinkle is I have to take into account whether it is a missing tooth or not, so I don't compare apples and oranges. All of this is well tested code. If it were going to break I would expect it to break at very low or very high rpms - not at idle rpms.

So here is all I can think to do:

1. post the msq you used for these last tests and I will try to reproduce things sometime this week.

2. Try test code (v2.883t2) that I recently posted on the microsquirt forum, under ignition tuning, geofct being the name of the starting poster. This code does not throw out or add in any pulses, nor does it resynch unless it's just not seeing anything for 2-3 secs. It does however record the trigger +/-, so if we see that this does not miss, then we will have a handle on this. This is not code to go driving with, but since your problem is at idle it should be ok.

3. Try another unit which I will arrange to have sent to you.

4. Test if the miss occurs at 1500 rpm. At this point I'm not sure what it will tell us, but it may tell me something as I go delving through the code.

I will also consult with Bruce to see if he has any ideas.

[TheMonkey]

Al-

Y, heaps of data, I'm trying to keep it broken down to the important parts. Thanks for your attention on this matter. I'll continue to follow your leads.

These traces were scoped directly at processor input and output. I find it interesting that the questionable pulse 'C' had longer dwell. Also, in the miss that occured at 1:16.xx, the JS10 jumper was left high for a long time which is 'dwell equivalent' and would be charging a coil if firing coil directly. Do either of these things follow any expected code logic?

Your suggestions from above:

1) here's a link to the MSQ - http://www.mediafire.com/?fmtnmdmzwzv

2) you mean the 2.883jt2 code? i will give it a try, but you said it will never resync... does this mean that timing could advance 10* at each missed tooth? i'd hate for timing to continue to accumulate into something gnarly. OR... will the code continue to reference the missing tooth to the delay teeth, everytime the missing tooth comes by? can i use my existing:
- msq file
- megasquirt-II.ini
- settings.ini

3) referencing a known working unit would sure eliminate the big question whether the problem is specific or systematic.

4) by measuring exact time for the last revolution before the miss referenced above (1:13.623) occured at exactly 1304 RPM, when engine was already warmed up... it's smoothest point. misses have happened as low as 750 RPM, and as high as 2,000.

Thx, Scott.

[FixItAgainTony]

Something bothering me here on the probing of the TSEL line:

I do not see anything wrong with the signal coming out of VR circuit. This is probed at the TSEL jumper. I had to probe through a 1k resistor, because after I removed the flyback circuit, the motor would die if I probed at TSEL without a resistor (?).

Yet the probes are 1MegOhm - that does not sound consistent to me. That signal is the output of an opamp going directly to the interrupt pin, it should not get loaded too easily.

Am I missing something here? Probably not relevant, even if the scope is loading the circuit, the odd behavior is present.

- Charles.

[grippo]

Al-

These traces were scoped directly at processor input and output. I find it interesting that the questionable pulse 'C' had longer dwell.
Also, in the miss that occured at 1:16.xx, the JS10 jumper was left high for a long time which is 'dwell equivalent' and would be charging a coil if firing coil directly. Do either of these things follow any expected code logic?

>>>>>>The first long dwell may have been a result of the timing problem, but the extended dwell should have been cut off after 0.3 sec.

Your suggestions from above:

1) here's a link to the MSQ - http://www.mediafire.com/?c21vei1sveg

>>>> I only see a datalog file here

2) you mean the 2.883jt2 code? i will give it a try, but you said it will never resync... does this mean that timing could advance 10* at each missed tooth? i'd hate for timing to continue to accumulate into something gnarly. OR... will the code continue to reference the missing tooth to the delay teeth, everytime the missing tooth comes by?

>>>>It will keep skipping teeth, so it will have to be cut at the first hint of a miss. If you have any reservations about this don't try it.

can i use my existing:
- msq file
- megasquirt-II.ini
- settings.ini

>>>>>>>yes- there is no change in any of them

3) referencing a known working unit would sure eliminate the big question whether the problem is specific or systematic.

>>>>who did you buy your unit from ?

4) by measuring exact time for the last revolution before the miss referenced above (1:13.623) occured at exactly 1304 RPM, when engine was already warmed up... it's smoothest point. misses have happened as low as 750 RPM, and as high as 2,000.

Thx, Scott.

[TheMonkey]

>>>> I only see a datalog file here

d'oh. here it is: http://www.mediafire.com/?fmtnmdmzwzv

>>>>It will keep skipping teeth, so it will have to be cut at the first hint of a miss. If you have any reservations about this don't try it.

i think i'll pass... hope you understand; letting prudence be my guide. do you remember that scene from the movie 'Flash Gordon' where he had to reach his arm fully into that creepy rock? it kind of feels like that.

>>>>who did you buy your unit from ?

DIYAutoTune. kit form.

[TheMonkey]

Something bothering me here on the probing of the TSEL line...

Charles-

you know... i think you may be right. it's important to sift the clues and keep them in mind. it doesn't make sense to me why removing the flyback circuit would affect the load into IRQ. at one end of that circuit is the IRQ pin 14 at the processor, and going the other way, only exposed to pin 24 on DB37, VCC, and ground. perhaps the removal of the flyback circuit was coincidental timing, or it did something to the VCC or ground plane. interestingly, after reading your comment yesterday, i tried probing again without a resistor on the probe.... this was with distributor VR hooked up.... and it made engine run very rough then die, but not immediate lights out like before ('before' was from crank trigger).

it's definitely a clue to remain the list of information to keep in mind:

- miss appears to occur in processor, although the behavior observed at JS10 signal does not seem to be an expected result of code (odd dwell on chunked pulse, and kooky start & end location).
- pattern of signal into IRQ processor pin 14 looks excellent
- voltage of hi signal into IRQ is 3.7v (enough to trigger 3.25v hi-trigger for IRQ, but why does this voltage vary from others?)
- probing TSEL without resistor kills motor or makes it rough (using CDI box, so signal from pin 36 must become erratic when triggering from distributor, and signal vanish when triggering from crank).
- miss happens during stable RPMs, and at various RPM levels
- miss remained with code reversion to 2.687
- miss goes away when not using decoder (trigger from distributor VR)

although my power bus looks excellent when probed at random points in time, perhaps i should record it, now that i have that ability. i suppose i could probe JS10 and compare against VCC? JS10 shows where the exact miss occurs. Would recorded VCC probe show if there were any problems from radiated RFI, or is it possible that radiated RFI could screw up the processor as an isolated problem, and it would not show up on VCC?

Scott.

[TheMonkey]

tonight, with crank trigger, i recorded the JS10 jumper vs. the VCC power (AC component only). i heard it miss, but tach did not drop out. i pored over the scope recording and there were no resets, but i found 4 instances where it just did not send a pulse to ignition circuit. just a missing pulse, never lost sync or anything, just didn't send the pulse.

i reopened up the previous file with the 1:13xx miss & resync, and 1:16.xx miss & resync; pored through that, and also found a plain missing pulse that i did not see before.

there was no noise on the VCC 5v when the missing pulse arrived. Notice in the scope shot, how sensitive the scale is on the VCC probe.

red = JS10 jumper
blue = AC of VCC

zoom out of missing pulse: http://img185.imageshack.us/img185/1662 ... cc2eq4.png
close up of same missing pulse: http://img390.imageshack.us/img390/1502 ... vccae5.png

[FixItAgainTony]

I went back and looked up some old information on the Vr circuit. The simulation that was run during the developement showed Vout about 4.1v, which sounds reasonable to me for a single sided op-amp. 3.7v sounds a little low. Have you looked at VrOutInv? A quick look at VrOut with the Tsel jumper disconnected might also be interesting. If it pops up to a higher voltage, it would indicate that the Irq line has a load on it somewhere / damaged input buffer. Conversely, if VrOutInv has a higher amplitude, perhaps the opamp output buffer has a problem. Regardless, the input should still be good enough to create a signal.

Is it possible to use the VrOutInv signal as Tsel by swapping the input Vr lines? Might be an interstnig easy to do check.

Part of what is bothering me is the loading of the circuit with a probe effecting the engine operation. I have not looked at the opamp specs, but I suspect that a 1k ohm load straight to ground on the opamp output should not cause a problem. I think that on your set up it would kill it completely. The microcontroller is so fast relative to the application that it is going to see any noise glitch or lack of signal, either of which would cause a problem. Swapping the opamp may help to shed some light on this. The addition of the probe can also act as a filter on a high frequency low level signal. The fact that you are able to see the same symptoms with / without probing makes me think this is not a problem in your case, but something to be aware of.

Good luck,
Charles.

[TheMonkey]

Charles-

i have tried the VRINV, just forgot to put that on the original list of things tried. the voltage coming out of pin 7 on the opamp (VrOutInv) has the same amplitude as pin 1 (VrOut) - 3.7v hi.

Kris had a similar voltage out from opamp, and swapping opamp did not change it. very interesting idea to check amplitude of VrOut if the Jumper to TSEL is disconnected.... if voltage increases, then i would suspect everything before processor input checks out as 'okay'.

since i now am finding occasional missing pulse to JS10 (without tach drop out, or resync), it makes me wonder if that might ALSO be occurring while triggering from distributor without wheel decoding.

fyi.... a missing JS10 pulse that i found on the scope file with TSEL did not show any trigger+ or trigger- on the datalog. this missing pulse picture has missing pulse at 26.2 which corresponds to time stamp 147.3 on this datalog that was shared on the evening March 29.

Scott.

[grippo]

OK I tried your msq for several hours on the bench last night and no misses were recorded. The input signal was a 36-1 toothed wheel that ramped back and forth from 100 to 2000 rpm. I will email you off line about getting you a different unit to try.

The only time I have seen a missing output like you describe was at cranking rpm where this can sometimes occur when dwell crosses a tach tooth boundary and can be eliminated by a different choice of delay teeth/ trigger offset. But it has always disappeared after cranking. I thought I had corrected this, but possibly not. Further work on this will require a different set of code diagnostics and a lot of time. I think it is more important to correct the tach problem and then see where we stand.

[FixItAgainTony]

Scott -
Been thinking about the missing pulse, 3.7V, etc. From the HCS12 data sheet (input/ouput buffers) 35% - 65% of Vdd for logic low / high. => 1.75V / 3.25V - Not a lot of margin on the high side, but it should be fine. There is frequently a bit of margin between guranteed operation and actual. I was trying to figure out if there is an easy way to put an additional buffer / filter from Vrout to Tsel. Originally, I was looking at using one of the LED drivers, when I spotted the neighboring optical isolated input. Would it be possible to take the VrOutInv signal route it to the cathode of D2, connect XG2 to XG1 and OptoOut to Tsel? If I read this correctly, it would insert a driver and a bit of filtering (C12, C31, C11 and associated resistors). The optical isolator requires a few millamps to turn on. I am guessing the opamp has enough snap & pop to deliver this - I checked the datasheet for the opamp, but did not get a real good feel for its output capabilities from the data sheet I had. A check with the scope should indicate of the opamp / optical input / output is working okay / loaded up too much.

A side note - I used my setup to datalog my LJET computer performance. While looking at the log, I noticed that my Vbatt was as clean as could be => the noise on my board is related to the additional load of driving the outputs.

- Charles.

[krisr]

Ohwell my timing cover has gone off to Loctite's porosity/impregnation sealing place to get treated. Should have it back in a week or 2 with any luck! Also found an Edelbrock 8810 pump for $100 too, bonus! Will post up soon once i'm running.

[TheMonkey]

Charles- What an interesting idea. Perhaps I'll have a chance to fool around with that this weekend. If the opamp was getting loaded, would it get warm to the touch just running the stim? Great idea.

Kris- So was your timing cover just sweating coolant, like osmosis?

[FixItAgainTony]

Hello Scott,
If the opamp gets loaded too much, its output will no longer swing to the typically seen 3.7v. It might get hot, but it is more the output voltage that would be of interest. The optical isolator has a 390 ohm current limiting resistor (R12) 5v/390 * 1000 = 12.8 mA in if driving at 5V, at 3.7v => 9.5mA = load on the opamp less feedback current. With 5V supply, it should be able to do that. If it is a problem, double the value of R12 to cut the current in half. I suspect that optical isolator will still have enough to fire with - I did check the data sheet on that, and I seemed to remember 5mA or so would easily turn it on. I do not have the data sheet here to check again. When done, there should be a nice solid signal on the OptoOut pad, swing from 5v down to 500mV or so. It will not go all the way to ground, but it will be close. There should be a lot more margin on the top end IRQ input signal + the additional filtering. A very small pulse might be enough to throw the wheel decoder off - the filters may clean this up.

The data sheet on the opamp that I found had some nice graphs in it, but the vertical axis were not labeled, which make it a little hard to figure out what they meant. If I read them right, the opamp should be up to the task. The only reason I have any concern is related to the need to probe through a 1K ohm resistor. Perhaps 3.7V is close to the limit for your particular MS-II IRQ input, and any additional load causes the interrupt not to register. It would fit a lot of the sysmptoms... The optical-isolator run should be intersting.

- Charles.

[TheMonkey]

It's working on the stim.

But something is a bit strange.

Before swapping the circuit, the inverted pin 7 on the opamp was showing the same high voltage of 3.7v and the low voltage was 1.2v. After swapping the circuit, the low voltage is the same, but the high voltage dropped a bit to 3.35v. That's not the strange part, but notable.

Here's the 2 strange parts:
1) Check out this PICTURE. The red trace is the stim VR input (ignore high voltage - ch1 of scope is showing max of 2.25v?? - actually is ~12v). The blue trace is the inverted pin 7 of opamp. At the gapped tooth, why does the pin 7 go high too early?

2) Also, the Opto Out signal seems to have some kind of delay, where the signal goes high, and kind bends to the right like a banana. Here is that PICTURE, red is VR input signal. Again, I included the missing tooth portion to show the rise too early.

RATS.... those were from 1,200 RPM. I turned up revs to 6,600 and it really got ugly. the banana phenom must be a load problem?

PICTURE of inverted VR out at 6,600

PICTURE of TSEL at 6,600

Good idea though. Kris modified his VR output to increase the voltage a bit because he was at the same voltage. I think he is > 4.0v. We'll surely be hearing from him as he gets his motor fired back up.

** Edited to add... the pin 7 of opamp seems to have a max period of 1.4ms that it can stay low. that's why it jumped in the missing tooth. i slowed revs down to a few hundred RPM, and EVERY tooth started jumping up early. right at 1.4ms.