Cookies: Our site uses cookies in order to deliver better content. By continuing you accept these cookies.


Ultimate CAN Bus Guide 2024: A Detailed Look at the Protocol

Updated at 29 Jan, 2023

— Delve into CAN Bus: its pivotal role in vehicle communication and why every auto enthusiast should know it. Your comprehensive CAN Bus guide awaits.

Ultimate CAN Bus Guide 2024: A Detailed Look at the Protocol
Welcome to our deep dive into the CAN bus protocol. With over 70% of modern vehicles relying on this system for communication, understanding its characteristics is more crucial than ever. Join us as we unravel its complexities.

It does not matter if you have no knowledge about the CAN bus protocol or if you are already a pro. This simple CAN bus guide intro, will give you all the information needed. Several topics have been covered, to give you the best explanation of the CAN protocol.

While working on the article, we combined the knowledge from our top experts within the company, as well as non-expertise team members.

Why? The idea was to write a professional but simple guide introduction to the CAN bus for everyone, no matter how much experience you have.

Diagram of a car's CAN bus with two ECUs connected by high and low signal lines.

What is CAN Bus?

CAN bus is a set of two electrical wires in the car network (CAN_Low and CAN_High), where the information is sent to and from ECUs. The network that allows Electronics Control Units (ECUs) to communicate is called Controller Area Network (CAN).

The CAN bus is a serial communication bus, designed for robust performance within harsh environments, primarily in industrial and automotive applications.

It is a vehicle bus standard that allows microcontrollers and devices to communicate with each other.

CAN bus is one of the protocols used in On-Board Diagnostics (OBD). Nowadays, the OBD-II is mandatory in all newer cars and light trucks all around the globe.

CAN Bus simple explained

Let's try to look at the CAN bus system from a different point of perspective.

Picture a car as the human body; just as our nervous system facilitates communication within us, the Controller Area Network (CAN Bus) does the same for the car.

Nodes or ECUs acts similarly like body parts, interconnected via the CAN bus. Just as body parts communicate easily, these components share information effortlessly. Simplifies things, doesn't it?

Car outline with CAN bus nodes and connections illustrating network layout.

CAN Bus Infographics

A detailed infopgrahics about the CAN Bus technology

Click the image to see the full infographics.

What is CAN Bus System?

In various cars, there can be as many as 80 ECUs, each requiring communication with other network segments.

Imagine ECUs as specific characters in a play. One ECU can craft a message and convey it via the CAN bus to its fellow actors (other ECUs). Much like a receiver deciding to respond to a letter or discard it, these ECUs evaluate the information and choose either to act on it or disregard it.

The CAN bus uses two communication wires known as CAN low (CANL) and CAN high (CANH). These standards governing the CAN bus are outlined in ISO 11898. While ISO 11898-1 covers the data link layer, ISO 11898-2 defines the physical layer.

  • ISO 11898-1 (Data Link Layer):

    • Addresses the communication protocol and its mechanisms.

    • Defines message framing, arbitration, error handling, and more.

    • Focuses on how data is transmitted and received within the network.

  • ISO 11898-2 (Physical Layer):

    • Describes cable types, node requirements, and electrical signal levels.

    • Specifies cable lengths: 40 meters for 1 Mbit/s and 500 meters for 125 kbit/s.

    • Outlines factors like cable impedance, baud rate, and necessary terminations.

  • Termination: Every CAN bus must be properly concluded with a 120 Ohms resistor at each bus end.

  • CAN Nodes Connection: Linked via a two-wire bus system with baud rates of up to 1 Mbit/s for standard CAN and 5 Mbit/s for CAN FD.

Diagram showing two CAN bus nodes with controllers and identifiers linked by a bus network.

What are the Key Components within a CAN Bus System?

