sync loss on duratec 3.0

[srb94]

Noob alert, but I have done lots of reading. I have found lots of information but it appears that either I have missed something or it is not quite correct. I think I am posting in the correct place and uploading the necessary data but please feel free to correct me if I have not done something as needed.

My problem is that I am getting sync loss reason code 2. Engine starts fine even though there is lots of tuning to go. Ford Duratec 3.0 V6 w VVT (VVT not active at this time but would like to tackle down the road). At this point just wanting to get a solid running base engine. it is setting in a 1990 Miata and seems to have lots of torque on the little it has been driven to date.

Basics of the install are as follows:

Using stock engine harness with large connector to interface to MS
MS3X from DIYAutotune last summer
Semi-sequential fuel
Narow band sensors on both banks
No ISC implemented yet
VR crank and cam sensors
Crank sensor wire shielded
Cam Sensors don't appear to be shielded on engine side, used twisted wire on MS side
Wasted 2 wire COP (built my own driver box)
D24 is already 1N4748
R45 is 10K (but I tried adding 15k with no improvement)
R56 full counter clockwise per assembly instructions
R52 full counter clockwise per assembly instructions (tried up to 6 turns with no improvement)

I think that is it, but may have missed something. The engine revs fine if throttle is increased slowly but if you stab the throttle there is popping in the exhaust, but you probably could have guessed that by the subject line. Interestingly a moderately quick throttle opening does not find a problem. All of this is while setting in neutral. On the street it seems to be load dependent which made me think noise from ignition, but with COP this is less likely.


I was not able to figure out how to set up MegalogViewer or TS to display the sync error count or composite logger. If that is needed and someone wants to point me in the correct direction I am interested. Sure I will figure it out eventually. Otherwise let me know if I need to supply any more informaiton.

[srb94]

Sorry, forgot to also post that I am using firmware 1.0.2.

[Matt Cramer]

Sync loss 2 usually means you either need a 10K to 20K resistor inline with the sensor positive wire (common on high tooth count wheels) or need to adjust the VR trim pots. See this article for details.

http://www.diyautotune.com/tech_article ... _index.htm

[srb94]

Matt,

Thanks for the reply. I had seen that R45 was already 10k as opposed to 1k, but also added 15k with no improvment. I also had tried pot R52 up to 6 or 7 turns as I had seen on another thread or on the site, but no help there either. No problem to go further but didn't want to creat another problem down the road with some other parameter getting out of whack. Is there a range on R52 that I should not exceed????

I also was concerned that the problem seemed to be worse if I stabbed the trottle. If you increase moderatly it will go much higher before the problem shows up. Most of the other posts I read seemed to deal with more consistent issues but they may be the same as mine. Hope I attached the correct log file that shows both accel rates but it was getting late and I may have missed it. I also was not able to get the sync error count to display in MegaLogViewer.

I also have the zeal board bringing in one of the cam inputs to JS10, but have not done anything with it in TS yet.

Thanks again for the reply,

Steve

[Matt Cramer]

Please post a tooth log of the loss of sync.

[srb94]

Matt,

It was a little difficult to get the logs I think you needed. It was late when I got home and I didn't want to disturb neighbors that get up very early, but I think I have something useful attached. Due to the time I did not let it warm up fully and noticed that the miss was not as bad, but still there. Could have been a coincidence, or new data.

Please let me know if there is something else that I can provide (obviously) or if you need more data. I should have some more time tomorrow evening but that may be it for a few days. I hope to get some time to attempt more adjustments on the hysteresis this weekend if you think that will be useful at all.

Steve

[srb94]

Also had another idea overnight. Have not had a chance to look at the logs yet but is it possible that the A/F ratio is going to lean (or rich but I doubt it) and causing a misfire that leads to the sync loss. I have not been able to do much calibration work in the map areas with more engine load. Just a thought. Would appreciate any comments.
Steve

[Matt Cramer]

