Never a stranger to hard work, Josh Jones had his hands full again this month, as he encountered a Vauxhall Astra with crankshaft sensor signal issues, and an imported Nissan Elgrand with an MIL illumination and lack of available technical information.
Vehicle: 2005 Vauxhall Astra G 1.7cdti Z17DTH
Issue: Crankshaft sensor signal
The fault with this car had been approached unsuccessfully by a garage prior to my having the chance to take a look. I feel that the results could potentially have been confusing for anyone, and they certainly made me think twice. In a nutshell, the symptoms experienced when running the engine boiled down to the control unit having no crankshaft sensor signal available.
An extended cranking period before starting was a good sign that the control unit was looking for an input before referencing the cam phase sensor as a back-up, and as the DTCs pulled from the car in prior attempts suggested this was the fault area, I decided to follow this path straight away. A scope trace of the crankshaft sensor output taken with the sensor itself disconnected showed good integrity and amplitude relative to RPM, and as the sensor had been changed before the car came to me, I didn’t need any more convincing that we weren’t looking at a sensor issue.
The live data stream from this car (on my scan tool anyway) did not have separate parameters available in order to view the camshaft speed independently from the crank speed; it only showed engine speed, which I knew was being calculated from the information from the cam phase sensor because the car started in the same manner with the crank sensor disconnected as it did with it connected, and as soon as the engine started in this mode, a crank sensor circuit code was logged.
Next on the hit list was the relevant wiring between the sensor and the control unit, which had also been looked into as a potential culprit in previous attempts. I thought the easiest way to do this would be to disconnect the control unit and take the same trace I took at the unplugged sensor but this time include the harness as well, at the terminal side. Normally I would always opt against this type of test as I always have better results testing circuits fully connected and in operation but as I was testing an inductive circuit, this test would confirm what information the control unit had available at its own connector in the characteristic AC signal.
None of the pins or sockets on the connector showed any visual signs of damage, including the two crank sensor circuit connections. The results of taking the trace were exactly the same as at the sensor itself – a good signal even at cranking speeds. For my own peace of mind, I also took a trace at the ECU harness wire side with the circuit complete to confirm that the ECU being connected was not adversely affecting the CPS output for any strange reason. The result was again the same.
Obviously at this point I was thinking the worst, as all signs pointed to a control unit internal problem. The control unit was sent away for a basic function test, and it returned with a clean bill of health (the test engineers were specifically requested to test the function of the trigger in question). I was advised that the ECU was functional on their test rig operating with only a crank signal available (no phase input). Oh dear, what had I missed?
I re-examined the ECU connector and harness multiplug. I could still see absolutely no reason to call into question the integrity of this connection but as it was the only part of the circuit I had not categorically confirmed as being intact, I decided to do something a bit unorthodox and very slightly ‘manipulate’ the applicable pins over to one side and plug back in. The car started instantly and no DTC was triggered. I have witnessed opened out female pin sockets before, but in this case it was so slight that even when I backed the sockets out to repair them I still could not see how there would be no contact. I guess that’s how sensitive these things are and why no stone can ever be left unturned!
Vehicle: Nissan Elgrand 3.5 V6 VQ35
Issue: ’Short to positive’ fault with upstream O2 sensor heater circuit on Bank 1
More adventures came this month in the form of an MIL illumination on an imported Nissan MPV, and the required technical information for this vehicle proved pretty hard to come by. No physical fault was reported by the driver, so a PCM code read was the first port of call. The ECU reported a ‘short to positive’ fault with the upstream O2 sensor heater circuit on Bank 1. In a previous effort to fix the fault by another garage, a new OE spec sensor had been fitted. I used a DVOM to confirm supply voltage to the heater with the engine running, at which point I also confirmed that the heater was indeed ground side controlled (I didn’t have a wiring diagram).
After manually tracing the loom from the sensor to the control unit, I checked for a duty cycle with my scope and contrary to the O2 sensor duty cycle live data parameter I was reading alongside this test, the voltage at this point was held high at battery voltage – no switching was taking place.
After re-testing the voltage at the PCM terminal again, with the Bank 1 sensor disconnected, I was able to confirm the control unit terminal connection integrity (you live and learn) as a diagnosis voltage was present. So, I now knew I was looking at two likely eventualities. The first was an ECU internal fault in which the end stage of the heater circuit had become disabled, and the second was an ECU ground fault.
After careful consideration, I decided not to try and blindly track down all the ECU ground lines. I felt it hugely unlikely that the ground path used for the heater circuit would be standalone, and since the Bank 2 duty cycle was present and no DTCs for any other component were logged, I was confident the computer had the applicable ground path available, but due to an internal issue, it was not able to make use of it. A new module is still being sourced at the time of writing, but I’m confident we are looking at a fix.