In our previous discussions, we've touched upon various aspects of the CAN Bus system, a critical technology in modern automotive and industrial communications. Let's delve deeper into the key components that form the core of a CAN Bus system, ensuring its efficient and reliable operation.

  1. Electronic Control Units (ECUs): ECUs are the 'brains' of the CAN Bus, controlling specific functions like engine management or airbag deployment in vehicles. They process and act on the information received via the CAN Bus.

  2. CAN Controller: This component acts as a bridge between the ECUs and the CAN network. It manages the sending and receiving of data packets, ensuring messages are correctly formatted and transmitted.

  3. CAN Transceiver: Working alongside the CAN Controller, the CAN Transceiver converts digital data into signals for transmission over the network and vice versa. This is essential for the communication across the network's nodes.

  4. Bus Lines (CAN_H and CAN_L Wires): The physical wires of the network, CAN_H and CAN_L, are the backbone of the CAN Bus system. They transmit signals between nodes, even in environments with significant electrical noise.

Together, these components ensure the efficient and reliable operation of the CAN Bus system in various settings, from automotive to industrial applications.

Top 5 CAN Bus Protocol Advantages

The CAN bus protocol is a key communication system used in cars and industry. It helps parts of a vehicle talk to each other smoothly. When CAN bus was created, its goal was to make wiring simpler and electronics less complicated.

Many vehicles now use the CAN bus system because of its clear benefits, such as:

  • Durability:

    • The CAN bus standard is designed for important uses, especially in vehicles, thanks to its strength and trustworthiness. It also has five methods to detect and correct errors; bit stuffing, bit monitoring, frame check, acknowledgment check, and cyclic redundancy check.

  • Cost-Effective:

    • CAN bus protocol was developed to support quick communication between devices, all while reducing errors and cutting down on unnecessary wires and costs.

  • Speed Varieties:

    • It offers two types: High-Speed CAN and Low-Speed CAN, each tailored for specific needs.

  • Adaptable Design:

    • The CAN bus protocol setup is message-based, allowing parts to be added or taken away without a total system overhaul. This design lets engineers introduce new gadgets with minimal adjustments.

  • Efficient Data Handling:

    • Urgent information is identified and processed immediately, ensuring smooth operations without interruptions.

Graphic highlighting CAN Bus benefits: Robustness, Low Cost, Speed, Flexibility, Efficiency.

CAN bus wiring

One key benefit of the CAN bus is its ability to minimize wiring while smartly avoiding message clashes.

Simply put, it ensures no data goes missing when sent.

In the example below, we are comparing two scenarios - one with the CAN bus and one without - which highlights the difference.

With the CAN bus, communication between nodes is streamlined and straightforward. Without it, nodes struggle to effectively communicate.

Comparison of linear and star CAN bus network topologies with multiple nodes.

There are various network types, especially in areas like CAN bus wiring. For a clearer understanding of these nuances, keep reading below.

High-speed CAN bus (ISO 11898)

  • Supports bit rates between 40 kbit/s and 1 Mbit/s.

  • Simple cabling.

  • Most commonly used these days.

  • The basis for higher layer protocols such as OBD2, CANopen, j1939, and more.

Low-speed CAN bus

  • Supports bit rates between 40 kbit/s and 125 kbit/s.

  • Allows communication to continue despite the fault in one of the two wires.

  • Also known as a fault-tolerant CAN.

  • Each CAN node has its own CAN termination.

LIN bus

  • Low-cost supplement.

  • Less harness.

  • Cheaper nodes.

  • Usually consists of a LIN bus master, which is acting as a gateway - up to 16 slave nodes.

  • Typically includes vehicle functions such as door functionality or air conditioning.

Automotive Ethernet

  • Ethernet supports high bandwidth requirements of Advanced Driver Assistance Systems (ADAS), cameras, infotainment systems, and so on.

  • Provides much higher data transfer rates than the CAN bus.

  • Lacks safety features of CAN and CAN FD.

  • Most likely will be used commonly in the upcoming years within the automotive industry.


  • Typically used in modern high-performance vehicles.

  • CAN FD is an extension of the original CAN bus protocol.

  • Released in 2012 by Bosch.

  • Developed to meet the need to increase data transfer.

The AutoPi CM4 Device
Are You Maximizing Your CAN Bus Communication's Potential?

Discover Unmatched Efficiency with Our Telematics Device - Try It Now and Elevate Your Performance!

What is a CAN message frame?

CAN frames plays an important role in CAN communication across the CAN bus. This communication method uses a differential signal, defined by two logic states: dominant and recessive.

Within CAN communication, there are two distinct message types: standard CAN and extended CAN, which we will delve into below.

