How Does CAN Bus Work With OBD2? A Clear Guide 

That distinction clears up most confusion here: a physical network, a way of sharing it fairly, and a diagnostic standard laid on top.

CAN Bus and OBD2 Are Two Different Jobs

CAN, short for Controller Area Network, is a communication system for electronic control units, or ECUs. The engine, transmission, braking, airbag, and body modules all need to share information quickly, and CAN lets them do that without a separate wire for every possible connection.

OBD2, by contrast, is a diagnostic standard. It defines what a tester may ask, how trouble codes are structured, and which emissions-related live data must be available. In modern cars, those diagnostic messages usually travel over CAN, under the standard known as ISO 15765-4.

In short, CAN decides how messages move, while OBD2 decides what diagnostic questions mean. A network can work perfectly for driving yet still limit what a generic scanner can ask through the diagnostic port.

For the full contrast, see the guide to the difference between OBD2 and CAN, which separates the diagnostic standard from the network underneath it.

The Two Wires That Carry Everything

High-speed CAN uses a twisted pair: CAN High (CAN-H) and CAN Low (CAN-L). At the diagnostic connector, CAN-H is pin 6 and CAN-L is pin 14. The twisting is not cosmetic. It helps electrical noise affect both wires in a similar way, so the receiver can cancel much of it out.

The key idea is differential signalling. The receiver does not judge each wire alone; it looks at the difference between them. When the bus is idle, both lines sit at about 2.5 volts, so the difference is near zero. When a dominant bit is sent, CAN-H rises to about 3.5 volts and CAN-L falls to about 1.5 volts, giving a difference of about 2 volts.

Those are typical high-speed CAN values, not a pass-or-fail test for every vehicle, and a single voltage reading never proves a network is healthy. The practical point is that noise moving both lines together leaves their difference largely unchanged.

Two terminating resistors, usually 120 ohms each, sit at the ends of a high-speed CAN network. In parallel they give about 60 ohms across pins 6 and 14 with the ignition off. That is a useful clue, not a diagnosis by itself.

The physical side is covered in more detail in the guide to CAN pins on an OBD2 connector.

How Messages Get Priority Without a Boss

CAN has no central controller telling modules when to speak. Every node can try to transmit when the bus is idle, and every node listens to everything on the bus, ignoring messages it does not need. That is called broadcast communication.

Priority comes from the message identifier, not from the module sending it. A lower identifier value wins. During arbitration, a node that sends a recessive bit (1) but sees a dominant bit (0) on the bus stops transmitting and waits. The winning message continues without damage or retransmission, which is why the process is called non-destructive arbitration.

This matters for safety-related data: a braking or stability message can be given a high-priority identifier so a routine display update does not delay it. Low-priority messages simply wait, and on a very busy bus they can be delayed. Each frame also carries checks that help receivers reject corrupted data, rather than trusting a wrong speed, temperature, or torque value.

The Snap-on CAN bus guide describes the same voltage and arbitration behaviour for high-speed networks.

What Happens When You Plug In a Scanner

When a scanner plugs into the diagnostic port, it becomes another node on the diagnostic CAN network, usually through a gateway. It does not take over the car, and it does not rewire anything. It listens, then asks, then waits for answers in the same frame format other modules use.

1. Connect and identify the protocol. The scanner detects the vehicle protocol, commonly ISO 15765-4 CAN at 250 or 500 kilobits per second on a 2008-or-newer US car.
2. Send a diagnostic request. A generic request is often broadcast to identifier 0x7DF. It names a service mode, such as live data or stored codes, and sometimes a specific parameter ID (PID).
3. Receive addressed replies. Responding modules answer on their own identifiers, commonly starting at 0x7E8. The scanner matches each reply to the request and decodes it into a code, a value, or a status.
4. Split long replies when needed. Classic CAN frames carry up to 8 data bytes, so longer replies are split and reassembled by ISO-TP, defined in ISO 15765-2. That is why a VIN can still arrive over short frames.

For example, a request for vehicle speed asks for Mode 01, PID 0x0D. The responsible module replies with the raw byte, and the scanner converts it into kilometres or miles per hour. The scanner did not measure speed directly; it asked for a value the car already calculates.

The diagnostic rules sitting on top of CAN are explained in the guide to ISO 15765 OBD2. That page separates the CAN transport from the diagnostic services that use it.

Why One Reading Can Reach Many Systems

Because CAN is broadcast, one sensor value can serve several systems at once. Wheel speed is a familiar example. The braking system measures it, but the engine, transmission, instrument cluster, and stability systems may all use versions of the same information, each for a different job.

That sharing reduces wiring, but it also means a CAN fault can look confusing. A broken wire, a faulty module, or a short can disturb several systems, producing warning lights that seem unrelated. They do not necessarily mean each system has its own failed part; the shared conversation may have broken down.

Modern cars also use more than one CAN network, often separated by a gateway. Powertrain, chassis, body, and infotainment traffic may live on different buses. The diagnostic port usually reaches the gateway, not every internal bus directly, which is one reason access varies by vehicle and scanner.

What CAN Bus Does Not Give a Generic Scanner

Access to CAN is not the same as access to everything. A generic OBD2 scan is mainly an emissions-related view: standard trouble codes, standard live data, freeze-frame data, and readiness information where supported. Manufacturer-specific systems often need manufacturer-specific diagnostic sessions, sometimes called UDS, plus the right software and, on some newer cars, security access.

That boundary explains several common results. A scanner may read engine codes yet show nothing for ABS, airbags, or body modules. It may show a code but not the deeper manufacturer data behind it. It may connect on one car and fail on another because the second car uses a different protocol, a gateway rule, or a bus the generic tool cannot reach.

CAN FD, a faster variant with larger payloads, appears in newer vehicle networks, but generic OBD2 diagnostics over ISO 15765-4 should not be assumed to be CAN FD simply because a car uses it internally.

Whether a given car uses CAN at all for diagnostics depends on year and market, as explained in the guide to whether all OBD2 vehicles use CAN bus. Older US cars, for example, may use J1850 or K-line protocols instead.

When the CAN Link Itself Is the Problem

A scanner that powers on but cannot communicate points first to the link, not to a fault code. Useful checks, in order, are power and ground at the port, ignition state, a firmly seated connector, and whether the tool is set to automatic protocol detection. A damaged pin, a blown diagnostic-port fuse, or an aftermarket device interfering with the bus can all produce the same “no communication” result.

If those checks pass and the car also shows several unrelated warnings, a network fault becomes more likely than a single sensor fault. That is a sensible point to stop DIY electrical testing, because probing live CAN wires without a plan can create new faults.

For a fuller fault-finding order, see the guide on what to do when an OBD2 scanner will not connect.

Frequently Asked Questions

Does every OBD2 car use CAN bus?

No. CAN became mandatory for US OBD2 diagnostics from model year 2008, but earlier cars may use J1850, ISO 9141-2, or KWP2000. Check the protocol your scanner detects, rather than assuming CAN from the port shape alone.

Are CAN High and CAN Low two separate data streams?

No. They carry mirror-image versions of the same signal. The receiver reads the difference between them, which helps reject electrical noise that affects both wires together.

Why does my scanner connect to one car but not another?

The second car may use a different protocol, need the ignition in a different state, have a port power or pin problem, or sit behind a gateway that limits generic access. Start with power, seating, and automatic protocol detection before assuming the scanner is faulty.

Can a generic OBD2 scanner read everything on the CAN bus?

No. It mainly reads standardised diagnostic data. Manufacturer-specific body, chassis, and security-gated data usually need a more capable tool and the correct diagnostic session for that vehicle.

Is CAN bus the same as OBD2?

No. CAN is the vehicle network that moves messages between modules. OBD2 is the diagnostic standard that defines which questions a tester can ask and how the answers are structured.

What speed does OBD2 over CAN run at?

Commonly 250 or 500 kilobits per second under ISO 15765-4. The exact rate depends on the vehicle, so a scanner set to automatic detection is usually the safer choice.

Conclusion

CAN bus works with OBD2 by giving diagnostic messages a fast, shared, noise-resistant path between modules and the scan tool. OBD2 supplies the questions and the meaning; CAN supplies the transport, the priority rules, and the error checking. Once that split is clear, scanner limits make sense: a working network can still gate manufacturer data, and a failed network can mimic several unrelated faults. Check the link first, and leave deeper network faults to proper diagnosis.