RPM dip but no sync loss

[Kzcleve]

My setup
I am using MS3 board 3.0 with MS3X, firmware version MS3 pre1.3 alpha5
The engine is an GM LT1 V8. Full sequential using the optispark for crank/cam sensor stock GM ignition module and coil. I am also using a GM MAF sensor.

The problem
I keep getting RPM dips accompanied by a pulse width spike followed by a brief dip (rich) in AFR. The dips do not happen all of the time but at least once per drive. I am pretty sure the PW spike is a result of the MAF algorithm seeing the dip in RPM but no dip in MAF so the PW spike is no surprise, the RPM dip is what i am worried about. I have attached a log that shows what i am talking about. see 804.738, 835.135, and 948.881. There are a few other examples in the log but these were the obvious ones. At 851.373 there is a large RPM dip with no spike in PW but a spike in AFR instead of a dip. I am pretty sure that was just a misfire. I have never seen the problem accompanied by any sync loss. I basically never get any sync loss (an exception is in the log i attached, it shows that there was 1 sync loss event but that was on start-up and rarely happens.). I have a composite log but I don't see anything odd in it and I am not even sure if any RPM dips happened when i was taking that log. I can post some of it if it might help.

Some additional details that might be important
When I originally hooked up the optispark I used the VR inverted circuit as per the manuals instructions. No matter what I did though i kept getting sync loss, I adjusted the pots endlessly and had no luck. I have an oscilloscope and I could not get a really good wave pattern on it no matter how much i adjusted the pots. All that being said, I decided to bypass the VR circuit. Instead I made a protection circuit in the proto area that matches the one on PT4 and then just send the low res signal directly to the processor. Since i changed the circuit, I have had no sync loss problems (about 5 months now).

[slow_hemi6]

Have you thought about it the other way. Often false triggering of Accel Enrich gives a pulsewidth spike that sends the engine rich so this causes the rpm drops. But in this case could it be a glitch in the MAF signal causing the RPM drop rather tan vise versa? There is definitely a spike in MAF load that corresponds with to each instance.

[Matt Cramer]

The MAF signal itself looks pretty regular, though. Can you catch a composite log of the RPM dip? Does the issue happen with 1.2.3 release code as well?

[Kzcleve]

Thanks for the responses. I agree that the MAF signal looks pretty stable. I ran the car in speed density mode this weekend just to check and the problem was still there. Matt, I attached a composite log, I had to cut it down a lot to get it to fit but if you need more I can send it. After looking through this composite log, it looks like any trouble might be on the cam input. let me know what you think. I am not sure if the missing events on the cam track are strictly visual in MLV or if there is really a problem there.

As for you question about 1.2.3 release code. When I had the car on that release I was focused on another issue that I resolved as i moved to the alpha code so I am not positive if it was happening--but i am sure that the physical feeling of a tiny miss that accompanies the issue was there when i was running 1.2.3. Thanks for the help on this one.

[Matt Cramer]

The Optispark mode switches off the cam interrupt above ~1000 RPM to reduce processor load. Did you capture any of the dips in the composite log?

[Kzcleve]

Thanks for the info on the interrupt. The composite log I have did capture one of the dips but I need to find where. I am not certain it is in the section of the log i posted.

[Kzcleve]

I have been logging for the past few days to get a composite log with the dip in it. Several times I have been running the composite logger when the dip occurred but when I go through the composite logs I can't find anything of interest and I don't want to post something that is a waste anyone's time. Maybe I just don't know what I am looking for. What should I be looking for?

[Matt Cramer]

Get a feel for the basic pattern - then see if there's a stretch of the log that doesn't conform to it. A section where there's an extra short pulse, or a long pulse you were expecting doesn't happen.

[Kzcleve]

Thanks. That is what I have been looking for and I can't seem to find anything. I have been going through old logs looking for these dips to see if anything stood out and I noticed something that might be interesting. Nearly all of the dips have happened between 1900-2300 RPM and each time the RPM dips by about 35-45%. I am wondering if the dips could have anything to do with when the MS3 stops using cam interrupts. From looking at the composite logs, it seems that the transition from using interrupts to not using interrupts happens around 2000 RPM. I am not saying that not using interrupts causes the problem but possibly the transition from using the interrupts to not using the interrupts might sometimes result in the dip. In such a case, the dip event might be happening on the tooth that occurs between the pages in the composite logger. Just a thought. Otherwise, I am still not finding anything in the composite logs but I will keep logging and looking.

