One of the greatest challenges in modern diagnostics is resisting the urge to force a vehicle’s data to fit your preferred theory. When faced with an intermittent fault or a complex control network, it is easy to jump to conclusions based on a fault code alone. True diagnostic clarity comes from a methodical, evidence-led approach to understand how a system works and allowing the data to guide your decisions. Just like we did with this VGT Turbo fault on a JCB Telehandler.
Using a PicoScope Automotive oscilloscope and the universal breakout lead set, we connected to the VGT actuator connector. This allowed us to verify a stable power supply and J1939 CAN network health and to evaluate the validity of the “U” code. Mapping exported CAN data revealed a smooth curve during manual movement of the turbo actuator but an erratic graph during automated learning sweeps. This provided the evidence to justify replacing the turbo.
What was the problem?
- Machine: 2015 JCB 540-170 Telehandler
- Symptom: Intermittent performance loss and power derate
- Logged Fault Code: U040D-54 – VGT span out of allowable range (<90% or >110% of the factory-stored first learn).
The operator reported that the machine was less likely to fault from cold. However, once the telehandler was up to normal operating temperature, switched off, and then restarted, it would more often than not log the fault code and therefore suffer a drop in power.
Initial Assessment
At the start of this investigation, we knew:
- The fault code referenced a “span out of range” error during a learning phase.
- The code began with a ‘U’, denoting a likely network communication failure.
A common diagnostic trap would be to focus on the ‘U’ prefix and start hunting for broken CAN wires or terminating resistors. Or jumping to a mechanical conclusion, assuming the turbocharger vanes were seizing due to heat expansion. Before replacing components, we needed to establish how the fault code is set and under what conditions.
How to Diagnose a VGT Turbo Fault in a JCB Telehandler
To diagnose this system effectively, we needed to know how the VGT function operates. Mechanically, the VGT alters the angle at which exhaust gases strike the turbine wheel. This minimizes turbo lag, improves low-RPM torque, and prevents the turbine from over-speeding.
Electrically, while older systems use vacuum actuators or pulse-width modulated (PWM) DC motors, this JCB Telehandler communicates the VGT position over the CAN data bus, relying on a 4-wire connection including the battery power, ground, CAN High, and CAN Low.
Depending on the manufacturer, a VGT actuator often has a self-calibration or “learn” routine. On this JCB, a key-on signal forces the internal actuator motor to sweep the vanes through their upper and lower mechanical travel limits. The internal electronics measure this movement via a position sensor. If the target position and feedback vary too greatly, or if the full span cannot be achieved, the engine control module (ECM) can limit current draw and derate engine power by up to 40%.
Step 1: Verify Power Supply
The first question was whether the turbocharger was receiving stable power and ground, and whether a CAN signal layer was present.
Using a universal breakout lead set, we split the 4-pin turbocharger connector to connect our test leads to the circuits. We connected a 4-channel PicoScope Automotive Oscilloscope to find the following:
- Channel A (Blue): Actuator Pin 1 (CAN Low)
- Channel B (Red): Actuator Pin 2 (Ground)
- Channel C (Green): Actuator Pin 3 ( Power Supply)
- Channel D (Yellow): Actuator Pin 4 (CAN High)
We initially set all channels to a +/- 20 V scale and a long timebase to capture the initial key-on event, as the correct pin configuration was unknown. We expected to see a clean, stable 12 V battery power supply, a solid ground at 0V, and standard CAN H and L packets idling around 2.5 V.
What this showed was a stable battery supply and ground, but all four channels were affected by significant electrical noise and overshoot spikes. Adjusting the wiring harness caused no dropouts, confirming the physical connections were tight.
Step 2: Decode CAN Network
With stable power established, the next step was to find out if the ‘U’ code was valid and ensure the turbocharger was communicating effectively.
We optimized our channels, moving CAN High and CAN Low to Channels A and B to use the built-in math tools within the PicoScope 7 Automotive Software. The machine network operates at a baud rate of 500 kbps. To accurately analyze and decode serial data, your sampling rate should be at least 10 times the baud rate. In this case, we should be looking for MS/s.
Diagnostic Tip: In an ideal environment, a USB3 cable and X10 attenuated test leads would help reduce noise. Unfortunately, these weren’t to hand and we were working on-site with standard X1 leads and a USB2 cable. Due to our streaming timebase constraints with a USB2 cable, we had a sample rate of 2.5 MS/s, which isn’t ideal, but in the real world, it is good enough to perform serial decoding.
By applying an A–B math channel and utilizing a J1939 serial decoding protocol, we expected to see a clean decoding table showing valid data packets passing successfully between the engine ECM and the turbocharger. Instead, we observed several invalid messages at key-on displaying an Acknowledgement (ACK) bit of 1, indicating that no other module on the network had answered or acknowledged the packet. However, as we scrolled further down the timeline, the ACK bit flipped to 0, and the subsequent messages became valid.
This did not prove a network fault. Instead, it revealed another diagnostic trap. At key-on, an ECU wakes up and transmits immediately, whereas other ECUs take a few milliseconds longer to boot up. These initial, unacknowledged packets can be normal for a staggered network wake-up.
As J1939 is a fairly standardised network, identifying ECUs based on the source address is well documented. Further analysis of the valid data revealed successful communication between several nodes:
- Source Address 0x00: Engine Control Module
- Source Address 0x02: Turbocharger Actuator
- Source Address 0x82: Unknown address
- Source Address 0xF9: Off-board diagnostic scan tool
This evidence changed the direction of our diagnosis as it confirmed the communication network was intact. The true fault lay within the actuator travel learning performance.
Step 3: Find the Vane Position
We knew the code pointed to a span error during the key-on sweep, meaning the turbocharger actuator could not find its upper and lower limits compared to its calibration values. While we would normally cross-reference our extensive Waveform Library to confirm this, we were working off-grid. Instead, we methodically exported the raw decoded J1939 hexadecimal data into a spreadsheet to isolate exactly what the actuator was reporting.
Reviewing the network, we confirmed communication across at least four active ECUs, including the engine (Source Address 0x00), an off-board diagnostic tool (0xF9), and an unidentified, likely proprietary JCB ECU (0x82). However, our primary focus was the turbocharger at Source Address 0x02 (verified via isobus.net). With both the engine and turbo online, we expected a healthy exchange of data.
By filtering the turbocharger’s address 0x02 and the Parameter Group Number PGN 0FF87, we analyzed the individual bytes. We noticed that the values in Byte 0 and Byte 1 shifted rapidly whenever the actuator motor drew current. Because these bytes originated from the turbocharger and reacted dynamically to motor activity, we tentatively identified this data as the VGT vane position feedback.
To visualize this, we exported the data from PicoScope 7 Automotive software, isolated and graphed individual bytes using the filtering and plotting techniques outlined in our PicoAuto forum. Rather than the smooth, predictable line you would expect from a sweeping actuator, the resulting chart revealed incredibly sporadic data. This critical finding led to two further tests.
Test 1: An Automated Key-On Sweep
We plotted the values of Bytes 0 and 1 during the automated key-on learn phase while the machine was hot and the fault was active.
The resulting graph was sporadic. Instead of a smooth, uniform travel line, the position feedback value jumped erratically. This explained why the fault code logged as the control loop was reporting incoherent feedback positioning during the span check.
Test 2: Manual Component Validation
We needed to isolate whether the internal position sensor tracking was broken or if the actuator was jamming due to internal stiction. We disconnected the linkage rod and manually moved the vane mechanism through its travel span while logging the data bus.
With the data exported again and then graphed, we noticed a smooth transition curve.
The smooth manual curve proved that the internal position sensor track was capable of reading linear travel, and the internal electronics were healthy. However, when the internal motor attempted to perform its high-speed automated sweep under its own power, the control loop failed to reconcile its positioning targets, resulting in sporadic data feedback.
We now had enough evidence to replace the turbocharger assembly.
Step 4: Repair and Validation
The complete turbocharger assembly was replaced. To ensure the repair was successful, we reconnected our PicoScope Automotive Oscilloscope to recapture the key-on signal.
The post-repair capture revealed that upon key-on, the new turbocharger actuator performed a single, swift mechanical sweep, and there was no sign of a fault code on the instrument panel.
Exporting the new J1939 data packets into our spreadsheet also confirmed the repair. The position feedback bytes plotted a clean, linear transition during key-on and captured a secondary, clean sweep immediately after the ignition was switched off, demonstrating a final calibration check to cache the travel limits for the next start cycle.
We also found the new working turbo drew significantly more current than the broken one, even over-ranging our initial 20A setup on the PicoScope. This supported our theory that when the old turbo controller realized it had lost track of its span boundaries, it intentionally clamped down on internal current draw to preserve its mechanical components. Once the new controller confirmed its boundaries, it safely permitted the internal motor to pull full current capacity to snap the vanes directly to their target destinations.
Top Tips for Technicians
- Don’t Let Fault Code Prefixes Trap You: A ‘U’ prefix code conventionally indicates a network communication failure, but it does not automatically mean the physical copper wires are broken.
- Staggered Boot-Up is Not a Network Fault: Missing acknowledgement (ACK) bits at ignition are common. Always look further down the data stream timeline to see if the modules successfully establish communication once they are fully powered up.
- Let the Data Guide Your Logic: When you cannot access our waveform library, work methodically with the parameters you can access. By systematically isolating power, checking network communication capability, and comparing manual sensor movement against automated operation, the data will naturally isolate the root cause.