Intermittent and no-code driveability problems

Van 2 has a problem its driver, Leah Mercer, describes with real frustration. Every few days, without warning, the engine dies while she is driving, usually on the rough gravel road to the airport freight terminal. The dashboard lights flicker, the engine stops, and it restarts immediately. Twice it has happened in traffic. There are no codes, and the van has been fine every time Ridgeline has driven it. "This is the hardest kind of job," Marty tells Kiran, "and the one that builds a shop's reputation. A fault you can't make happen is still a fault. You have to arrange to be there, or have your instruments there, when it does."

This lesson covers faults that come and go, and faults that leave no codes: why they are hard, how to gather evidence about them, how to leave instruments in the vehicle to catch them, how to provoke them in the bay with heat, cold, moisture and vibration, and how to correlate the events with the conditions that cause them. It also covers no-code driveability complaints in general, where the engine runs poorly but nothing is out of range enough to set a code.

Why intermittent faults are hard

An intermittent fault exists only some of the time. When it is not happening, every test passes, because the circuit or part is working at that moment. A technician who tests during a good period finds nothing, and a technician who replaces a likely part may seem to fix the problem only because it has not happened again yet. The only way to diagnose an intermittent fault reliably is to observe it while it happens, either directly or with a recording, and then find the condition that causes it.

Most intermittent driveability faults are electrical: a loose or corroded connection, a chafed wire that touches ground when the vehicle flexes, a terminal that loses contact when hot, a ground that loosens with vibration, or a connector that lets water in. Some are mechanical, such as a sticking valve or a part that cracks only when hot, and some are software, which a bulletin may describe. The electrical ones respond to the same three provocations: vibration, temperature and moisture.

The interview matters most

Because the technician may never see the fault, the driver's description is the most important evidence. Kiran interviews Leah in person with a set of questions Ridgeline uses for every intermittent job: when did it start, how often does it happen, what was the vehicle doing, how fast, on what road, in what weather, how warm was the engine, what did the dashboard do, did anything else happen at the same moment, how did it restart, and has anything been repaired, added or changed recently? The answers go on a log sheet that the driver keeps in the van and fills in each time.

Leah's answers narrow the conditions sharply. It happens on rough roads, never on smooth highways. It happens warm or cold. It happens in dry weather as well as wet. The dashboard lights flicker as it happens, which means more than the engine is affected: something is interrupting power to several modules at once. And it restarts immediately, so whatever opens closes again almost at once. Kiran writes her first theory on the order: an intermittent open in a power or ground circuit shared by the engine control module and the instrument cluster, made to open by vibration.

Instruments in the vehicle

When the fault cannot be reproduced on demand, the instruments must ride with the vehicle. A scan tool's flight recorder, or a stand-alone data logger connected to the diagnostic connector, records chosen parameters for hours and saves the data around a trigger. A portable scope with a long recording mode records voltages at a high sample rate. Some shops loan a recorder to the customer; others ask the customer to leave the vehicle and drive it themselves. Ridgeline's practice for a fleet vehicle is to install a recorder, explain its event button to the driver, and collect it after a week.

Kiran chooses the inputs from her theory. On the scan recorder: engine speed, ignition voltage as the engine control module sees it, the module's own reset counter if the manufacturer provides one, vehicle speed and coolant temperature. On a small two-channel data logger with its own battery, wired with sealed connections and secured away from moving parts: channel 1 on the engine control module's main power feed at the module connector, and channel 2 on the battery positive post, so a voltage drop between them can be seen. A cheap vibration logger, an accelerometer recorder the shop uses for noise jobs, is taped to the floor to record how rough the road is.

Before deciding how long to leave the recorder, Kiran estimates the chance of catching the fault. Leah logged three events in the last two weeks. The code treats the events as random at that rate and calculates the chance of at least one in a recording period, and the chance of several, which would make the pattern clearer.

# Chance of catching an intermittent fault in a recording period, if events happen at random
import math
events, days_observed = 3, 14
rate = events / days_observed            # events per day
for days in (1, 3, 5, 7, 10):
    expected = rate * days
    p_any = 1 - math.exp(-expected)
    p_three = 1 - sum(math.exp(-expected) * expected ** k / math.factorial(k) for k in range(3))
    print(f"{days:2} days: expect {expected:.1f} events; at least one {p_any:4.0%}, at least three {p_three:4.0%}")

 1 days: expect 0.2 events; at least one  19%, at least three   0%
 3 days: expect 0.6 events; at least one  47%, at least three   3%
 5 days: expect 1.1 events; at least one  66%, at least three   9%
 7 days: expect 1.5 events; at least one  78%, at least three  19%
10 days: expect 2.1 events; at least one  88%, at least three  36%

A week gives about a four in five chance of at least one event, and ten days gives about nine in ten. Bev and Hal agree on a week, with Leah keeping the van on its normal route, including the gravel road.

Provoking the fault in the bay