The following illustration depicts a prevalent CAN frame with an 11-bit identifier, the kind predominantly found in vehicles. Expect for its extended ID, the 29-bit identifier frame remains consistent with standard CAN communication practices.

Standard CAN frame

Diagram of a CAN bus data frame showing fields for arbitration and data payload.

Here is a breakdown of the different fields in the Standard CAN Frame:

  1. SOF (Start of Frame):

    • Length: 1 bit

    • Purpose: Indicates the beginning of a CAN frame. It is always dominant bit (0 in CAN).

  2. ID (Identifier):

    • Length: 11 bits

    • Purpose: Represents the priority and the address of the transmitting node. In CAN, the lower the identifier value, the higher the priority.

  3. RTR (Remote Transmission Request):

    • Length: 1 bit

    • Purpose: Used to differentiate a data frame from a remote request frame (RTR = 0 for data frames and RTR = 1 for remote request frames).

  4. Control

    • Length: 6 bits

    • Purpose: Contains control information like the data length code (DLC) which indicates the number of bytes in the data field.

  5. Data:

    • Length: 0 to 64 bits (0 to 8 bytes)

    • Purpose: Contains the actual data being transmitted. Its length is determined by the DLC in the control field.

  6. CRC (Cyclic Redundancy Check):

    • Length: 16 bits

    • Purpose: A polynomial code used to detect errors during data transmission. The transmitting node computers a CRC value based on the frame content and sends it along with the frame. The receiving node then calculates its own CRC from the received frame and compares it to the received CRC. If they match, it's assumed that the frame was received correctly.

  7. ACK (Acknowledgement):

    • Length: 2 bits (one for the slot and one for the delimiter)

    • Purpose: The ACK slot is overwritten with a dominant bit by nodes that correctly receive the frame. If the transmitting node sees a dominant bit in the ACK slot, it knows that at least one other node on the network received its frame correctly. Following, there is an ACK delimiter bit, which is always recessive (1 in CAN).

  8. EOF (End of Frame):

    • Length: 7 bits

    • Purpose: Marks the end of a CAN frame. It consist of 7 consecutive recessive bits, ensuring that there's enough separation between consecutive frames.

In addition to the fields described above, actual CAN communication also involves some other fields and error handling mechanisms not depicted in this standard CAN frame. These include:

  • Interframe Space: A time interval between two consecutive frames.

  • Error Frames: If a node detects an error in a frame, it will transmit an error frame to notify other nodes of the error.

  • Overload Frames: Used to introduce a delay between consecutive data or remote transmit frames.

Extended CAN frame

The extended CAN frame uses a 29-bit identifier with a couple of additional bits. The extended 29-bit identifier (CAN 2.0B) is identical, but has a longer ID and is usually used in the j1939 protocol - heavy-duty vehicles. CAN uses two logic states; dominant and recessive.

  • Dominant:

    • Pinpoints that the differential voltage is greater than the minimum threshold. In addition, the dominant state is also achieved by driving a logic ‘0’ onto the bus.

  • Recessive:

    • Pinpoints that the differential voltage is less than the minimum threshold. On the other side, the recessive state is achieved by a logic ‘1’.

It also has a substitute remote request (SRR) bit, which comes after an 11-bit identifier and acts like a placeholder, to keep the same structure as a standard CAN frame.

The identifier extension (IDE) should be recessive and the extended identifier should follow it accordingly.

The remote transmission request (RTR) comes right after the 18-bit ID. The reverse bit r1 follows the path and the rest of the message stays the same.

Extended CAN bus frame layout with bit-lengths for each segment illustrated.

The AutoPi CM4 Device
Are You Ready for the Adventure of Real-Time CAN Bus Access?

Explore New Frontiers in Vehicle Data and Optimize Diagnostics with Our Cutting-Edge Tool Today.

CAN bus data logging

Logging CAN data can be done from several types of vehicles such as cars, heavy-duty vehicles, predictive maintenance, and machine black box.

The vehicle data are gathered through the OBD2 port and are usually used to reduce fuel costs, improve car mileage, and more.

On the other side, data from heavy-duty vehicles are gathered through j1939 and are usually used to improve safety and reduce costs.

