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

TheMonkey wrote:Al-

I appreciate your attention on this, and I will do my best to respond with diagnostics as you come up with thoughts on how to solve this.

Next couple days, I will report back with some comments on whether misses only come after warmup, and also on the higher RPMs.

If you come up with any new diagnostics in the ini file, I'll toss those in.

Thanks,
Scott.

Hi Scott,

Like Al indicates, when there is extra noise spikes it is one thing. In this case there are missing pulses. This can come from loose connections, ground issues, solder joint (I have seen this before), etc.

Since you are not intimidated to try out new ideas, here is something to try. Grab a headset stereo jack (I think these are 1/8"), the ones that you can plug into the microphone jack of a PC. I use a old headset and chop off the headset part, leaving the wire. If you strip the outer covering you will see a shield wire and two inner conductors. There are two because of the left-right channels.

What I would do is hook one of the channels (solid wires) to the output of the opamp on the MS circuit, and the shield to MS ground. Then plug this into the mic input on your computer.

Next, download Audacity and tell it to record, then run the engine. When you observe the miss, stop recording. You can then zoom into the datalog in Audacity to see if the miss is coming from the VR pickup+circuit.

Now, for 5-volt signals I have hooked up the mic input direct. But, there could be a chance that the signal (5V) is too much for the soundcard input. So you can make a simple voltage divider. I would take a 1K resistor between the solid conductor and shield, and a 10K resistor in series of the solid lead and the op-amp output. Also, do not run any serial cable b/w the computer and MS during this test because there could be a potential difference b/w serial cable ground and sound card ground.

- Bruce

New datalog... Here is my experience from tonight...

Through my file updates, I seem to have lost my smooth startup from cold through warmup. Motor is oscillating for the first couple minutes which I'll sort through, so don't laugh at my datalog

I'm getting good at swapping between hardware setups. The end of my tach pigtail can plug into distributor VR or crank VR now.

Check out this datalog http://www.mediafire.com/?c21vei1sveg

Pretty much had no trigger misses using my crank trigger wheel decoder tonight, so I couldn't get any real answer on repeatability issues. RPM never blipped to zero, but a couple other curious things.

I had a hard start, and the trigger +/- counted down to -2 when the motor died and hiccuped at first start attempt. after motor started back up and warmed up, i had to fiddle with idle screw and VE values so idle was a bit rough for a bit. i had no misses, but at time stamp 517, trigger+/- counted up one to -1 and stayed there until completion of the test.

Strangely though, tach count reached 65,535 then reset to zero during the middle of the datalog.... without any apparent misses?

Thanks for any help.

Kris- Thanks for the idea. I did take a look at time & % masking, and did even fool around with it, but that seems to be more of a tool to combat noise (extra tooth) rather than a missed tooth, but I am still learning....

Front of my car is off and I should have the timing cover off tonight ready to take to the workshop. With any luck i'll be running next week.

Looking at your logfile, should the TPSdot be that noisy with a relatively steady state throttle position?

Bruce-

I just now saw your note on this, and your idea on recording.

Couple questions....

- I built the audio cable with transformer to use the crank wheel pulser program. Could that transformer be used in reverse to record to accomplish the same thing as the voltage divider you described above? I"m not sure about the difference between a transformer and voltage divider.

- Also... could I use both the left and right channels to record the VR signal and the opamp output signal to see them side by side? I've never used Audacity, not sure if left n right can be seen individually.

Thx.

krisr wrote:Front of my car is off and I should have the timing cover off tonight ready to take to the workshop. With any luck i'll be running next week.

Looking at your logfile, should the TPSdot be that noisy with a relatively steady state throttle position?

at times, this project has felt like i am trying to herd cats. i see what you are saying, and it seems that my TPS has become noisy, while this miss seems to have taken a break.

BUT... i suspect that that the return of the TPS noise could be 1 of 2 things:

1- in an effort to clean up TPS, noise i ran shielding, and routed the TPS wires by the cart away from other wires. so... hooked my foot on them on several occasions in the last few days. i think i have pulled on the twisted connections. i have found that these connections, and grounding really affect TPS signal. last time i cleaned them up, there was zero TPS flutter and then i went and tripped on them like homer simpson.

2- i just hooked my o2 sensor back up and that seems to be noisy, but i would think that the noise filter into MS would be cleaning up the power now. but on the ground side, the heater and controller are grounded with MSII. maybe i'll ground the sensor heater ground directly to battery, and ground the controller with MSII to try to clean that up more.

Kris-

Here is a file with perhaps the best display of zero TPS flutter, and also the ignition misses. This was right after I reconnected the TPS connections, and refitted soldered lugs to ground. unfortunately, the ini file was previous version without 'tach count' or 'trigger+/-'.

file: http://www.mediafire.com/?vinxblyilmz

** edited to add: ** this file was right after I put the o2 sensor back on, so the misses in tonight's file must have been from tugging on the wires. or something else... this project has been full of surprises.

Scott.

TheMonkey wrote:New datalog...

Strangely though, tach count reached 65,535 then reset to zero during the middle of the datalog.... without any apparent misses?

The tach count was intended only to allow some correlation between cylinder events and the recorded data. At cranking rpm you might see the tach count stay the same for 2 or 3 lines, so you know that data in the middle is all from the same cylinder event. It is a 16bit number, so it always overflows and resets to 0 every time it pass 65535, which is 16 1s. This is a cpu limit and doesn't mean anything.

thx for the explanation on the tach count reset Al.

sounds like i need to determine if the missing pulse is occurring before the processor, or in the coding.

i will determine this and report back in the next several days. Bruce's suggestion on recording is the right approach, but i should just figure out how to get my scope to record. i think i just need to dope down the settings so that it will signal plot on my old laptop.

wouldn't pin 36 show the miss? i'm thinking that pin 36 will be easy to spot the miss and plot that against the VROUT signal to the processor and see what that looks like. or is there a better approach? i have 2 channels on my scope.

Scott.

A mis-fire on the output side wouldn't show up in the logs as a complete loss of RPM I would have thought.

krisr wrote:A mis-fire on the output side wouldn't show up in the logs as a complete loss of RPM I would have thought.

- IF the miss is before the processor, the miss will be apparent in the square signal to the processor.

- BUT, if the square wave into processor looks okay, and the miss is in the coding, where can i probe the scope to see where the miss happened? i was thinking that the signal on pin 36 signal would go away until re-sync unless it is able to re-sync immediately?

Yeah good point, I think If you can probe both IRQ and IGN pin's at the processor and log them when it misses, it will tell you which one is the culprit I guess.

The funny thing is though, I had experimented with the MS2/Extra code at one stage and I even had losses of sync using that code too, which is why I was certain my issue was on the IRQ side of things.

I'm determined to find it. I figured out how to record on my scope. Turns out my laptop is just too chunky which made for frustrating attempts. I loaded up on my desktop and the recording function is really amazing; whole new nerdy world. My wife splits town Friday so I'll haul my desktop into the garage and poke around with the scope this weekend. Heck... wife splitting town , I'll haul my sofa and ice box into the garage too!

I love my wife but I heard a funny joke.... actually a test... if you lock your wife and your dog into the trunk of the car for an hour, which one do you think would be REALLY happy to see you when you open it back up?

TheMonkey wrote:I'm determined to find it. I figured out how to record on my scope. Turns out my laptop is just too chunky which made for frustrating attempts. I loaded up on my desktop and the recording function is really amazing; whole new nerdy world. My wife splits town Friday so I'll haul my desktop into the garage and poke around with the scope this weekend. Heck... wife splitting town , I'll haul my sofa and ice box into the garage too!

I love my wife but I heard a funny joke.... actually a test... if you lock your wife and your dog into the trunk of the car for an hour, which one do you think would be REALLY happy to see you when you open it back up?

Glad to see you got the scope nailed. I'm going to have to order one of those for my toybox!

Scott,
With the faster PC, the burst mode for the logging may be worth revisiting although the scope with some fancy triggering will probably be more useful.

- Charles.

If you were to completely replace the whole MS with an identically built "other" Megasquirt, do you think the problem would continue?

At this point I'd be considering a Saturday afternoons' overtime and get the credit card out... only so much it's *worth* investigating?

...unless you enjoy the build over the drive I guess...

good luck anyway - it's tricky with persistent probs, I hope you sort it soon

RB

I feel like a just took a picture of the lochness monster....

Signal to the processor looks good. 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 (?).

i was about to give up trying to capture a miss, but then i caught it perfect. i started a datalog and captured one miss. datalog: http://www.mediafire.com/?jdcyjnyndnl

pics show probes hooked up to VRIN (red trace) and TSEL (blue trace).

my scope just started recording 11 seconds before the miss. i have saved the data both as a binary bitmap file which my scope software can open up, or a 7 meg txt file with the data. but, i'll share some pics. if anyone wants an email of the data, let me know.

my IAC is programmed to open at a reset and tapers back for 3 seconds. when a miss happens, the motor idles steady, then all of the sudden hiccups and then speeds up from the IAC opening. i'll share a series of pics where i'm sure the miss occurred; 8 pictures each showing all 36 teeth. i was also able to measure exactly the time between the first trigger rise after missing tooth (left of each pic) to calc RPM for that rotation.

I now suspect the code, as there does not seem to be anything wrong with signal to processor? Interestingly, there is another thread in MSE with a ign miss problem that only occurs with MS2 installed, MS1 is okay. i don't have an MS1 chip to test. This is kooky. I hope we can solve this.

I have tried different settings on masks, and tolerances. There must be some kind of trace that can be tracked in the code to determine why it is not accepting one of these pulses?

I would guess the miss happened in Pic 3; casually overlaying the RPM pattern on the datalog from MT compared to scope pics & idle calcs would suggest it prob happened in pic 3:

* note that time stamps on scope don't match the time stamps from the datalog because the recordings started at different reference points. but, i suspect that the miss happened at about 11.4 - 11.7 on the scope, and on the datalog it shows up at 50.861.

11.184-11.261 No Pic RPM 779 ...idle
11.261-11.336 Pic 1, RPM 800 ...idle
11.336-11.406 Pic 2, RPM 857 ...idle
11.406-11.485 Pic 3, RPM 759 ...miss
11.485-11.578 Pic 4, RPM 645 ...causes slow down
11.578-11.690 Pic 5, RPM 536 ...still slow
11.690-11.803 Pic 6, RPM 531 ...even slower
11.803-11.895 Pic 7, RPM 652 ...IAC opening - speeding up
11.895-11.970 Pic 8, RPM 800 ...more air through IAC

11.261-11.336 Pic 1, RPM 800 ...idle
http://img402.imageshack.us/img402/8787/skip1cr2.png
11.336-11.406 Pic 2, RPM 857 ...idle
http://img440.imageshack.us/img440/9810/skip2ji7.png
11.406-11.485 Pic 3, RPM 759 ...miss
http://img413.imageshack.us/img413/9089/skip3ya1.png
11.485-11.578 Pic 4, RPM 645 ...causes slow down
http://img204.imageshack.us/img204/1260/skip4cf5.png
11.578-11.690 Pic 5, RPM 536 ...still slow
http://img204.imageshack.us/img204/280/skip5tt9.png
11.690-11.803 Pic 6, RPM 531 ...even slower
http://img254.imageshack.us/img254/8515/skip6px5.png
11.803-11.895 Pic 7, RPM 652 ...IAC opening - speeding up
http://img100.imageshack.us/img100/8756/skip7xs3.png
11.895-11.970 Pic 8, RPM 800 ...more air through IAC
http://img187.imageshack.us/img187/6582/skip8zh5.png

red_baron wrote:...At this point I'd be considering a Saturday afternoons' overtime and get the credit card out... only so much it's *worth* investigating?....

RB- i hear you. but... there is a certain element of problem solving that is satisfying. i think that's why most of us opted for DIY. if i were doing this from a $ standpoint, then my time sure isn't worth very much (granted, even with the DIY warnings, this is requiring more time than anticipated). now that my car gets back from body shop this week, i hope i don't get impatient, but at least i can just plug in the distributor VR trigger with no troubles (i think, hope). it's also not clear that the hardware is the problem...

scope data sure has a lot of info.... it opened right up in excel. spark was at 26*, so it was pretty easy to locate ignition events. looking at the RPM levels as calculated from time between each tooth, i'm thinking that the miss could have happened in pic 2, and not pic 3. and if you look at the blue signal above in pic 2, there is maybe a little nugget of noise? but... IRQ has a substantial amount of hysterisis built in, and any noise seen on the scope seems to be tiny.

seems reasonable that the last ignition event before the resync could have been either at 11.372ish or at 11.389ish. that is where potential noise exists on the IRQ signal, but i really think it's in the decoding or something else.

i suppose i could go back to idea of probing pin 36 to know which spark events occur, but the point is, signal seems to be okay.

http://img169.imageshack.us/img169/2249/ignmisswz7.jpg

kind of interesting pic with bigger picture. obviously i'm a bit bored with the family gone...

thought it might offer some info though... looks like it went 2 rotations without resync, and then reengaged after 3rd missing tooth.

Hello Scott,
Given that the Vr input to the VrOut/Tsel jumper looks clean, it might be interesting to look at Tsel and JS10/Igbtin jumper ( leg 1 of Q16, vb921 coil driver) when MS-II is configured to drive vb921. Becareful probing that point, as it goes directly to the microcontroller - don't want to blow up a port. The resistor you used for the VrOut/Tsel may be useful. On probing VrOut/Tsel, I was a little surprised that probing directly would have an effect. Do you know what the impedance of the input section of your scope is? To avoid the loading problem, you could just probe VrOutInv, which is just a buffered inverted version of VrOut. I'd do this, as the scope probe loading can effect a circuit's performance as you have already seen. I doubt that much will be seen, but who knows? Looking at the pulse deltaT's in both signals may give a clue. If nothing else, it should give a good view of into the controller out of the controller.

- Charles.

FixItAgainTony wrote:... it might be interesting to look at Tsel and JS10/Igbtin jumper ...

captured another (blue TSEL, red JS10 jumper)



same one, zoom out: