Today I put a quick temporary tap on the P-CAN bus, just to see what's going on in there. Most of the buses arrive behind the gateway module [the beige thing which also holds the interior fuse block] on a single small connector with a short leash to the harness. Not easy to get hold of to gently strip a wire and get a miniclip onto it, laying half into the footwell with just enough room to move my hands. It's a little messy as my grounding probably wasn't the best, and I was only looking at CANH and not in differential mode. The bus is quite busy as we'd expect, with a whole range of IDs from low 1nn up to mid 5nn. All 11-bit IDs as far as I saw. The scope was able to capture a couple of "event table" packet dumps, but making any sense out of it is likely for another day, if ever, and very different equipment. I'll bet that many of the OBD2 figures we have to specifically ask for just fly by here all the time in different formats. _H*
In case you haven't seen these, Eric Reuter in the Boston area tapped into the P-CAN bus used by the gear selector to bypass the gateway, I assume unterminated. He built a prototype VESS replacement, and as far as I know no one else has explored any further. I bought a CANable USB transceiver to look at this stuff as well but haven't had the motivation yet.
Huh... if he's in my area, I should probably try to hunt him down for a bit o' geeking. I can certainly answer his gateway question. _H*
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*
Since discussions of packet contents are more appropriate to the OBD2 and monitoring thread, I've posted the second half of the day's discoveries over there. _H*
