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

MSII v3.0 2.883j

thanks for the help so far. i need a fresh look.

i have a 36-1 crank wheel with a Ford VR sensor going through the VR circuit on the 3.0 board.

PROBLEM: just sitting at idle, steady state, the RPM will blip down to zero. ECU does not reset, only RPM blip to zero until next rotation resync.

VR signal at idle: http://img231.imageshack.us/img231/5979/37vpq7.png
AC in Power bus before & after noise filter (blue before, red after): http://img254.imageshack.us/img254/1920 ... er2oi6.png

things i have tried:
- tried several combos of the wheel setup - rising edge works the best (that correlates with steep edge of VR)
- 'twiddling' the pots, R56 & R52
- adjusting sensor in & out
- replaced VR sensor
- removed everything from power bus except for ECU & fuel pump.
- installed smaller traditional coil instead of strong u-core coil
- installed large electrolytic capacitor on CDI ignition to reduce noise
- bypassed CDI ignition and used direct fire from MSII
- installed high quality noise filter into power line going to MS.
- double shielding on VR wires - first is negative side in coax grounded at MS, second is a braided sheath over the coax, grounded at block.
- prediction algos, tried both last interval and ABG
- time & % mask adjustments
- adjusting next pulse tolerance to a large & small amount
- negative signal from VR into spare pin on DB37 and directly to collector of Q22 to avoid any extra noise on ground plane
- installed 10k resistor from VRIN to ground
- reinstalled firmware
- removed unused flyback circuit since i use Hi Hz injectors
- touched up all the solder joints in VR circuit
- touched up all solder joints on entire board
- cleaned and recleaned PCB board
- soldered all lugs in any wiring

seems that no matter what i try, RPM insists on dropping to zero occasionally.

what else should i try? any suggestions will be appreciated.

here's a short file showing a single miss. i cannot figure out how to look at timingErr, as it is not on my datalogs and i can't figure out how to get it on there. i don't think it's prediction problems anyhow because it happens in a steady state idle, as you can see in deltaT, it's a predictable environment.

It looks like you have a laundry list of things you've tried... Compared to engines I've scoped, your signals look fantastic. I have a hard time believing that's where your problem lies. Do you have both channels scoped during an RPM drop at all? I'd be very curious to see if the VR in/out changes at all.

Aside from that I'm very green on the MSII, but it does seem that the MS1 processor is a little more forgiving, perhaps due to a little better code maturity at this point.

Also, I've used megatunix for MSIextra to monitor run-time trigger and tooth events and it's worked well for spotting problems. But I don't think anything comparable exists for MSII at this point.

Also, OT what scope software/hardware are you using. I've been wishing for a dual channel scope after owning a single.

Good luck!

i think it would require an extraordinary amount of luck to capture the miss on the scope. but i have tried.... i think there is recording capability for the scope but i'm not sure how to use it.

i also don't think my problem is my signal.

FYI... scope is the hobbylab scope. plenty fast enough for automotive stuff and priced right: www.hobbylab.us

I'm no expert on 'scopes, I have a Velleman HPS10, which does about a million things I can't begin to understand...

If you change your period to a couple seconds or more you should be able to see if there is a miss in the VR... looks like it might have enough resolution for that, mine does if you zoom in on the LCD, or hook it up to laptop. Until you can verify that you have all your teeth on the scope it's going to be hard to figure anything else out I think.

I also agree that with how clean your signal looks I have a hard time believing that's the issue...

Hey Scott, try back flashing the firmware a couple of revisions back. Oddly enough when I flashed to 2.883j I noticed the TPS seemed to be a bit noisy and trigger AE alot but that could have been that .ini descrepancy where it messed around with the v/sec triggering.

I still haven't been bothered to fix up my timing cover yet so I can't really run my car for more than like 1 minute as it's got no water.

Maybe see if something is intermittant on the board.
Get a piece of 1/4" dowel to tap on the pc board while it's running. Also tap on the db37 connector shell and other devices.
BTW, if you eat chinese food, chopstick makes a great 'test stick'

Also, you should be able to turn R56 CCW until it clicks and then CW two turns.
If the car no longer runs, R56 is installed backwards and you'll need to reverse above directions.

Kris- sorry about your timing cover probs. y, i had your TPS AE settings from your MSQ and i think the new code was magnifying them by a factor of 10. for now, i have turned off AE entirely until i find my miss. BTW... i found that soldering my ground wires to the lug rings got rid of my TPS flutter nearly entirely, even through cranking it doesn't move.

if i do a code reversion and it works, i suppose that will tell me if it's code or hardware.

Peter- good idea on tapping. i'll try that. although, my ECU sits on a cart to the side of the motor so it doesn't rattle around at all, but i'll see if i can aggravate it.

CDW- y, i can slow down the scope nicely and see several revolutions of the toothed wheel in one pic, but..... i think i would have to record the data in order to capture the miss.

Peter Florance wrote:...
Also, you should be able to turn R56 CCW until it clicks and then CW two turns.
If the car no longer runs, R56 is installed backwards and you'll need to reverse above directions.

yes, i have used the circuit with R56 turned in 2, 4, 6, 8 turns. everything works the same. same with R52. the pot adjustments seem pretty forgiving with my signal.

in fact, i have built an entire extra VR circuit on a breadboard and tested the behavior and polarities to make sure the one on my board is set up proper.

something that is making me think it might be something hardware related, is that sometimes the miss is more frequent than others during similar running conditions (which is just idle).