Page 3 of the tooth log looks almost exactly like this illustration:



Classic example of a phantom tooth. This is usually cured by either a larger series resistor or a higher voltage threshold for triggering.

[srb94]

No luck, still there. I saw that one from your website and in other docs before I posted, and as a result I did some adjusting on the hysteresis, but really wasn't sure what the limit would be. Tonight I tried increments up to 15 turns, which I believe is essentially all the way. I also tried increasing the trigger level, but it got so far that it would not trigger on crank so I had to back off.
Unfortunately, I still have the problem even with the addition of the 15k resistor in series with sensor. Am considering adding some capacitance across the VR sensor but not able to give it much serious thought to try it yet. I want to look at the schematics first. Also still thinking it may be that I am going lean at this particular loading condition, but not sure this would cause the problem. Unfortunately have not been able to spend the time with it I would like to but still being persistent.
Attached are some more log files of tonight's results. The tooth logger looks different than before. I also have an .msl file taken at the same time, but the data is at the end and it exceeds the file size limit. I can email it separately if desired. I have included a screen shot in a word document for posting. Suggestions for next steps?

Steve

[Matt Cramer]

Ok, now you're getting one or two short noise pulses away from the missing tooth as well as not seeing the missing tooth. I'd see if I can shield the wires better.

[srb94]

Lots of time has passed and lots of things have been tried to no satisfactory result so far. In addition to re-routing, shielding, isolating, etc., have also tried ferrite beads (inductance) on the ground of the ignition module to keep a spike/transient from transmitting to the MS ground. So far nothing I have tried has had any impact at all, either in the running of the engine or on the scope.
Eventually I went ahead and decided to just drive it some and let it tune the VE map some. I have maybe discovered something that is related. If the VE table is off far enough to cause misfires can that cause a sync loss with a cause #2 to be logged? It seems that the closer the table is getting the less sever the problem is. It's not totally gone, but the table has a way to go yet. Some points in the heavier engine load area have moved from ~100 to ~80, or some similar percentage. I also played with the limits of when it would allow closed loop and that also seems to be generating a better table so far. Eventually I will need to go back to the open loop WOT scenario but for now I need to make some progress.
Thoughts?? Am I on to something or is it just coincidence?

[billr]

Like you say, it's been a while... how about posting recent .msq and .msl files? Sync shouldn't be related to engine load or speed, that would indicate you still have a problem with the crank/cam sensor systems.

[srb94]

No problem to post files, but nothing has changed but the VE table and EGO control settings since the last ones and it was more of a rhetorical question. I agree it points to a problem with the crank signal, but looking at the VR sensor output with a scope it looks nice and clean. Setup is semi-sequential, COP wasted spark, no cam sensor input yet (will need VVT work to be done on code), ms3x.
All of the work since the last data posting has been outside the software (and MS for that matter) other than looking at signals. The msl files I generated today exceed the 1 mb limit for uploading so i trimmed one down in excel. Seems to open OK. Unfortunately the car is back on jack stands working on a suspension issue so it may be a bit before it goes back on the road for more data like this. Interesting to note that there are now many times where I was able to get above 3500 RPM with no sync issues where before that never happened. That was why I asked the question.

[srb94]

Any thoughts from more experienced tuners? My thinking was that if the misfire caused enough change in engine speed instantaneously it could cause a gap between teeth to be significantly longer than the gaps between the previous teeth. This could appear as a missing tooth depending on how the code discriminated the differences and rate of change. Since I have been moving the VE table leaner in the outer regions it seems to be getting better and I am looking for an explanation.

[jsmcortina]

Please add AFR to your datalog (you do have a wideband - right?)

James

[chango de naranjito]

I still have the problem even with the addition of the 15k resistor in series with sensor.

In my case 22k in series was the magic number...

[srb94]

