Brief Introduction to CAN Bus Protocol

Keywords: Embedded systems, Serial Communication, CAN Bus

CAN is a multi-master, broadcast, asynchronous, serial messaging protocol designed by Bosch in 1986 for Automotive applications.
Remember, CAN is not an address based protocol, neither its a handshaking based; which means there is no way a message can be directed towards a single specific node/device on bus. The messages are simply broadcasted i.e. Any device (in interested) in received packet, can read/interpret received data.

The beauty of CAN protocol is there is no limitation on devices communicating on bus. Adding or removing devices has absolutely no effect on CAN bus except on application itself. Devices can be added to or removed from bus on fly.

1. CAN vs OSI Model:

Before we can go deeper into CAN bus hardware specifications, let’s touch the lyrical structure of CAN bus specifications. CAN confirms with the lower two layers of OSI 7-layer model. We will just briefly explains what each layer is responsible for, Figure-1.

Figure-1: CAN Bus Layers

We will reference each CAN layer in respective section.

2. CAN bits Representation:

CAN bus, under nominal condition remains at 2.5V. This state is considered as Logic-1 and called Recessive bit in CAN specifications. Don’t think of it as the regular transmission of logic-1 on bus… Well yes, sort of – but this state is merely considered logic-1 during transmission.

When ever the transmission of Logical-0 is required, the CAN-High (see 3.2 CAN Bus) line is pulled up while the CAN-Low line is pulled low. This state is called Dominant bit in CAN specifications. Figure-2.

Figure-2: CAN Bus states

3. CAN on Hardware Level:

On broader level, CAN communication involves a bunch of compatible devices (called NODES) connected to two wire bus end to end connected with 120Ω resister, Figure-3.

Figure-3: CAN Bus, with N-Nodes.

Let’s get a little deeper into Hardware involved in CAN bus communication. Following are the main components involved in CAN bus communication.

  • CAN Bus
  • CAN Controller (ECU)
  • CAN Transceiver

3.1 CAN Bus:

CAN bus physically is no more than a twisted pair of electrical wires end to end connected with each other via 120Ω resister, Figure-4. The voltage level at both bus wires remains at 2.5V, thus the potential difference between two wires is always zero under Recessive state. The key benefit of this configuration is if the bus is noisy still the potential difference between two wires will remain same as the noise will affect both bus wires simultaneously. One wire is called CAN-High (because the voltage level at this wire is pulled up to 3.75V during Dominant bit) while the other wire is called CAN-Low (because the voltage level at this wire is pulled down to 1.25V during Dominant bit). There is nothing much special about it. Its not the wires that do the magic rather its the CAN Controller and CAN Transceiver thats implements CAN protocol.

Figure-4: CAN Bus

The question that’s worth asking is the reason behind 120Ω resister. For that we have to go a little bit deeper in Transmission Line Theory which we truly don’t wanna touch here. Kvaser [3] has given very good to the point answer to this question. I will quote here for reference.

“Most automotive cables are single wire. If you take the wires typically used in a car and twist them into a pair, you will get an impedance of 120 Ohm. If you then squeeze the twisted wires into a cable, the impedance typically drops to 105 Ohm and then use thin isolation – as exemplified in CAT5 cable – the impedance drops to 100 Ohm.”

“A 120 Ohm resistor is not the optimal ending resistor when using a CAT5 cable for your CAN-bus, but it is good enough for a slew-rate of 50 nanoseconds at 1 Mbit/s. If bit-rate is increased to 100 Mbit/s and slew-rate of a few nanoseconds is sought, there will be problems … but this is more than even CAN-FD will ever reach.”

3.2 CAN Controller:

This is the part of CAN hardware which implements Data Link Layer of OSI-Model. As shown in figure-1, this piece of hardware has two main functionalities. To filter incoming messages (as by default every node/device on can bus recessives every packet. its upto node to interpret/read the packet or reject/filter the message) (LLC Layer), and to packetize data (MAC Layer). The LLC sub-layer is active during message/packet reception while MAC sub-layer is active in both transmission and reception. The MAC sub-layer is required because CAN protocol follows special pre-defined packet format to be sent over the CAN Bus. Thus the MAC sub-layer pack data bits into CAN format and sent it for transmission.

This part of CAN hardware comes as a part Microcontroller chips and also available as standalone IC e.g. SJA1000.

3.3 CAN Transceiver:

