OtoDünyam
DEEP TECHNICAL CONTENT

First Checks on a CAN Network

First Checks on a CAN Network: CAN is a differential serial bus; on a conventional high-speed CAN network two 120 Ω end terminations appear as about 60 Ω with the network powered down. The page also includes a worked example and measurement sequence.

6 concrete technical facts1 worked example2 sources

Technical frame

First Checks on a CAN Network: CAN is a differential serial bus; on a conventional high-speed CAN network two 120 Ω end terminations appear as about 60 Ω with the network powered down. The page also includes a worked example and measurement sequence.

The technical values here expose the standard, protocol or physical relationship directly; model-specific service values are linked through the matching model/variant dossier.

The goal is not only to define the term but to let the reader calculate and interpret what the data means in a scan, scope or physical test.

Concrete technical facts

  • CAN is a differential serial bus; on a conventional high-speed CAN network two 120 Ω end terminations appear as about 60 Ω with the network powered down.
  • CAN-H and CAN-L operate differentially for common-mode noise rejection; checking only one wire voltage is not enough.
  • The arbitration identifier sets priority between nodes transmitting at the same time; a dominant bit overwrites a recessive bit.
  • Classical CAN is standardized up to 1 Mbit/s, while CAN FD can use a higher bit rate in its data phase.
  • CAN error handling tracks bit, stuff, CRC, form and ACK errors through error counters; a node can progress to error-passive or bus-off as counters rise.
  • A Classical CAN data frame carries 0–8 payload bytes; CAN FD can carry a longer payload and use a different data-phase bit rate.

Worked example

  • Termination example: 120 Ω || 120 Ω = 60 Ω. With the network powered down/asleep, roughly 120 Ω instead of ~60 Ω suggests that one termination branch is missing.

Measurement and verification sequence

  • Measure termination resistance with the network powered down/asleep.
  • Capture CAN-H/CAN-L both separately and differentially with a scope.
  • Log bit rate, error frames and bus-off state.
  • Do not randomly disconnect ECUs without understanding network topology.

Fault-separation logic

  • Is a valid command present and are power/ground/network healthy?
  • Does feedback follow the command?
  • Does an independent physical measurement confirm the output?
  • Is the fault limited to a specific temperature/load/speed condition?
  • Does the result remain stable when the original condition is repeated after repair?

Technical sources

  1. Otodünyam Technical Editorial Dictionary R3
  2. CAN in Automation · CAN knowledge

Continue investigating

Model-specific real technical data · Measurement references · Technical diagnostic atlas