CAN Protocol and its Description

Bosch’s CAN protocol, first released in 1986, also provided advancements in communication. CAN is short for ‘controller area network’. Controller area network is an electronic communication bus defined by the ISO 11898 standards. Those standards define how communication happens, how wiring is configured and how messages are constructed, among other things. Collectively, this system is referred to as a CAN bus.

A vehicle contains a network of electronic devices that share data and information with one another. A spark-ignition engine, for instance, requires a spark to initiate the combustion chamber. Timing is important here. To ensure this occurs accurately, it “communicates” with the vehicle’s engine control unit, which chooses the ideal time for the ignition to provide the power and fuel efficiency.

Benefits of CAN Protocol:

  • Low cost: Since a CAN serial bus uses two wires (with high-volume and low-cost production), it offers a good price-to-performance ratio.
  • Reliable: CAN protocol offers excellent error-detection and error-handling mechanisms, which provides highly reliable transmission. It’s also largely immune to electromagnetic interference.
  • Flexible: CAN nodes are not limited by the protocol and can be easily connected or disconnected.
  • Fast: CAN protocol supports a data rate of 1 MBit/s @ 40m bus length.
  • Multi-master communication: Any node can access the bus
  • Fault confinement: Faulty nodes do not disturb the communication.
  • Broadcast capabilities: Messages can be sent to one /many/all nodes.
  • Standardized: ISO has standardized the CAN protocol via ISO-DIS 11898 (for high-speed applications) and ISO-DIS 11519-2 (for low-speed applications). The CAN protocol is also standardized by industry organizations, such as the SAE-Society of Automotive Engineers.

CAN Protocol Terminology

CAN devices send data across the CAN network in packets called frames. A CAN frame consists of the following sections.

  • CAN Frame –an entire CAN transmission: arbitration ID, data bytes, acknowledge bit, and so on. Frames also are referred to a messages.

Figure 2. The standard CAN frame format.

  • SOF (start-of-frame) bit – indicates the beginning of a message with a dominant (logic 0) bit.
  • Arbitration ID – identifies the message and indicates the message’s priority. Frames come in two formats — standard, which uses an 11-bit arbitration ID, and extended, which uses a 29-bit arbitration ID.
  • IDE (identifier extension) bit – allows differentiation between standard and extended frames.
  • RTR (remote transmission request) bit – serves to differentiate a remote frame from a data frame. A dominant (logic 0) RTR bit indicates a data frame. A recessive (logic 1) RTR bit indicates a remote frame.
  • DLC (data length code) – indicates the number of bytes the data field contains.
  • Data Field – contains 0 to 8 bytes of data.
  • CRC (cyclic redundancy check) – contains 15-bit cyclic redundancy check code and a recessive delimiter bit. The CRC field is used for error detection.
  • ACK (ACKnowledgement) slot – any CAN controller that correctly receives the message sends an ACK bit at the end of the message. The transmitting node checks for the presence of the ACK bit on the bus and reattempts transmission if no acknowledge is detected. National Instruments Series 2 CAN interfaces have the capability of listen-only mode. Herein, the transmission of an ACK bit by the monitoring hardware is suppressed to prevent it from affecting the behavior of the bus.
  • CAN Signal – an individual piece of data contained within the CAN frame data field. You also can refer to CAN signals as channels. Because the data field can contain up to 8 bytes of data, a single CAN frame can contain 0 to 64 individual signals (for 64 channels, they would all be binary).

Bus Termination:

An ISO 11898 CAN bus must be terminated. This is done using a resistor of 120 Ohms in each end of the bus. The termination serves two purposes:

  1. Remove the signal reflections at the end of the bus.
  2. Ensure the bus gets correct DC levels.

An ISO 11898 CAN bus must always be terminated regardless of its speed. I’ll repeat this: an ISO 11898 CAN bus must always be terminated regardless of its speed. For laboratory work just one terminator might be enough. If your CAN bus works even though you haven’t put any terminators on it, you are just lucky.

Note that other physical layers, such as “low-speed CAN”, single-wire CAN, and others, may or may not require termination. But your vanilla high-speed ISO 11898 CAN bus will always require at least one terminator.


When two nodes attempt to transmit at the same time an arbitration process determines which one takes preference. While transmitting, each node reads the bus state as well. If a node detects that one of its recessive bits has been driven dominant by another node, then it stops transmitting. This results in lower IDs taking precedence over higher IDs. If a node looses arbitration, it will attempt to resend the message once the current transmission is complete. This behavior results in automatic prioritization and collision resolution.