Vehicles and machinery can also be monitored through IoT CAN loggers. That can be done in the cloud to avoid breakdowns. A CAN logger can provide data for disputes or diagnostics. It is also called a black box.

CAN bus logging is commonly used in fleet management, due to its effectiveness and increased number of opportunities.

A CAN logger is required to record CAN data. This allows you to save timestamped CAN data on an SD card. In some situations, a CAN interface is required to transmit data to a PC, such as when decoding data.

Example: TMU CM4

The TMU CM4 allows you to record data from any CAN bus to an 8-32 GB Micro SD Card with ease. Simply plug it to the OBD-II port within a car or truck to begin logging, and then interpret the data using AutoPi Cloud.

Furthermore, the TMU CM4 has Wi-Fi, allowing you to automatically upload data to your own server - as well as upgrade devices over the air.

Network diagram of an ECU, various devices, and display connected via CAN bus, with a telematics unit.

Decoding raw CAN data

Raw CAN data is not easily readable. Therefore we have prepared a guide for you. Check out the guide on how to log raw CAN messages.

The CAN bus supports the basis for communication, but not more than that. The CAN protocol doesn’t indicate how to handle messages greater than 8 bytes, or how to decode the RAW data.

To indicate how data is communicated between CAN nodes of a network, a set of standardized protocols come in handy. There are several higher-layer protocols such as; OBD2, CANopen, CAN FD, and SAE J1939.

A high-speed transfer data rate offers DoIP diagnostics, more precisely approximately 100 times of CAN diagnosis.

Screenshot of a terminal displaying hexadecimal CAN bus data sequences.

History of CAN bus

Control Area Network (CAN bus) has a rich history and went through several development stages. The actual development stages within years can be seen below.

  • Development of the CAN bus goes back to 1983 when Bosch originally invented Control Area Network which was later codified into ISO 11898-1 standard.

  • The CAN protocol was later released to the Society of Automotive Engineers (SAE) in 1986.

  • Intel was the first one to introduce the CAN controller chips in 1987, and Phillips joined Intel shortly after that.

  • In 1991, Bosch published CAN 2.0 (CAN 2.0A: 11 bit, 2.0B: 29bit).

  • CAN bus as an international standard in ISO 11898, was adopted in 1993.

  • In 2003, ISO 11898 became a standard series.

  • In 2012, Bosch has released the CAN FD 1.0 - flexible data rate.

  • In 2015, the CAN FD protocol has become standardized in ISO 11898-1.

  • Lastly, the physical CAN layer up to 5Mbit/s has become standardized in ISO 11898-2, in 2016.

Timeline graphic showing key historical events in the development of CAN bus technology.

In the future, CAN bus will still be commonly used, but influenced by major automotive industry trends such as; the growth of the Internet of Things and connected vehicles, the impact of autonomous vehicles, the rise of cloud computing, the need for advanced vehicle functionality, and more.

The need for CAN FD increases and many experts assume it will slowly replace the classical CAN bus protocol. Stay updated to see what happens.

The AutoPi Devices

Embark on a Journey of Discovery and Unveil Secrets Admired by Thousands.

Why Not Uncover the Secrets of Vehicle Data Today?

Other posts you will like

Connected Car Tech: Your Ultimate Guide (2024)
Smart Topics

Connected Car Tech: Your Ultimate Guide (2024)

Explore connected car technology and understand the role of 5G and vehicle-to-everything (V2X) communication and how it's shaping the future of drivin ...

Telematics Explained - A Simple Intro (2024 Guide)
AutoPi Telematics Unit Internet of Things Fleet Management

Telematics Explained - A Simple Intro (2024 Guide)

Learn about telematics systems. Understand how telecom and informatics unite to improve vehicle tracking, safety, and efficiency, in an easy-to-grasp ...

How to Build a Raspberry Pi Car Computer (In 7 Easy Steps)
Raspberry Pi DIY

How to Build a Raspberry Pi Car Computer (In 7 Easy Steps)

Step-by-step to your own carputer! Our detailed, easy-to-follow guide helps you to effortlessly build a car computer in just 7 straightforward steps.


Get in touch with us – We're ready to answer any and all questions.

* Mandatory fields

Email our engineers

We are here to help!