Hide and seek

Fig 1

There are those who, instead of identifying and rectifying faults on cars, would rather change the vehicle’s capacity to detect such faults

Fig 2

Published: 22 September, 2022

By Ryan Colley, Elite Automotive Diagnostics

Vehicles will always experience faults; It is inevitable. However, some choose not to repair the fault. They would rather play games by changing the ECM’s ability to detect the fault. Man-made faults are some of the most challenging to uncover, but with a logical approach and careful eye, these too can be fixed without too much difficulty. Following on from a recent article on how to determine whether software tampering has taken place, I would like to discuss the next case study.

This vehicle was brought to me by another garage after multiple attempts at repair. This included a replacement crankshaft sensor and donor ECM. The vehicle was a VW Scirocco 1.6 TDI (Engine code= CAYC).

I was informed by the garage that the vehicle only exhibits its symptoms, which are stalling and hunting, during acceleration. If the vehicle is left to idle it will be fine. First, I road-tested the vehicle and as the garage informed me, the vehicle would cut out fiercely and stall. At other times, the engine would attempt to stall, but would continue to run if the vehicle was then stationary.

I connected the diagnostic equipment to the vehicle and retrieved the fault codes. After a full system scan was carried out, the only fault code stored in the engine computer was related to the crankshaft sensor signal being implausible. This would make sense considering the symptoms the vehicle is exhibiting.

I then carried out another road test monitoring the engine speed and camshaft speed data parameters via the scan tool. I found when the fault occurred, there was no fault exhibited in the data being displayed by the scan tool. However, the fault code relating to the crankshaft circuit kept returning.

Suspecting the scan data refresh rate was not fast enough to catch the fault during its occurrence, I decided to connect an oscilloscope directly to the crankshaft signal itself, to monitor the sensor's output back to the ECM. Another road test was carried out with the oscilloscope attached. Please refer to Fig.1. The capture demonstrates exactly where our fault lies.

At times, the crankshaft signal was sticking at 5V, thus informing the ECM the engine had stopped. This, in turn, caused the ECM to cease injector control. Remembering initially that the previous garage had already replaced the crankshaft sensor, it seemed odd for another to have failed in such a short time. Therefore, before condemning the sensor itself, we needed to verify both the 5V feed and ground supply was present during the fault occurrence.

Another road test was carried out. At this point I was connected to the 5V supply to the crank sensor and the signal wire itself. Please refer to Fig.2. When the fault occured with the crankshaft signal, the 5V supply was also dropping, thus causing our sensor to stop outputting. Without a good 5V supply and/or ground, the sensor could not operate correctly.

I had at this point confirmed that the vehicle was experiencing a 5V supply-related issue to this circuit. However, it seemed odd to me that the engine computer had not set codes for any other circuits, and only the crankshaft sensor. I then retrieved a wiring diagram and examined it to find many other devices shared the same 5V feed from the ECM:

EGR valve feedback sensor
Rail pressure sensor
Intake flap motor position sensor
Turbo wastegate position sensor

Please refer to Fig.3. Again, all shared this same 5V supply but none of them were reporting any faults.

After closer inspection, it was clear the EGR pipe on this vehicle had been completely removed and blanking plates had been installed in both the manifold and cylinder head, to stop any leaks. Please refer to Fig.4. This was an issue as the engine computer should be setting fault codes relating to the EGR valve system flow. These capabilities must have been deactivated for no other fault codes to be present in the engine ECU.

I then read the engine computer's flash file and studied it to not only find that the EGR valve had indeed been deleted, but multiple fault codes had also been removed relating to all the sensors which were connected to the 5V supply issue. By re-flashing the control module with the correct/original software, I then received fault codes for these sensors during a subsequent road test, confirming the fault occurrence.

Armed with the information that the EGR valve had been deleted, and permanent fault codes now present in the engine computer for the EGR valve control circuit open, I decided to carry out a visual inspection of the connector on the EGR valve. This component was one of the sensors to share the 5V supply.

Finding the root cause
As you can see from Fig.5, the connector was nowhere to be seen. However, if you look closely, you can see the harness was running down the back of the engine, above the driveshaft. Further inspection showed that the connector had been rubbing on the driveshaft and was intermittently shorting the 5V reference circuit to ground, causing the drop out in the 5V supply to all the related sensors.

A wiring repair, replacement pipe and EGR valve were installed, and this vehicle was then cured. The original EGR valve had seized, causing the engine management light to illuminate, but a poor attempt at repair led to a shorted 5v reference circuit.

