One Bit at a Time

By Nick Hibberd

The car had an intermittent drivability complaint, bogging down under acceleration with
no MIL flagging. The customer insisted that it wasn’t just intermittent; it was very
intermittent. First things first: I connected the scan tool to see if any DTCs had been
logged. It was here that this investigation took a sharp turn.

The scan tool oddly came back with No Communication Possible, and whenever I see
this I automatically think, what have I done wrong? It’s only natural to think this
because computers don’t make mistakes, do they? I ran back through everything but it
was still the same.

I checked other modules and quickly noticed No Communication on a lot of them. This
is typical of diagnostic line failure, and already a mental game plan was beginning to
form. Before doing anything else, I made the customer aware of what I had found and
that this was a vital investigation in itself before I could begin to address his original
complaint.

If I am dealing with a diagnostic line failure, then a cabling short to battery negative or
positive is the most likely cause. I know from past dealings with this make of vehicle
that nearly all connected modules run to one pin on the OBD socket, which isn’t going
to help things because now my suspected fault could be anywhere on the car.

It was time to hook up the oscilloscope to get a clearer picture of the fault. Monitoring
the diagnostic line electrically is a little awkward on this model, to say the least, so I
opted for a known connection at the back of the radio which actually could help the
diagnosis.
In this picture I’m connecting to a module away from the OBD socket and my next
move will depend on what I capture. Because I’ve already decided that other modules
apart from the engine are affected, I’m anticipating that every capture I get here will be
the same for the rest of the diagnostic line and its connected modules. Initially I look for
a voltage level present, usually near battery voltage, and then as the scan tool attempts a
handshake I look for a pulsed ground in a code sequence. Because each module shares
the diagnostic line, only one will respond to a certain code given by the scan tool,
leaving all others ignoring it. Enough theory — let’s have a look.

For a diagnostic line problem, I like to take a wide view and then zoom in later. This
helps to see the scan tool handshake, which can be lengthy until the module responds,
and also any abnormalities that might be lurking.

On the face of things there is not a lot wrong. We see a good handshake structure, with
good high and low voltage levels present. It also tells me that I’m not dealing with an
open circuit problem between the scan tool and the modules. What isn’t clear at the
moment is the integrity of the module’s response, but this could be due to the PC
struggling to display the fast dialogue reply with the long time base. Let’s zoom in for a
better look.

Now things don’t look so good. The highlighted section which is supposedly our
module reply is an immediate cause for concern. There’s something trying to break
through but it certainly isn’t binary. It looks more like a sawtooth pattern. The same
signal “arch effect” seen in the module response can also be seen in the rising edge of
the handshake. This is potentially a big problem and worth pointing out.

In binary signals, there is always a threshold of operation, and the voltage doesn’t have
to be full on or full off for a module to recognise a valid binary bit. There is a crossover
point where a module understands the difference between high and low states. If noise
spikes don’t cross this threshold, then the module won’t see them and detect the wrong
state. Here I’ve chosen a threshold of 5 volts as an example.
In the capture 1b you can see that, because the rising signal edge has an “arch effect” as
it returns to rest, it will have an effect on the rise time and thus the overall handshake
time from the scan tool. I recorded the rise time here to be around 23 ms (0.023
seconds), which I don’t consider normal, but the time between state changes of 1.007
seconds wasn’t enough to prevent the module from responding, however wrongly, to
the handshake.

So what’s causing this? At the moment I’m not considering a hard wiring fault, but
rather leaning towards a module problem. The described “arch effect” in the signal
appears very controlled, neat, and clean. This type of control is indicative of a resistive-
capacitive (RC) circuit, but has no place in binary signalling. This is an issue at an
electronic level.
On closer inspection of a falling binary edge, we can see a similar characteristic. I
would have expected the binary structure to be much more definite than shown at this
time scale.

At this point, I took a step back and jotted down some ideas in diagram form. This has
helped me in the past to spot problems that were not originally anticipated. This time,
the most likely cause I could come up with was as follows:

I’m suspecting a capacitance leak into the diagnostic line, and that the capacitance is
already connected to ground potential, or certainly close to it. Here’s my reasoning.

The diagnostic line voltage at rest is derived from a high-resistance source inside the
connected modules, including the scan tool that is now also connected to the line. Only
a very small amount of current is needed to pull this voltage down to 0 V; that’s all the
scan tool does. With the line voltage at rest, our suspect capacitance will already be
charged. As the scan tool handshake pulls the line voltage down, the capacitance is also
forced to dump its stored charge to ground, but not without putting up a fight first when
we see the small exponential curve at the base in extract 1d. Now the capacitance is at
near ground potential for the duration of the binary low state. When we see the binary
low state released in extract 1c, our suspect capacitance charges up and once again we
see the characteristic exponential curve. Notice how the two binary edges are affected to
different degrees. This is because the scan tool ground command comes from a low-
resistance source pulling the signal down at the beginning, while the diagnostic line has
a higher resistance pulling the signal back up at the end.

Of course, none of this theory is any use whatsoever, as I’m still left with the question:
where’s the problem?

The engine module is a bit of a pain to gain access to under the wiper scuttle trim, so I
started the search within the passenger cabin. I stripped the underside of the driver’s
dash panel to have a look around. A Convenience Unit lives behind here, and then I
planned moving on to the instrument panel. Then it dawned on me that the radio was
obviously a module too...

I pulled out the power ISO connector and retried the scan tool: Connection Established.

Incredible! It was staring me in the face. The whole diagnostic system was now back in
operation.
Capture 2 was a segment of the handshake now: perfect.

Capture 2a was taken with the engine module sending a full data stream to the scan tool.
With the radio connected (fault present) the signal didn’t stand a chance of developing a
full “bit”, because our stray capacitance stored enough energy to keep the diagnostic
line potential quite high. We come back to time constants of RC circuits, where a
capacitor is allowed to charge up from a power supply and then discharge into a load.

The scan tool handshake is long in comparison to the full data stream, and it managed to
create a defined binary bit without letting the stray capacitance interfere too much.
I isolated the diagnostic line connection from the radio and informed the customer of
the situation. He didn’t seem too bothered that his radio was missing a diagnostic line.

After all this, there were no DTC’s Logged in the engine control unit.