While the recorder is in the van, the tests that provoke faults in the bay are still useful, especially once there is a theory. A wiggle test means flexing and tapping connectors and harnesses in small sections while watching for the fault on a scope or scan tool, with the engine running if safe. A heat test uses a heat gun on low, held well away from plastic parts, to warm a suspected part or connector; a cold test uses a freeze spray made for electronics. A water test uses a spray bottle of water with a little salt, or for some connectors plain water, to wet a connector or harness while watching; it should never be used near ignition parts at high voltage or on connectors that will not dry, and anything wetted is dried afterward. A vibration test can be as simple as a rubber mallet tapped on a bracket, or as structured as driving over a rough surface.

Kiran wiggle-tests the engine control module's harness, the main fuse box connectors, the ignition switch connector and the main grounds with the engine idling and the scope on the module's power feed. Nothing changes. The fault may be in a place she has not reached, or it may need more vibration than her hands can make. That is why the recorder is in the van.

Correlating events with conditions

A week later, the recorder has caught two events, and Leah's log sheet records both, on the gravel road. Each recording shows the same thing: the module's main power feed drops from about 14 volts to under 3 volts for 40 to 60 milliseconds, while the battery voltage stays steady; the engine control module resets, the injectors and coils stop, and when the voltage returns the module restarts the engine as it rolls. The vibration logger shows large vertical accelerations at the same moments. The drop is between the battery and the module, on the power side, and it happens with vibration.

For a fault with more events, a technician can let the data speak by comparing the conditions during the events with the conditions overall. Kiran uses the week's logs: for each recorded minute, the road roughness, the engine temperature and whether the windshield wipers were on, as a proxy for rain, and whether an event happened. The code compares how often each condition was present during events with how often it was present at all.

# Which conditions go with the events? Compare event minutes with all minutes
minutes = [
    # rough road, engine warm, wipers on, event
    *[(False, True, False, False)] * 1400, *[(False, False, False, False)] * 380, *[(False, True, True, False)] * 260,
    *[(True, True, False, False)] * 190, *[(True, False, False, False)] * 45, *[(True, True, True, False)] * 30,
    (True, True, False, True), (True, False, False, True), (True, True, False, True), (True, True, True, True),
]
events = [m for m in minutes if m[3]]
for k, name in enumerate(("rough road", "engine warm", "wipers on")):
    overall = sum(1 for m in minutes if m[k]) / len(minutes)
    during = sum(1 for m in events if m[k]) / len(events)
    lift = during / overall
    print(f"{name:<12} present {overall:4.0%} of the time, {during:4.0%} of events: {lift:4.1f} times as likely")
print(f"{len(events)} events in {len(minutes)} recorded minutes")

rough road   present  12% of the time, 100% of events:  8.6 times as likely
engine warm  present  82% of the time,  75% of events:  0.9 times as likely
wipers on    present  13% of the time,  25% of events:  2.0 times as likely
4 events in 2309 recorded minutes

Over two weeks of logs, counting Leah's two earlier events with known conditions, every event happened on a rough road, which the van is on only about one tenth of the time. The engine temperature makes no difference, and a single wet event among four is too few to mean anything. The road is the condition; vibration is the cause.

Finding the connection

With the fault located on the power side between the battery and the module, Kiran turns to the wiring diagram. The engine control module's main power comes through a relay and a fuse in the under-hood fuse box, and the instrument cluster's ignition feed shares a terminal on the same fuse box connector. A loose terminal there would explain both the engine dying and the dashboard lights flickering. She removes the fuse box from its bracket with the battery disconnected and examines the connector. One terminal on the main feed connector has a slightly opened tang and a polished ring around it, and its wire has been pinched under the fuse box cover where a previous owner or shop had routed an accessory wire. When she pulls gently on the wire, the terminal slides back in its cavity.

With the scope on the module's feed and the engine running, she taps the fuse box with a rubber mallet: the voltage drops and the engine stalls, exactly as on the road. The fault has been reproduced on demand. The repair, using the manufacturer's terminal repair kit, is a new terminal crimped and sealed to the specification, seated with its lock engaged and its retention checked, the accessory wire rerouted through its own grommet, and the connector's secondary lock refitted. Verification is the mallet test, which no longer causes a drop, a drive over the gravel road with the scope recording, and another week of the recorder in the van with no events.

No-code driveability complaints

Not every no-code complaint is intermittent. Some engines run poorly all the time without setting a code: a hesitation, a flat spot, poor fuel economy, a rough idle or low power. A code sets only when a monitor's test fails its limits, and many faults stay inside those limits while still being noticeable to the driver. A slightly restricted fuel filter, a catalyst partly clogged, a camshaft a little retarded, a sensor reading a little off, a thermostat opening early: each can make an engine feel wrong without crossing a threshold.

For these, Lesson 1's strategy still applies, with two tools leaned on heavily: comparison with known-good data, and tests that measure the engine's performance as a whole. Known-good data, from the shop's own reference folder or from aftermarket databases, shows what the fuel trims, airflow, spark advance, manifold pressure and other values should be at each speed and load for that engine. Performance tests include the airflow check from Lesson 3, a fuel pressure and volume test under load, an exhaust back-pressure test, and a timed acceleration on a safe stretch of road compared with a known-good vehicle. The capstone is a no-code hesitation diagnosed this way.