reversion to 2.687 did the same thing... idle was rougher for some reason with 2.687, but the miss did end up happening. i tried tapping around to aggravate it, and that did not do anything. i put dielectric grease betweer the db37 connectors and tapped around. with the case over the top of MS, i rapped the case a couple times with my knuckles to try and get a miss, but it just does it on it's own time, when it wants.

here's a question: would it make a difference if i run it without the db9 serial cable hooked up? is it possible the laptop is sending in some funk? only thing here, is that i can't datalog while this is going on.

** edited to add: ** removing db9 did not make a difference. i have the IAC cranking position programmed to be open a bit, so i can hear revs increased at a miss during the IAC taper.

Have you tried datalogging with the lastest ini file for 2.883 code. This has a trigger+/- output that counts up if a noise spike comes in and counts down if a tooth is missed. This might be helpful.

grippo wrote:Have you tried datalogging with the lastest ini file for 2.883 code. This has a trigger+/- output that counts up if a noise spike comes in and counts down if a tooth is missed. This might be helpful.

Al- yes, on my latest revisions, i found this data. however, i'm not having a problem finding when it happens, as much WHY it happens, and the data in the datalog doesn't seem to offer the explanation.

today, i wired my VR circuit to the distributor VR sensor. there are no misses at all when triggering from this. makes me suspect that it's something in the wheel decoding.

i'll be anxious to hear back from Kris when he sorts through his timing cover how he sorts through this. we have very similar setups. are there many people using the wheel decoder successfully through the VR circuit?

thx, Scott.

I'm going to pull the front of my car & engine off tonight and hopefully have the water jackets bored/sleeved during the week. Remember in the early days I mentioned that I had issues with that HVC2 coil?? Have you tried just a normal oil filled Blaster coil at all?

krisr wrote:....I had issues with that HVC2 coil?? Have you tried just a normal oil filled Blaster coil at all?

I took off the HVC2, and currently have the Blaster3 on there. Blaster3 is traditional oil filled, round canister type.

TheMonkey wrote:
Al- yes, on my latest revisions, i found this data. however, i'm not having a problem finding when it happens, as much WHY it happens, and the data in the datalog doesn't seem to offer the explanation.

thx, Scott.

Is the extra/missing pulse counter counting in the data log or is it staying at 0 ? Is the count going up or is it negative ?

Also, how long does it take between misses - on average ?

If you raised the rpm would it occur more or less often ?

grippo wrote:

TheMonkey wrote:
Al- yes, on my latest revisions, i found this data. however, i'm not having a problem finding when it happens, as much WHY it happens, and the data in the datalog doesn't seem to offer the explanation.

thx, Scott.

Is the extra/missing pulse counter counting in the data log or is it staying at 0 ? Is the count going up or is it negative ?

Also, how long does it take between misses - on average ?

If you raised the rpm would it occur more or less often ?

Al-

here's a datalog to take a look at w/ trigger +/-. yesterday, i reflashed again with brand new firmware 2.883j, new ini file, and i built an MSQ from scratch. it went up to nearly 11,000 tach counts before it reset tach count to zero, and started missing some occasional teeth, maybe every 5 seconds or so. as you can see, everything was in pretty much steady state without any TPS movements or anything. can't be seen in this file, but anecdotally, the miss seems to not care about RPMs.

on thing interesting, is that it seems that there have been several instances where it warms up for awhile without any misses and then they begin to occur. a clue?

Scott.

This tells us a lot - it says the processor is missing teeth detections - not getting noise in. I have a fair amount of confidence that this is true, because all the code does is calculate the times between teeth and compare them with the last one. If one is out of tolerance too long, then it counts down as a missing tooth, and if too short compared to the previous, it counts up as an extra tooth. In your case there were 12 downcounts - it never went up. It does take into account missing teeth. Let me think on what might be the problem and talk to Bruce and see if we can't come up with additional diagnostics that I can put in the code.

As far as it just starting after the car warmed up, this would be significant if it was consistent. Also variation with rpm - if you could repeat this run but once the missing pulses start can you hold it steady at say 1500 rpm or more for a few minutes ? If you have already done thi and gotten misses, then there is no sense in repeating it.

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.

TheMonkey wrote:

grippo wrote:Have you tried datalogging with the lastest ini file for 2.883 code. This has a trigger+/- output that counts up if a noise spike comes in and counts down if a tooth is missed. This might be helpful.

Al- yes, on my latest revisions, i found this data. however, i'm not having a problem finding when it happens, as much WHY it happens, and the data in the datalog doesn't seem to offer the explanation.

Did you see this data with the megalog viewer ? How ?

Thanks

nyabinghi wrote:
Did you see this data with the megalog viewer ? How ?

Thanks

just showed up in the log file after updating firmware to 2.883j & the most recent ini file.

Hey Scott, another thing I remembered when I switched to missing tooth wheels after looking at the manual again that you may want to check for sanity sake:--

In the code are two input variables to control the interrupt masking to prevent false triggers:

Time Mask, (ICISR_tmask) time (msx10) after tach input capture during which further interrupts are inhibited to mask coil ring or VR noise, and
Percentage Mask, (ICISR_pmask) percentage of the predicted interval before the next tooth (dtpred) after tach input capture during which further interrupts are inhibited to mask coil ring or VR sensor noise.

These are called the time mask and percentage mask, respectively, in the ignition options dialog of MegaTune. For wheel decoding you must use values close to 0.2 ms and 10%. However, to not break any existing setups, the default values are 0 and 50%, the same values hardwired into pre-v2.5 code. Be sure to adjust these values when you set up for a trigger wheel (note that they are in a separate dialog from the trigger wheel settings).
In addition to the above settings, you should set:


Predictor Algorithm to last interval, and
Predictor Gain to zero.