Keeping your eyes open for anything that seems out of the ordinary, like a completely missing pipe for example, is a good indicator that software tampering has occurred. This is becoming more and more frequent, making the diagnosis a lot more difficult due to pieces of the puzzle being taken away.

If you are ever in doubt whether software tampering has occurred, having access to dealer equipment is advantageous in these circumstances; allowing us the ability to flash the correct/original files onto the computers so we can then continue with the diagnosis.

Fig 3

Fig 4

Is it there or not?
Intermittent faults are always the most difficult to find. Therefore, when I was tasked with attempting to diagnose and rectify an intermittent cutting-out fault I knew it would not be straightforward.

The customer had heard of me via my social media page and local garages who use me for their diagnostic work. The customer complained that the vehicle, a Renault Traffic 2.0L TDI, would stall on its own, intermittently. The vehicle would then start up again as soon as the ignition switch had been cycled. This fault could occur within the hour or take five hours before it would surface again. The customer advised there was no rhythm or rhyme to the fault, and it could occur at any time. Knowing this would be a very time-consuming fault I advised the customer I would need the vehicle for a week to ensure experiencing the fault and carrying out testing thoroughly. The customer was more than happy to oblige, as long as I fixed the fault, so no-pressure then…

Initial approach
I started by carrying out a full system scan of all the vehicle’s computers. I found in the engine control module a fault code for ‘Computer internal electronic fault.’ Please refer to Fig.1. This was a good starting point as this fault code is very specific and often is caused by an internal control module error, wiring fault to the computer or a component directly related to the computer. However, at the cost of a new engine computer (over £1,200) I needed to pinpoint the fault and not rely solely on the fault code provided. I cleared all the fault codes present in the engine ECU and ran the vehicle in the workshop until it cut out. Once the vehicle cut out, I re-read all the fault codes and the only code which returned was the internal electronic fault as described earlier.

I noticed that when the vehicle had stalled, communication was still present and live data parameters were still being displayed by the scan tool. This indicated the engine computer is alive and operating. This was a good indicator that the engine computer is receiving the voltage and ground supply. Without it, communication would not be possible. I needed to confirm this for certain as I cannot diagnose a fault solely on suspicion.

To access the engine ECU on this vehicle I needed to remove the bumper, headlight, and security cage around the engine ECU. Before I attempted to remove all those components, as this was very time-consuming, I wanted to use an oscilloscope to check the fuses that feed the engine ECU at the time of the stall. These fuses are on the output stage of the engine control relay, therefore if it was the relay that was failing, for whatever reason, I would see the drop-out on the oscilloscope. As you can see from Fig.2, the supplied voltage and ground were constant and did not drop-out. This indicated that the engine control relay was latched and doing its job properly when the fault was present. I now had no choice but to access the engine computer to carry out further testing.

By removing the bumper, headlight, and security cage I was able to access the engine computer and its respective wiring harness. Concerned still of a voltage or ground supply issue, I connected the oscilloscope to the engine computer supplies and verified, during the stall, that these were present. Next, I wanted to verify the main inputs and outputs of the computer that could contribute to a stalling condition. I connected to the camshaft and crankshaft position sensor wiring, directly at the engine computer. I also connected to the injector wire using an amp clamp to determine if injector operation remained constant during the stall event. If not, I could then determine if injector pulse ceased due to a loss of a cam or crank sensor signal.

As you can see from Fig.3, the cam and crank sensor signals remained and the injector control was the first to be lost, thus resulting in a stall of the engine. The engine computer was no longer providing injector control to keep the engine running. Since proper cam position signal remained during the stall it was unlikely to be a 5v reference fault, as the 5v reference is used to power the camshaft sensor. At this point, from the evidence I had retrieved coupled with the fault code I initially found, I was highly suspicious of an internal engine computer fault.

There are no problems, only solutions
Due to the current issues surrounding the supply of electronic parts in the UK I was not able to obtain an engine control module directly from the dealership. I had only one option which was to locate a used control unit and carry out cloning of the original control module.

This process requires removal of the engine computer from the vehicle and connecting a programmer directly to the ECU. Please refer to Fig.4. You are then required to read the flash and the EEPROM internal to the computer and transfer that data from the suspect's faulty original ECU into the donor ECU. Please refer to Fig.5 and Fig.6.

