CAN2.

0B [“Extended CAN”] Guide by Adrian Cires - Avionics Lead 2024-2025

Motivation
Understanding the underlying mechanism behind how the majority of our electronic
systems communicate is the first step to writing effective code. The first half of this guide will
focus on practical explanations, i.e. the basics of “how it works” and “how to use it.” The second
half of this document will go into more depth on some of the mechanisms behind CAN
communication.

Definition
CAN stands for Controller Area Network. CAN (and its derivatives) is a serial
communication protocol that lets us communicate with an (nearly) arbitrary number of devices
connected to the same CAN Bus (NOTE: It’s alright if you understood none of that, that’s why
I’m writing this guide). There is a distinction between CAN (the protocol) and the CAN Bus (the
physical wires that literally
connect each device). The CAN
Bus (pictured left) is literally just
two wires that are twisted together
and connected at each end by a
120 Ω resistor. The signal
(voltage) on each wire is the
inverse of the other, so when one
wire has a “high” signal, the other
will have a “low” signal, and
vise-versa.
The CAN Protocol is the set of
rules that each device connected
on the CAN Bus follows in order to communicate with each other. There are various different
versions of these rules, which make up different versions of the CAN communication protocol.
Some of these versions include CAN-FD, CAN2.0A, CAN2.0B, CANopen, etc.. It’s important to
note that these different versions are not directly compatible with each other, so a device
configured for CAN-FD cannot communicate with a device configured for CAN2.0B on the same
CAN Bus. The CAN communication protocol we will be using is CAN2.0B, sometimes referred
to as “CAN Classic” or “Extended CAN”. The main difference between CAN2.0A and CAN2.0B
is how many bits of Arbitration you have access to. CAN2.0A has 11 bits dedicated to Arbitration
while CAN2.0B has either 11 bits or 29 bits of Arbitration (you can choose). That’s actually the
reason that it’s called “Extended CAN,” because of the extended amount of bits you can use in
Arbitration.

Arbitration
Arbitration is the process of deciding which device has priority to send a message on the
CAN Bus. Since every device is sharing the same physical CAN Bus, only one device can send
a message at a time. You can start to imagine how tedious this process [of deciding] can get,
especially since CAN allows you to add/remove devices from the CAN Bus arbitrarily. That is,
there is no centralized controller that is deciding who can/cannot send messages nor in what
order messages are to be sent. Instead, because every device on a CAN Bus is following the
same set of “rules” defined by a common CAN communication protocol, every device knows this
information intrinsically.

Anatomy of a CAN message

Before we can understand how Arbitration literally happens, we have to understand how
a CAN message is composed. Below is the basic anatomy of a CAN2.0A message:

Credit: By Ken Tindell, Canis Automotive Labs Ltd, CC BY-SA 4.0,

https://commons.wikimedia.org/w/index.php?curid=109636302

Each message (payload, data, whatever you want to call it) sent over the CAN Bus is done so
within a predefined CAN frame. The CAN frame consists of different fields shown below (for
CAN2.0B “Extended CAN”):

Field name Length Purpose

(bits)

Start-of-frame 1 Denotes the start of frame transmission

Identifier A (green) 11 First part of the (unique) identifier which also

represents the message priority

Substitute remote 1 Must be recessive (1)

request (SRR)

Identifier extension bit 1 Must be recessive (1) for extended frame

(IDE) format with 29-bit identifiers
 Identifier B (green) 18 Second part of the (unique) identifier which
also represents the message priority

Remote transmission 1 Must be dominant (0) for data frames and

request (RTR) (blue) recessive (1) for remote request frames (see
Remote Frame, below)

Reserved bits (r1, r0) 2 Reserved bits which must be set dominant
(0), but accepted as either dominant or
recessive

Data length code 4 [a]

Number of bytes of data (0–8 bytes)
(DLC) (yellow)

Data field (red) 0–64 (0-8 Data to be transmitted (length dictated by

bytes) DLC field)

