I wanted to find out if the OBD2 queries are passed directly through to the
P-CAN bus, so I got the scope back on it. With the car powered up for real
the bus is a lot busier, as we'd expect. There are several things to learn
from this trace. It's in dual-view mode, expanding a small segment of a
long capture into the main window.
The trace is a lot cleaner, and I believe I know why. Again, I'm only looking
at CAN_H, the positive-going half of the differential pair. Both wires sit
at about 2.5 volts in the "recessive" state when they're not sending traffic.
To send a "dominant" bit, CAN_H goes up about a volt and CAN_L goes down,
so the voltages fly "apart" and back together. All of this is floating
a little above ground, and when all traffic ceases the bus wires settle back
down to slightly above ground level fairly quickly. Thus there is always a
tendency to drift back toward ground level, and with a relatively inactive
net like in the previous trace I believe that's what causes the lower-edge
loopiness relative to the car's ground. With the car fully on/ready and
*all* the ECUs online and participating, we don't see that so much.
What we do see, though, is a different voltage effect. At the end of every
CAN packet is an optional ACK bit, which any receiving device is free to
send if it likes. Multiple devices can ACK at the same time, and with all
those participants at once asserting the bus against the termination, the
voltage for that ONE interval winds up going considerably higher. Then
everybody waits for the required 20 microseconds or whatever it is.
The next event is more subtle, notably here over the "524". CAN IDs are
also priority selectors, with the lowest ones taking precedence. The bus
arbitration is rather elegant: since a dominant, asserted bus [high in this
case] is a zero bit, not a one, whichever device is sending the lower ID
MSB-first is going to hit a zero bit sooner and assert the bus when another
one is letting it go. When the other device sees that something else is
sending a lower ID, it stops transmitting immediately and waits to retry
later. The rest of the intended packet flows undisturbed, with receivers
basically unaware that any contention happened at all.
But again, that means that two or more devices *could* begin transmitting
at the same time, so for a short time we have multiple senders yanking on
the bus, cutting the effective source impedance by half, or a third, or
however many tried to speak, all against the line termination. Thus, the
voltage sails higher until the losing device sees the other's dominant
bit and shuts up. The ID 524 packet must have won out over another with
a similarly high ID, so it took a few bit times to resolve. The 220 one later
took precedence within one bit time.
The string of zeros across the center has a sprinkling of ones; those are
the required "stuffing" bits which actually lengthen the packet's duration
a little. The rule is, any five consecutive bits the same must be followed
by one of the opposite polarity, to keep receiver clocks synced and avoid
building DC bias on the bus. A little bias happens anyway; you can see the
slightly higher tail after the ACK bits before it settles back down.
You could almost guess the number of participating ECUs on the network from
this, assuming their transceivers are reasonably within impedance spec. It's
also clear that the powertrain bus is busy enough that there *is* a notable
amount of contention. Imagine the mess if the car had only one CANbus, like
the Prius or any older car before the advent of packet gateways.
And to answer the original question, the OBD2 queries *do* show up on this
bus after passing through the gateway. I'll bet with a little creative
packet construction and monitoring, we could effectively "portscan the
firewall" and see what it actually passes through or doesn't. I'm sure
the D-CAN is as isolated as it is to prevent an aftermarket tool or logging
widget from jabbering insanely and crashing the whole car. Once in a while
I would plug the Scangauge back into the Prius and have it immediately
light the whole dashboard with errors and throw a U code, due to some brief
instance of a mangled partial packet or bus voltage out of whack at the
moment of connection. That's the hazard of having your DLC on the live
critical path.
The world really is analog. If it moves back and forth fast enough, we
call it digital. I'll talk about packet contents in another post.
_H*