By going through this process, you are effectively making an exact copy of the original ECU, allowing all the immobiliser and coding data to be transferred so you can simply connect the ECU back to the vehicle without any further programming being required. This will only rectify a hardware-related fault. If there was a software-related issue, then you will effectively copy the fault onto the donor unit. I was confident this was a hardware-related issue rather than a software-related problem. Once I had cloned the ECU, I left the engine idling to attempt to re-create the original complaint. I can confirm the donor ECU I cloned had fixed this intermittent fault as the stalling no longer occurred.

With intermittent faults, the best way to tackle them is to gather as much data as you possibly can, performing as little work as possible. This will then stop the hours and hours of stripping parts off needlessly to carry out inspections that are not required. A solid foundational knowledge of how systems operate on today's complex vehicles also provides a strong advantage. Logic can then be used to narrow down the possibilities that could cause the fault as we have done in this diagnosis and repair.
Diesel diagnostics for the workshop
I’m mindful of several recent diagnostic topics that focused on cutting edge opportunities such as noise and vibration analysis. It also reminded me of the most important aspects of fault finding; to focus on the symptoms, ask relevant questions and conduct a methodical approach based on systems knowledge, accurate data and a proven process.

All of this really boils down to training, experience, and confidence. There are no short cuts, cheap fixes or internet gurus. There are however basic steps that are easily introduced into your workshop procedures.

This brings me to the topic in hand. Can we conduct relativity simple tests on common rail diesel systems? Not only can we, but we must! Remember, the foundation rule of fault finding is a simple methodical approach. Don’t expect a magical fix-all in less than 1,000 words. However, I can provide a pathway that will illustrate the area of responsibility and potential investment in time and money.

Vital information
The first vital step is to listen and ask questions. Owners often have vital information. Remember this is not a recipe for short cuts or silver bullets for your machine gun. Your approach will always depend on the extent of problems. Will it run? are there any mechanical noises? Is there a loss of power? if so when? Is the fault intermittent and how did it start? There is an endless list of questions that will help establish a hidden history.

I often find that a physical examination or health check helps understand the way the vehicle has been driven and serviced. This will often expose basic problems especially with charge pressure circuits.

Try to explore all non-intrusive tests first. They may not be entirely logical in order of priority, but do provide results in the minimum time period. With experience, you will hone these steps into a razor-sharp intuitive process.

Serial investigation
Serial investigation is without doubt the correct first step. Do not jump to premature conclusions as serial data often shows symptoms, not cause. For example, a faulty air mass meter will cause EGR calculation error values, incorrect load and boost calculation. This is a common problem with many causes.

The volumetric efficiency relies on the intake system, swirl flap control, turbo spooling, and a free-flowing exhaust system. Please note that I keep my thoughts non-specific yet focused on all possible causes. This is a very important reaction in any diagnostic process.

Assuming a non-run condition, excluding any serial clues as often there are none, I would always check for the correct rail pressure. This can be done with a DMM. Expect around 1-1.5v with a quick rise time of 0.5-1sec. If it is slow to rise or low, check the priming system including the filter. This should be done with a gauge. Remember pressure, flow and pump current. This will depend on system type so check the schematics carefully. Most systems now prime at 5-6bar.

Isolate components
A slow rise time may be due to an internal leak or worn components within the high-pressure system. This includes the HP pump, rail limit valves, and injectors, as well as volume and pressure regulation devices. Always isolate various components and conduct a blind or proof test before suspecting the pump. They rarely fail, unless run dry or have contaminated fuel.
The PCM requires camshaft position data to sync the injectors and crank position once running. If recent belt replacement or engine repairs have been carried out, add this to your list. To check the injector sync against cam and crank position is a bit technical. To perform you will require a scope and current clamp.

Quite often the serial data identifies the incorrect timing sensor for position error. This is due to the PCM looking at the camshaft first. Slow rotation speed may be due to a faulty or incorrect battery, so check charge and health status with a suitable conductance tester. Yuasa have a fantastic free online training academy.

Next check relative compression. This is a simple cylinder balance check but when compared with current and rotation calculation will accurately predict correct compression.

Identify
A blocked exhaust or failed open EGR will prevent the correct combustion properties. Exhaust back pressure can easily be proven from the map and DPF pressure sensors. Plotting them with a scope will quickly identify intake or exhaust restrictions. The maximum DPF sensor value cranking or at idle should be 0.5-1.25 volts, 100mbar-1.5psi.