CAN Protocol Network Structure:

Multiple nodes may be connected in parallel. The lines must be terminated on each end with a termination resistor (typically 100Ω to 120Ω) like RS485 . For high speed CAN bus, the network below included a termination resistor of 120Ω at each end.

Error Detection Mechanisms:

The CAN protocol defines no less than five different ways of detecting errors. Two of these works at the bit level, and the other three at the message level.

  1. Bit Monitoring.
  2. Bit Stuffing.
  3. Frame Check.
  4. Acknowledgement Check.
  5. Cyclic Redundancy Check.

Bit Monitoring
Each transmitter on the CAN bus monitors (i.e. reads back) the transmitted signal level. If the bit level actually read differs from the one transmitted, a Bit Error is signaled. (No bit error is raised during the arbitration process.)

Bit Stuffing
When five consecutive bits of the same level have been transmitted by a node, it will add a sixth bit of the opposite level to the outgoing bit stream. The receivers will remove this extra bit. This is done to avoid excessive DC components on the bus, but it also gives the receivers an extra opportunity to detect errors: if more than five consecutive bits of the same level occurs on the bus, a Stuff Error is signaled.

Frame check
Some parts of the CAN message have a fixed format, i.e. the standard defines exactly what levels must occur and when. (Those parts are the CRC Delimiter, ACK Delimiter, End of Frame, and also the Intermission, but there are some extra special error checking rules for that.) If a CAN controller detects an invalid value in one of these fixed fields, a Form Error is signaled.

Acknowledgement Check
All nodes on the bus that correctly receives a message (regardless of their being “interested” of its contents or not) are expected to send a dominant level in the so-called Acknowledgement Slot in the message. The transmitter will transmit a recessive level here. If the transmitter can’t detect a dominant level in the ACK slot, an Acknowledgement Error is signaled.

Cyclic Redundancy Check
Each message features a 15-bit Cyclic Redundancy Checksum (CRC), and any node that detects a different CRC in the message than what it has calculated itself will signal an CRC Error.

Peak CAN Analyzer:

The PCAN-USB adapter enables simple connection to CAN networks. Its compact plastic casing makes it suitable for mobile applications.
The opto-decoupled version guarantees galvanic isolation of up to 500 Volts between the PC and the CAN side.
The package is also supplied with the CAN monitor PCAN-View for Windows® and the programming interface PCAN-Basic.

Technical Specifications:

  • Adapter for the USB connection (Full-Speed mode, compatible with USB 1.1, USB 2.0, and USB 3.0)
  • High-speed CAN connection (ISO 11898-2)
  • Bit rates from 5 kbit/s up to 1 Mbit/s.
  • Time stamp resolution approx. 42 µs.
  • Compliant with CAN specifications 2.0A (11-bit ID) and 2.0B (29-bit ID).
  • CAN bus connection via D-Sub, 9-pin(in accordance with CiA® 303-1).
  • NXP SJA1000 CAN controller, 16 MHz clock frequency.
  • NXP PCA82C251 CAN transceiver.
  • 5-Volt supply to the CAN connection can be connected through a solder jumper, e.g. for external bus converter.
  • Galvanic isolation on the CAN connection up to 500 V (only for IPEH-002022).
  • Voltage supply via USB.
  • Extended operating temperature range from -40 to 85 °C (-40 to 185 °F)

Microchip CAN BUS Analyzer Tool:

CAN BUS Analyzer Tool is a simple to use low cost CAN bus monitor which can be used to develop and debug a high speed CAN network. The tool supports CAN 2.0b and ISO11898-2 and a broad range of functions which allow it to be used across various market segments including automotive, industrial, medical and marine. The toolkit comes with all the hardware and software required to connect a CAN network to a PC. The Graphical User Interface makes it easy to quickly observe and interpret bus traffic.


Originally created for automotive applications, CAN is a high-speed and reliable protocol for applications requiring robust communication at bit rates reaching 8 Mbps. The first production cars armed with CAN multiplex wiring systems rolled onto the streets nearly three decades ago, long before the commercial Internet or smartphones or digital media. Their introduction redefined the possibilities for in-vehicle communications and connectivity and triggered a perpetually evolving technology sector that has had far-reaching implications beyond the automobile. CAN offers key advantages to these and many other markets:

  • Automotive
  • Aviation
  • Agricultural
  • Building automation
  • Commercial transportation
  • Construction
  • Factory control
  • Marine
  • Medical
  • Military
  • Smart buildings

Leave a comment

Your email address will not be published. Required fields are marked *