A 2016 Ford S-MAX II arrived with six fault codes stored in memory, yet the dashboard was completely dark and the car drove perfectly. The technician's own notes summarized the situation perfectly: 'Finns felkoder lagrade. Ingen lampa lyser i bilen, bil går normalt.' Fault codes are stored, no lamps are lit, and the car runs normally.
When a customer drops off a vehicle like this, it threatens to ruin your daily schedule. You cannot justify spending three hours of diagnostic time chasing ghosts when the car exhibits no actual drivability issues. The codes present were U0402, P061B, C0034, C0051, B1202, and U0415. A traditional scan tool gives you a list of definitions, leaving your technician to guess which one is the root cause and which ones are just noise.
Tracking the cascade from the wheel speed sensor
The diagnostic platform we build analyzed these codes together and pointed straight to the right front wheel speed sensor as the 85 percent probability root cause. The specific code for this is C0034, indicating a circuit fault in that sensor. When a wheel speed sensor fails intermittently, it sends either zero signal or erratic data to the ABS module. This corrupt data then propagates across the CAN bus.
That propagation explains the U0415 code, which flags invalid data from the ABS module. It also explains the P061B internal torque performance code, because the engine control module relies on accurate wheel speed data to calculate torque and monitor powertrain performance. Since the vehicle was running perfectly and no warning lights were on, this had to be a historical or intermittent fault. The recommended test plan was straightforward: a visual inspection of the sensor and wiring, a resistance measurement, a check of the tone ring, and monitoring wheel speed via live data.
CAN bus stability and invalid data codes
If the wheel speed sensor checked out, our engine ranked CAN bus network stability as the second most likely cause at 80 percent probability. The presence of multiple invalid data codes (U0402, U0415, and C0051) without active dashboard warnings strongly suggests a network integrity issue. A weak battery, poor ground connections, corroded pins, or wiring damage can disrupt data packets across the network.
This type of disruption creates a cascade of communication codes. The platform recommended a battery load test, a charging system check, a voltage drop test on the ground points, and checking the termination resistance of the CAN bus itself. These are quick tests that confirm basic electrical health before tearing into harnesses.
Secondary modules and steering inputs
Further down the probability list, at 70 percent, was a fault in the Transmission Control Module or its communication pathway, flagged by U0402. This means the TCM was broadcasting data the rest of the network could not interpret. If the previous steps yielded nothing, the technician was guided to run a bi-directional test on the TCM, check its power and ground supplies, and verify if a software update was available.
Finally, the C0051 code pointed to a 65 percent chance of a steering angle sensor plausibility failure. The data coming from the steering angle sensor was corrupt. This sensor feeds critical information to the stability control system. The suggested tests were live data monitoring, visual inspection of the connector, and running a recalibration routine.
Giving the technician a clear path
Intermittent faults without active symptoms usually mean a technician clears the codes and tells the customer to come back when the light stays on. By mapping the relationship between the wheel speed sensor and the resulting communication errors, you can give your customer a definitive answer without tying up your bay for hours. Have you noticed wheel speed sensors triggering torque calculation codes in your own workshop?