[Kzcleve]

Disregard my last post for now. I have been looking at the per cylinder knock events in my logs and I see that there is a spike in knock input at each dip (a different cylinder each time) this is true for the log i posted as well. I am fairly certain that this is not knock but I think it might be a misfire. Could misfires cause the kind of RPM dips I am seeing? I also noticed that even in places in the log that there are no PW spikes or RPM dips there are RPMdot spikes that correspond to knock in spikes that look the same as when the dips occur.

As a side note, I am still unable to see anything in a composite log that raises concern.

[Matt Cramer]

Yes, this could be a straight up misfire.

[Kzcleve]

Thank's for keeping with me on this one. I will address possible causes of misfires and then check back in.

[Kzcleve]

It has been a while since I have been able to focus on this issue but i finally got a composite log that is helpful. Take a look at frame 37. I think It looks like i am getting a bogus cam pulse and it was accompanied by the same symptoms described above. What confuses me is that a bogus pulse would show up as an RPM dip, I though that would show as a spike and a missed tooth would show up as a dip. When I look at the data it's self it shows that tooth is about half of the tooth before and after and a 1 for SecLevel and that is the only place in the log it shows a 1 for SecLevel. I have three composite logs and i see the same thing happen once in each log. Is this just noise on the PT4 input? What does the change in SecLevel mean and how does the cam pulse affect RPM and fuel calculations/timing.
EDIT: after reading more, it seems like the issue can't be a cam pulse but is probably a problem on the crank side. Am I seeing the cam flag because of a re-sync?

[Matt Cramer]

I think frame 37 may be a rendering error, but I'm not sure.

[Kzcleve]

I think frame 37 may be a rendering error, but I'm not sure.

I suppose that could make sense. I do feel the car miss/stumble and usually see a one record RPM dip either to 0 or a really low number like 200 in the log. I am not saying that frame 37 is necessarily capturing the issue but i did feel the miss/stumble one time while I was collecting that composite log. I Have done about all I can as far as eliminating misfires. When i Looked at frame 37 with the include non-interrupt data option, I saw an extra dot on the crank trace below the odd cam line, but I don't know if that means anything. I was also wondering if the cam flag could be caused by the RPM dip. As I understand it, the controller will ignore cam pulses except to sync with the crank pulses at during cranking. If my RPM dips below my cranking RPM threshold, would that cause the controller to look at cam interrupts again, and could that explain frame 37? I know that is a little beside the point of my issue but I am just curious there.

I have also noticed that I can almost count on one or two of these misses around 2600-2700 RPM. I don't know if there could be some sort of frequency dependent noise i am dealing with or if it is just a coincidence. Anyway--thanks for the help. I will just keep plugging away at the issue.

EDIT: I just reread my last post and realized I might have been less than clear on one point. When look looking at the raw data of the composite log I saw that the Tooth time at the odd cam pulse was about half of the tooth time before it and after it. Specifically, the Tooth time goes .172, .172, .088, .084, .172, .175 ... I don't know if that helps but I thought I would clarify my poor explanation.

[Kzcleve]

The last code update, 1.3.3 beta 5 really helped how the car was running. In the previous post I said I could almost count on a miss around 2600-2700 RPM; that miss is gone now. However, I am still struggling with the random RPM dips. Can anyone tell me how RPM is calculated for the Optispark wheel. I don't know code well enough to work it out from the code. I just want to know so I can better think about where the Issue might be. Thanks for any help.

[jsmcortina]

I'm planning to re-test OptiSpark some more this week. I have one here on the bench.

James

[Kzcleve]

Thanks for the heads up. I appreciate it. I will wait to hear what you find.

[Kzcleve]

I'm planning to re-test OptiSpark some more this week. I have one here on the bench.

James

James, did you have any luck on the OptiSpark? I know you are busy and I am not trying to be pushy I am just curious. Also, I was wondering if you could help me understand how the code handles the OptiSpark. Specifically how the high-resolution track is used after start-up, it seems like I heard somewhere that the high-resolution track sends an interrupt every six pulses or something like that. In my composite logs I am not seeing any problems with the low-resolution track so it seems like it might be on the high-resolution side. I have taken a lot of composite logs that I am sure were logging when several of the RPM dips happened. I am not seeing anything in them but I am happy to post or send some of those to you if you are interested.