CRC 15 Cyclic redundancy check

CRC delimiter 1 Must be recessive (1)

ACK slot 1 Transmitter sends recessive (1) and any

receiver can assert a dominant (0)

ACK delimiter 1 Must be recessive (1)

End-of-frame (EOF) 7 Must be recessive (1)

Inter-frame spacing 3 Must be recessive (1)

(IFS)

If all of the above looks like gibberish to you, don’t worry. I’m going to explain some of the more
important fields now.

Identifier A & B
The identifier is exactly what it sounds like. The identifier is the ID associated with a
specific CAN frame. Notice, that the identifier is not necessarily the ID for any specific device
(though it can be and often is). Instead, the identifier is a number that represents the purpose of
a specific CAN frame. Say, for example, a CAN-compatible motor wants to send a message
broadcasting its current encoder value, the identifier would at least contain information such as
which motor is sending the encoder data. However, the identifier could also contain information
such as a specific recipient, what type of encoder value it’s sending (absolute vs relative), and
the fact that it is sending encoder data in the first place. That sounds like a lot of information, but
in practice it’s much simpler than I am making it out to seem.
The identifier is just a number. That’s it. It’s a sequence of 11 or 29 bits. Arbitration
(which message gets sent first, and which messages have to “wait in line”) is decided by the
lowest identifier number. This means that the CAN frame with the lowest identifier field will
be the frame that gets sent out first on the CAN Bus. I will go into some more specifics later
in this guide, but, practically speaking, this is all that you would need to know in order to write
effective code for CAN. If you want a message to have high priority, you would make the ID for
the message as small as possible. For example, an emergency stop message might have the
ID of “1”, and every device on the CAN Bus could be programmed to shut down if they read in
this message (this is assuming that you have full control over the CAN messages being sent,
though sometimes CAN-configured devices, such as certain motors, already come with a static
list of CAN commands/frames that they will send/accept. In this case, you would have to follow
their documentation when handling communications over CAN). Such a message (with ID of “1”)
could only be “beaten out” by a CAN frame with identifier “0”, which is the error identifier, and
you cannot define a CAN frame to use the identifier “0” since it is built in to the CAN protocol by
default.

Data Length Code (DLC)

The 4 bits that make up the DLC field are used to determine how long the message
payload within the CAN frame is going to be. Even though it’s 4 bits, the value of these 4 bits
can only be [0, 8] for CAN Classic (meaning CAN2.0A & CAN2.0B). If your CAN Bus is
configured for CAN Classic, and you attempt to send a message with a DLC field value higher
than 8, the devices on the CAN Bus will pull the frame down to 0 V, which indicates that an error
has occurred. For other protocols, such as CAN-FD, this DLC field operates differently.

Data Field
The data field is composed of 0-64 bits, or, equivalently, 0-8 bytes. The actual length is
determined by the DLC field. This is where the data for your message is sent. How that data is
structured is completely up to you (or a manufacturer if a device comes pre configured with CAN
messages). When designing a CAN frame, keep in mind that you will need to write the
complementary code to receive (and presumably use) the data from said CAN message, so
make it as simple or as crazy as you want--this part is up to you. In practice, writing this code is
more tedious than it is difficult, though I recommend that you start simple and get more complex
as you get more comfortable.

Configuring CAN on the Network

In the same way that the internet is a network, CAN is also a network. At least, you can
think of it that way. Various devices on the CAN Bus are sending information through CAN
frames. To make development easier, you can use something like a CAN2USB adapter. This
adapter plugs in to a usb port on your computer and allows you to access the CAN network. All
you need is a linux-based operating system and the adapter to get started. You can follow my
guide on installing a Linux vm if you don’t have one already.

ip link
- Shows what network devices you have access to
- “can0” is what the CAN interface device will typically be called

====================
From here on out, this document has been redacted specifically for challenge week. Do your
own research on how to access and send commands on the can line. To get started the
following command can be useful:

cansend can0 141#0000000034AB0001