CAN Protocol Overview

CAN is the most popular protocol for automotive vehicles. Learn about the CAN protocol and its particularities in this article

Even if you've never worked in the automotive industry, there is no way around it: at some point, you heard about CAN (Controller Area Network). Today, we'll turn the house inside out. We'll learn how the ECU's are interconnected via the protocol, the configuration parameters and their influence in the signals exchanged on the bus.

So, let's start with the hardware. The CAN protocol allows the ECU's to communicate with each other with only two cables and two resistors on each end. Aside fromt that, you'll need a CAN transceiver, or you can go the DIY route, although these are fairly inexpensive, so why bother? Besides, choosing a transceiver can have some advantages. For example, you can set it up to wake up your ECU in some specific messages, saving energy. In each end of the bus, the two 120 ohm resistors prevent the signals reaching each end to be reflected, avoiding interference and maintain the DC levels between the bus. When in idle, each CAN line carry 2.5V. When signals are being transmitted, there is a 2.5V difference between the lines, with CANH rising to 3.75V and CANL dropping to 1.25V. When both lines are at idle, you get a recessive bit (1) and, in the opposite case, you get a dominant bit (0). Lastly, let's talk distance: the cable length can go from 30 meters (1 Mbps) to 1 km (62.5 kbps).

CAN bus hardware connection

Regarding the CAN frames, these are comprised of the SOF (Start of Frame), followed by the CAN idenfier (in which we call the arbitration phase). The CAN-ID can be of 11 bits (standard frame) or 19 bits (extended frame). Then, one bit specifies the RTR (Remote Transmission Request), which differentiates between a message (dominant bit) and a request frame (recessive bit). The next bit is the IDE (IDentifier Extension), which specifies if the ID is standard (dominant) or extended (recessive), followed by a reserved bit. The next four bits specify the DLC (Data Length Code), which for non CAN-TP frames is between 0 and 8. Then, we receive the data, depending on the DLC chosen. After that, we get a 16-bit CRC (well, 15, one is for the CRC delimiter). The last four bits are the ACK slot (receiver sends a recessive and sender sends a dominant bit) and the last 11 bits are recessive: ACK delimiter (1 bit), EOF - End of Frame (7 bits) and IFS - Inter-Frame Spacing (3 bits).

A particularity, CAN never has more than 5 consecutive bits of the same value. Since CAN is a synchronous bus, it requires a rising or falling edge to resynchronize the clocks between all CAN controllers. This is called bit stuffing. The stuffing bit only server for synchronization purposes.

The internals of a CAN frame (source - Wikipedia)

Lastly, let's discuss CAN bit timing and how to calculate it. The bit timing (time necessary to carry one bit) is measured in time quanta (just a basic time unit) can be divided into four parts:

• SYNC_SEG (Synchronization Segment) - used to synchronize all the bus nodes and indicate the start of a bit transmission. Its length is 1 time quanta
• PROP_SEG (Propagation Segment) - its purpose is to compensate signal delay errors across the network. Programmable from 1 to 8 time quanta
• PHASE_SEG1 (Phase Segment 1) - compensates edge phase errors across the network. Programmable from 1 to 8 time quanta
• PHASE_SEG2 (Phase Segment 2) - also used to compensate edge phase errors. The maximum length is from 1 to PHASE_1

In between the PHASE_SEG1 and PHASE_SEG2, you will find the SAMPLE_POINT, which is specified as a percentage. A bigger sample point allows for a maximum cable length.

How to calculate these parameters? Well, you can use a calculator from the internet. No need to get scared.

Can bit timing

Just as some ending notes, there is more to explore. We only dug the surface when it comes to CAN. In the future, we'll cover some particular CAN topics: CAN-TP, CAN-FD and TT-CAN. Stay tuned!