Injector type, solenoid or piezo faults will normally be identified within serial data. A single faulty injector circuit will normally shut down all fuel delivery. It is also worth noting that if a minimum rail pressure is not reached, the injectors will not be activated.
So back to priming. Leaks, faulty rail sensors will all contribute to a non-start.

If you are looking for more information, visit www.ads-global.co.uk for courses and dates, and Autoinform events.
Reasoning and diagnostics Part II
We began this journey last issue, so to recap: We need solid reasoning skills to carry out effective diagnostics; persistently good decision making doesn't happen by chance. Possibly out of convenience these skills are often underestimated and undervalued by people, both in and out of the trade. We must raise awareness of the discipline and precision of thought necessary for logical and critical thinking: so we can be better rewarded for our efforts; and to make sure they are consistently and properly applied.

Reasoning, arguments and hypotheses
We covered some fundamentals in my last article: we explain our reasoning using arguments, which contain statements supporting a conclusion; one type of argument, a deductive argument, should guarantee the truth of its conclusion (if it is sound); however, we need to use critical-thinking to check this, by making sure i) there are no other possible conclusions (which makes it a valid argument) and ii) the supporting statements are true.
Comline provides automotive apprentices with handy tools
Comline Auto Parts recently went above and beyond when responding to a college request for one of its common fault poster, by also providing tools for the classroom and workshop environment in the form of pens, post-it notes, magnetic pick-up tools and air-fresheners.
Common people
How do you go about diagnosing a common fault that you have seen before and all the symptoms match? Do you go ahead and fit that new part with no testing? Do you go straight to where you think the issue will be or do you test to be sure regardless of the situation?

You may or may not recall several articles ago, in the May 2020 issue of Aftermarket, I had a Land Rover Discovery 3 which would not start after being jump-started incorrectly and was fixed by reflashing the engine control unit software. Well, strangely enough, I was recently presented with a Range Rover Sport with near enough the exact same initial symptoms and fault codes. I want to show how starting afresh and testing, instead of jumping to the same conclusion, prevented a misdiagnosis.

Customer complaint
The customer’s complaint was that the vehicle would crank over but would not start. They said previously that the vehicle had started showing an intermittent no-start condition after sitting for a short period of time, for example to go into a shop. Once they returned, the car would crank and not start. The customer had discovered though that if they then waited five minutes and tried again, the vehicle would then start and be okay for the rest of the day. However, by now the symptoms had slowly become worse and no amount of cranking would start
the vehicle.

As always in my diagnostic process, the first step is to confirm the customer complaint and look for any tell-tale clues along the way. Yes it seems silly on the face of it to crank the engine over knowing it will not start, but an experienced technician may pick up a clue which will give direction where to go next so it always pays to always confirm the complaint. On this occasion confirming the complaint revealed no clues so it was on to the next step and to check for fault codes and review some live data.

Multiple fault codes
As can be seen in Fig.1, we have multiple fault codes stored for all different circuits and systems on the vehicle so where do we start? As in previous articles I have written, I always like to split them up into a list and put the most likely causes at the top and start there. Looking at the list we have five fault codes and I felt three could cause the no-start.

There are a number of likely causes. It could be a lack of fuel pressure, as the fault code states it is too low. The DC/DC converter fault also is another clue, as this converts the 12V supply from the battery and boosts it up to 60/70v to open the fuel injectors. The fact that code is stored could be another reason the engine will not start and the system voltage low fault code as this could indicate the control unit isn’t receiving the voltage it should to operate correctly.

The other two fault codes I felt could be put to the bottom of my list. An EGR fault most likely would not cause a no-start issue on this particular engine and there are two fitted due to the the engine being a V configuration. Having plenty of experience with this engine, I have seen many stuck open and closed EGR valves not cause the customer’s complaint due to the pipework configuration so it could be ignored for now. Lastly, there is the control box fan fault. This is a small fan mounted next to the engine ECU to control its temperature and would also not cause a no-start complaint.

Live data
My next step was to consult live data and look at module voltages and fuel pressure as these were at the top of my list. Cranking the engine while monitoring rail pressure showed there was next-to-no fuel pressure being generated, so this is one of the reasons the engine will not start. In that case, why do we have a low system voltage code and a DC-DC converter fault logged? With reference to Fig.2, looking in the module voltage section in live data showed why we have 0v for battery voltage and 3v for the DC-DC converter. As I mentioned, this should be around 60-70v on this particular vehicle so this explained the reason for the other fault codes. I then decided to pull up a wiring diagram and look at how the engine ECU was supplied power to formulate a plan of attack for these faults.