OK, work has been in the way of progress but I have made some. Seemed obvious once I had seen what I had done. The vehicle wiring was two wires in a shield for VR sensor. The MS harness was a single shielded wire. I connected the center MS wire to the signal wire from the VR sensor, and the MS shield to the vehicle sensor return wire. Then I grounded the vehicle shield to the MS ground. Makes for some interesting ground loops. To resolve the problem (at least so far) I ran a second sheilded wire from the MS ground to the vehicle harness, connected the center wire to the vehicle sensor return wire and connected both MS shields to the vehicle shield. Seems to be working correctly now, at least from what I can tell.
However, somewhere in the process I have come up with an error on Tunerstudio when I go to VE live. I get an "Error setting gauges, check log for detail" message but cannot find the log being referenced. If I hit OK, and continue, everythign seems to work fine but still don't like the message. Will continue to look and post separately if I don't find it.
Boy I wish I could get the time to work on this steadily. Maybe things will get better sometime this fall.

[1uz_nissan]

OK, work has been in the way of progress but I have made some. Seemed obvious once I had seen what I had done. The vehicle wiring was two wires in a shield for VR sensor. The MS harness was a single shielded wire. I connected the center MS wire to the signal wire from the VR sensor, and the MS shield to the vehicle sensor return wire. Then I grounded the vehicle shield to the MS ground. Makes for some interesting ground loops. To resolve the problem (at least so far) I ran a second sheilded wire from the MS ground to the vehicle harness, connected the center wire to the vehicle sensor return wire and connected both MS shields to the vehicle shield. Seems to be working correctly now, at least from what I can tell.
However, somewhere in the process I have come up with an error on Tunerstudio when I go to VE live. I get an "Error setting gauges, check log for detail" message but cannot find the log being referenced. If I hit OK, and continue, everythign seems to work fine but still don't like the message. Will continue to look and post separately if I don't find it.
Boy I wish I could get the time to work on this steadily. Maybe things will get better sometime this fall.

The VR wire should be a twisted pair inside of a shield. One inside to signal, one inside to ground - both on the vr sensor. The shield should be connected to nothing on the sensor side, and to one of the ms ground pins on the other side. Twisted pair helps cancel any noise, shielding helps stop the noise in the first place.

[srb94]

I agree from my past experience that is the conventional way of installing VR sensors, but being new to MS, I was assuming (yeah, I know the meaning) that what was supplied with the kit was how it was supposed to be connected. My error for not catching it sooner. I tried this alternative so as to not have to rework the connector, but if problems recurr that is what I am going to do. For now it seems to work fine, or at least much better than before. Can drive the car and load the engine up to almost 6000 RPM with no problems.
I definatly recommend twisted pair for the entire length with a shield around both. In fact, I am told by some on the OEM site that you may be fine with just the twisted pair, but he shield is recommended for robustness. The only way to go in my opinion.
Now on to the log error and strating to work out the other control issues (VVT and IMRC) for the engine.

[srb94]

Decided to correct the wiring and go to the shielded twisted pair in case my interim solution caused problems later. It appeared to be working OK but I knew it was not totally correct. I had some audio cable that was twisted 3 conductor (very fine wires but workable) in a shielded cable. I thought it looked appropriate, although I was really wanting something with larger conductors for better mechanical reliability, but decided to use it anyway.
Unfortunately the lost sync error appears to be back. The reason I say apparently is that the SD card failed to capture the log data I was looking for, I will have to look into that tomorrow evening if I can get the time. But the tach in the dash cuts out when the backfires occur indicating that same problem exists. The tach is driving from the MS.
My question is this, is there a particular twisted pair wire that I should be using? Is it something readily available? When I purchased the kit I was clear that I would be using it on a VR sensor but it came with a single shielded wire for the tach input. It seems that is the start of my issues with crank signal and still continues keeping me from making progress. I'm almost ready to go to the old fashioned solution of using three wires, twist them with a drill, use one for signal, one for signal return, and one for shield/ground.
As soon as I get the data log I will post it. The one I have now does not illustrate the problem. The MSQ is attached now.