MicroSquirt.com read only forum (Jan.15,2018)

That is good news. Have you had any rpm drop outs from missed VR triggers or any other noise symptoms ?

No RPM dropouts. Datalog looks great with no noise in any of the individual datastreams.

The only oddball thing is that trigger +/- occasionally picks up a negative, but only during idle. The most I have seen is dropping to -5 over the course of an entire datalog. I have not fooled with any of the decoding algorithm variables. It does not seem to be noise or hardware related. I have wound up the car on the road to about 5,500 revs just fine.

i hooked up the scope to record 2 of the IGN outputs for a 30 second test of wasted mode while idling/revving in the garage. arbitrarily, i chose output #3 & #4 (out of the 6).

unfortunately (or for diagnostic purposes - could be fortunate?) it exhibited the same behavior that my Pontiac had. very erratic pulses, including some with huge dwell times.

here is a picture of what to expect as a good picture (red = #3, blue = #4)


attached file is a datalog running fuel only, while scoping the 2 ign outputs. there were a few trigger- that occured, but not until time stamp 46.4s. it seems to be more susceptible to trigger- when reving up in neutral. ignore AFR - sensor not heated up yet.

here is some funk at about time stamp 40.6s, where everything on the datalog is clean:


here is some really crazy funk at about time stamp 46.6s, right where the big trigger-6 occured. even if it was adjusting for a bad trigger algo, it ended up spitting out a huge dwell period (21ms, with expected 5ms) which the code never calls for:


so... the good news is that i can attempt fixes to this while running on fuel only, and will hook up individual coils after the output signals are cleaned up.

I will await suggestions on how to clean it up.

i just noticed that the 'tachcount' started over twice. both times occurred at a trigger- event. and the RPM blips to zero at one of them. sure can't see or feel any dropouts while operating fuel only and watching the MT screen. when driven normally, these really don't occur.... just went jabbing at accelerator in neutral.

There were no processor resets, but there were at least 2, maybe 3 ignition resets. The tach Count will reset to 0 at each ignition reset, and when it gets > 65535 counter overflow. Plus there are missing triggers. I don't know if the missing triggers are causing the missed outputs, but they shouldn't - they should only be caused by ignition resets. So if there are more than 2 or 3 instances of missing outputs, then there is a more serious problem. To check this I will need your msq and an idea of the rpm range in which missed outputs are most likely to occur.

Al-

I'll record a new session both on datalog and on scope at same time to try to overlay it.

For now, attached is the msq.

Scott.

Would high RPMdot values from aggressive throttle blipping have an effect?

i'm not familiar with RPMdot. i'll read up on it.

i did a 1 minute recording with scope and datalog at same time.

if you have hobbylab software loaded, you can scroll through the scope data: http://www.mediafire.com/?tjinmjyyzjj
here is the datalog file at same time: http://www.mediafire.com/?omnimqmxeti

on the datalog, there are zero processor resets, and only one ignition reset (RPM blips to zero, but tach count never resets). this one ignition reset occurred at cranking when it fired and went from cranking speed to idle speed.

i think there is about 115.0 second difference between datalog time stamps, and scope time stamps. actually it starts at 115 difference, and changes slightly throughout. here are the errors found by scrolling through the ignition scope data:

1) datalog time stamp 117.4 at very beginning of recording, where the trigger- shows up. strangely, during this error, there is a dwell period of 20ms, where max should have been 5.5.
2) time stamp 125.6 just prior to acceleration, at RPM 780, there is a bad sequence, no error shows up on datalog: .....red,blue,skip,red,blue,blue,skip,red,blue,skip....
3) time stamp 127.7at RPM 2400, just prior to next ramp up, there is the same type of bad sequence with no error on datalog
4) from 128.0 to 128.4, through the peak of the accel, there is funky noise flanking the dwells (see the middle scope picture previously shared)
5) time stamp 134.9, at RPM 1765, same bad sequence with 2 blues in a row
6) from 147.3 to 148.1, through peak, there is the funky noise flanking - same as #4 above
7) time 150.3 there is a bad sequence, but this time with 2 reds in a row - this is immediately prior to an accel
8 ) 152.3 another bad sequence just prior to an accel
9) through the peak at 152.8 another bad flanking noise period
10) through peak at 160.6, there is flanking noise AND a bad sequence
11) for nearly 1.0 second through the peak at 169.6, there is flanking noise
12) multiple bad sequence at about 170.9 (no sudden TPS changes surrounding error)

there may be other errors in the recording that i missed.

i think it's possible that bad sequence errors are a result of inputs to decoding algorithm, or something non-hardware related. BUT... the crazy flanking noise seems to show up at higher revs when the end of one dwell is close to the beginning of the next cylinder dwell. there were a couple instances where it went through these periods without noise showing up, but for the most part, the signals get really funky right around 3k rpm when the dwells get close. and, the occasional really big dwell times are a concern.

i'm not familiar with RPMdot. i'll read up on it.

I just made it up using the MS naming convention (TPSdot, MAPdot.) It is dRPM/dt, calculated as RPM2-RPM1/T2-T1. Then I fed it into MLV and produced the graph attached to my post. I just wanted to take a look at how fast the RPM changed as you blipped the throttle, theorizing that high RPMdot's and 60-2 wheels might cause the Sequencer to get confused if its expectations of the time of arrival of the next tooth were way off.

It's not like I know what I am talking about ...

Brian

Brian-

I think that's a good suggestion to look at it like that. It seems that the problem of a bad sequence would likely be tooth decoding issues - whether or not it's how fast the teeth are going, or the decode algorithm, I wouldn't know. I'll try suggestions of tweaking the algo variables.

But.... the 'flanking noise' seems to be a separate issue. When I had the seq on my Pontiac, it has a 36-1 wheel, and similar noise popped up on ignition signals.... kind of looks like one of the ign signals is picking up, and acting on a change from another signal. Isn't it peculiar how the short 'flanking' signals are the exact width between where the missing dwell would be (wasted ign #5 & #2)?