The CAN transceiver connects the CAN controller to the physical transmission medium. This is the part of CAN hardware which produces actual bits signaling on physical bus and thus implements the Physical Layer of OSI Model. As we mentioned earlier that CAN bus specify the characteristics of both 0,1 bits representation which are encoded in NRZ format. Once the data is packet into CAN packet format (coming later), it is sent to CAN transceiver which thus convert the packet 0’s and 1’s into electrical pluses as shown in Figure-5.

Figure-5: CAN Controller and Transceiver Output

Kind of funny but whenever I think of CAN transceiver, it reminds me the following Gym Guy where the man represent CAN transceiver and rope represent kind of Electrical Pules (figure-5) on CAN bus.

Figure-6: CAN Transceiver Analogy

CAN Transceiver doesn’t defines full Physical Layer of OSI model, rather it defines it partially. More detail on the topic is beyond the scope of basic-level tutorial.

All the above three main hardware components can be summarized by the following Figure-7 [4].

Figure-7: CAN Hardware Complete at a glance

4. CAN Framing:

In section 3.2, we mentioned that the CAN Controller basically defines the Data-Link Layer of OSI Model whose main Job apart from filtration is packetization i.e Data to be sent, must be encoded into CAN specification defined packet called CAN Frame. All CAN messages are sent in these well defined Frame format. In this section we will discuss CAN Frame format in detail.

CAN Frame exact format depends on CAN Standard. There are two types of CAN implementations depending in the size of the identifier field.

  1. STANDARD: 11-bit wide identifier field.
  2. EXTENDED: 29-bit wide identifier field.

Figure-8,9 show STANDARD and EXTENDED frame format respectively.

Figure-8: CAN Standard Frame

Figure-9: CAN Extended Frame

SOF: Start of Frame – 1 bit. This bit indicates start for CAN Messages/Frame. Its always a Dominant bit (0) and is used for Hard Synchronization.

Identifier: This message identifier basically defines the application dependent message identification. As CAN is broadcast messaging protocol which mean every message is open to be received by any ECU/Node on CAN bus. So in order to differentiate messages from one another for application, each message is assigned user defined ID. The same identifier defines message priority i.e. the lower the ID the greater the priority. In other words the more zeros on the right side of first recessive bit (logic-1), the higher will be the priority of the message. Similarly the same identifier is used by the CAN Controller to filter messages (Recall before mentioned LLC Layer). For CAN Standard, this is field is 11-bits while in CAN Extended, the message identifier is 29-bits split into two half.

RTR : Remote Transmission Request – 1 bit. If this bit is set Dominant (0), it indicates Remote Frame (discussed later). Remote Frame simply means: Hey, can somebody send some data on CAN bus with the same ID as used for this message. Remote Frames are usually used to ask for services from another ECU/Node on CAN bus.

IDE: Identifier Extension – 1 bit. It is used to specify the frame format. Dominant bit is for CAN Standard Frame and recessive for CAN Extended Frame.

R0, R1: Reserved for future use.

DLC: Data Lengthn – 4 bits. These bits contains the lenght of data packet – maximum 8-bytes.

DATA: Message Data – 8 Bytes. The data to be sent on CAN Bus.

CRC: Cyclic Redundancy Check – 16 bits. Checksum of data field. This will be calculated by CAN Controller and is used for Error detection.

ACK: Acknowledge – 1 bit. Optional acknowledge may be send back by any node receiving data correctly. A Dominant bit indicates acknowledge while the recessive bit indicates no-acknowledge.
Note even if a single node on bus send acknowledge where all the remaining nodes have not received data correctly, still the message acknowledge form that single node will be considered as successful transmission.

EOF: End of Frame – 7 bits. 7 continuous recessive bits sent indicates END of current message Frame.

IFS: Inter Frame Space – 3 bits. Two continuous frames are separated by inter-frame space. This gives some time to ECUs to process previously message.

SRR: Substitute Reverse Request – 1 bit. The SRR bit is always transmitted as a recessive bit to ensure that, in the case of arbitration between a Standard Data Frame and an Extended Data Frame, the Standard Data Frame will always have priority if both messages have the same base (11 bit) identifier.


[1] – An Inroduction to CAN

[2] – Understanding CAN Protocol

[3] – CAN-Using termination to ensure recessive bit transmission

[4] – CAN Layered Architecture

55 thoughts on “Brief Introduction to CAN Bus Protocol”

Leave a Reply

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