CAN Bus Signaling and Bit Representation

Thread Starter

Embededd

Joined Jun 4, 2025
157
I am trying to understand what it actually means when we say we are sending a dominant or recessive bit on a CAN bus.

In a digital system, logic levels are usually measured relative to ground for example, 0 V for logic 0 and 5 V for logic 1. when a line is set to 5 V we say we are sending logic HIGH, and when it is at 0 V we say we are sending logic LOW on the communication bus but I do not understand how this concept applies on a CAN bus.

Imagine a typical CAN bus setup where two nodes are connected through CAN H and CAN L lines, and the bus is terminated at both ends with 120 Ω resistors.
1778235646113.png

Could you please explain how dominant and recessive bits are represented in terms of voltage levels on CAN H and CAN L lines with respect to ground? Also, how does the receiver determine whether the transmitted bit is dominant or recessive?
 

panic mode

Joined Oct 10, 2011
5,000
imagine output stage, an NPN transistor with resistor in collector circuit. transistor is dominant. when it is on, voltage drops. resistor is recessive/accommodating mood of transistor... in a network with two or more nodes connected in parallel (which is what bus is), dominant node is one that pulls line low. it overrides other nodes that try to assert high...
 

Papabravo

Joined Feb 24, 2006
22,083
A recessive bit is not driven by an active device. It is established by passive elements such that CAN_H ≈ CAN_L ≈ ½*Vcc. This condition is enforced by the termination resistors. For a Vcc of +5V this would be 2.5 volts, and for a Vcc of 3.3V this would be 1.65 Volts. ALL CAN receivers on the bus will monitor the difference between CAH_H and CAN_L and see a recessive bit when they are approximately equal. For a +5 Volt system a dominant bit requires that CAN_H - CAN_L be driven by active devices such that the difference is greater than or equal to +2 Volts. I don't have any experience with 3.3 V CAN busses, but the CAN specification will identify an appropriate value. If I had to guess it would be greater than or equal to 1.32 Volts.

Remember that CAN is a sampled data system, so it is the value of CAN_H-CAN_L at the sampling point in the bit frame that is relevant. This is so that reflections on the cable system have died out BEFORE the sampling point.
 

drjohsmith

Joined Dec 13, 2021
1,609
The can bus
Is a "standard" initially developed by Bosch cars for use in vehicles
A good overview and links is here
https://en.wikipedia.org/wiki/CAN_bus
Can is a two wire bus,
Its basic data / logic levels are NOT voltages relative to "earth" , but a current flow..
Two wires , say A and B .
Send current out of A , through end termination , back to B , is say '1'
Send current out of B , through end termination , back to A , is say '0'

Might be confusing , advantage is it helps receivers to distinigrate between noise on both lines and signal.

To add confusion .
"Side' signals were added in some versions of the spec .
Things like drive A and B 'high' voltage as a attention signal .
 

Thread Starter

Embededd

Joined Jun 4, 2025
157
A recessive bit is not driven by an active device. It is established by passive elements such that CAN_H ≈ CAN_L ≈ ½*Vcc. This condition is enforced by the termination resistors. For a Vcc of +5V this would be 2.5 volts, and for a Vcc of 3.3V this would be 1.65 Volts. ALL CAN receivers on the bus will monitor the difference between CAH_H and CAN_L and see a recessive bit when they are approximately equal. For a +5 Volt system a dominant bit requires that CAN_H - CAN_L be driven by active devices such that the difference is greater than or equal to +2 Volts. I don't have any experience with 3.3 V CAN busses, but the CAN specification will identify an appropriate value. If I had to guess it would be greater than or equal to 1.32 Volts.
Okay, please correct me if my understanding is wrong.

Let’s say we have two nodes, Node A and Node B, connected to the CAN bus. Each node consists of an MCU and a CAN transceiver.

When Node A wants to transmit a bit, the MCU sends a logical bit (0 or 1) to its CAN transceiver.

For example, if the MCU sends a dominant bit (logic 0 in CAN), the transceiver converts this logic level into differential voltages on the bus, such as:

CAN_H = 3.5 V
CAN_L = 1.5 V

This creates a differential voltage CAN_H − CAN_L = 2.0 V

The CAN transceiver in Node B continuously monitors both CAN_H and CAN_L. It calculates the voltage difference between them, and if the difference is large enough (for example, around 2 V), it interprets the bus state as dominant and outputs the corresponding logic bit to the MCU.

If both lines are approximately equal (for example, CAN_H ≈ CAN_L ≈ 2.5 V in a 5 V system), the differential voltage is near 0 V, and the receiver interprets this as a recessive bit (logic 1 in CAN).

So, in summary, the MCU deals with logic bits, while the CAN transceiver converts those bits into differential voltages for transmission and converts the received differential voltage back into logic bits for the MCU.

Is this understanding correct?
 

Papabravo

Joined Feb 24, 2006
22,083
Okay, please correct me if my understanding is wrong.

Let’s say we have two nodes, Node A and Node B, connected to the CAN bus. Each node consists of an MCU and a CAN transceiver.

When Node A wants to transmit a bit, the MCU sends a logical bit (0 or 1) to its CAN transceiver.

For example, if the MCU sends a dominant bit (logic 0 in CAN), the transceiver converts this logic level into differential voltages on the bus, such as:

CAN_H = 3.5 V
CAN_L = 1.5 V

This creates a differential voltage CAN_H − CAN_L = 2.0 V

The CAN transceiver in Node B continuously monitors both CAN_H and CAN_L. It calculates the voltage difference between them, and if the difference is large enough (for example, around 2 V), it interprets the bus state as dominant and outputs the corresponding logic bit to the MCU.

If both lines are approximately equal (for example, CAN_H ≈ CAN_L ≈ 2.5 V in a 5 V system), the differential voltage is near 0 V, and the receiver interprets this as a recessive bit (logic 1 in CAN).

So, in summary, the MCU deals with logic bits, while the CAN transceiver converts those bits into differential voltages for transmission and converts the received differential voltage back into logic bits for the MCU.

Is this understanding correct?
That is correct, but again it is the value of the differential voltage at the sampling point that determines the value for a bit in a message. The bus should always be in a recessive state between frames
 

Thread Starter

Embededd

Joined Jun 4, 2025
157
That is correct, but again it is the value of the differential voltage at the sampling point that determines the value for a bit in a message. The bus should always be in a recessive state between frames
Thanks, Papabravo for your help. Your explanations have made the CAN concepts much easier for me to understand.

I now have a question about synchronization in CAN.

Protocols like SPI and I2C are synchronous because they use an clock signal. The transmitter places data on the bus, and the receiver samples the data based on the clock edges.

CAN is also considered a synchronous protocol, but I do not see any separate clock line on the bus only CAN_H and CAN_L. Each node is configured with a specific baud rate.

So my doubt is:
how do all nodes stay synchronized in CAN communication without a dedicated clock signal? How does the receiver know exactly when to sample each bit, and how is synchronization maintained ?
 

drjohsmith

Joined Dec 13, 2021
1,609
Thanks, Papabravo for your help. Your explanations have made the CAN concepts much easier for me to understand.

I now have a question about synchronization in CAN.

Protocols like SPI and I2C are synchronous because they use an clock signal. The transmitter places data on the bus, and the receiver samples the data based on the clock edges.

CAN is also considered a synchronous protocol, but I do not see any separate clock line on the bus only CAN_H and CAN_L. Each node is configured with a specific baud rate.

So my doubt is:
how do all nodes stay synchronized in CAN communication without a dedicated clock signal? How does the receiver know exactly when to sample each bit, and how is synchronization maintained ?
Read the wiki article ,describes why can is really asynchronous ,
 

Ian0

Joined Aug 7, 2020
13,132
The protocol limits the number of ones or zeroes in a row to 5. After that it inserts and extra bit of the opposite polarity, so that gives it an edge so that it can keep itself in sync.
 

Papabravo

Joined Feb 24, 2006
22,083
Clock synchronization is derived from the actual bit stream. There are two features of the CAN system that allow this to happen.
  1. The maximum length of a message is limited.
  2. Bit stuffing limits the number of consecutive bits that can happen without a transition from zero to one or from one to zero.
Each CAN node has a clock which runs at a significant multiple of the maximum bit rate. Usually this will be from 12-24 times the maximum bit rate. A typical system would have a 16 MHz. clock for a 500 kHz. channel. The actual bit timing and the location of the sample point is determined by the values loaded into configuration registers. Receivers are allowed to adjust the timing of received bits, in units of the high frequency clock subject to certain limitations. Every receiver on the network will insist that transmitters must maintain accurate timing or they will flag timing errors.

The rule on stuff bits is that after five(5) consecutive bits of a particular value, a bit of the opposite polarity is inserted by every transmitter and removed by every receiver. Wait you say: "How can there be multiple transmitters?". During the arbitration phase, SOF(Start of Frame) to the end of the identifier field, there can be as many transmitters as there are nodes on the cable system. The only time this is a problem is if the higher- level protocol allows two or more nodes to transmit the identical identifier. This is a major BOZO no-no on any CAN network.

Homework: What is the maximum message length before bit stuffing is applied?
 
Last edited:

Thread Starter

Embededd

Joined Jun 4, 2025
157
What is the maximum message length before bit stuffing is applied?
I think your question may not be phrased correctly.

Bit stuffing is performed by the transmitter as the frame is being sent, starting from the Start of Frame (SOF) and continuing through the 15-bit CRC sequence, as described in the CAN specification (see page 22, Bit Stuffing).

http://esd.cs.ucr.edu/webres/can20.pdf

1778349671982.png


In a standard CAN frame with 8 data bytes

  • Total frame length (without any inserted stuff bits) = 108 bits
  • Number of bits over which bit stuffing can be applied = 98 bits

The remaining 10 bits are not subject to bit stuffing:

  • CRC delimiter = 1 bit
  • ACK field = 2 bits (ACK slot + ACK delimiter)
  • End of Frame (EOF) = 7 bits

(see attached frame format diagram):
1778349781701.png

If the intent is to ask how many consecutive identical bits can be transmitted before a stuff bit is inserted, then the answer is five.

So I believe the question needs to be clarified depending on what exactly is meant.
 

Papabravo

Joined Feb 24, 2006
22,083
I think your question may not be phrased correctly.

Bit stuffing is performed by the transmitter as the frame is being sent, starting from the Start of Frame (SOF) and continuing through the 15-bit CRC sequence, as described in the CAN specification (see page 22, Bit Stuffing).

http://esd.cs.ucr.edu/webres/can20.pdf

View attachment 366974


In a standard CAN frame with 8 data bytes

  • Total frame length (without any inserted stuff bits) = 108 bits
  • Number of bits over which bit stuffing can be applied = 98 bits

The remaining 10 bits are not subject to bit stuffing:

  • CRC delimiter = 1 bit
  • ACK field = 2 bits (ACK slot + ACK delimiter)
  • End of Frame (EOF) = 7 bits

(see attached frame format diagram):
View attachment 366975

If the intent is to ask how many consecutive identical bits can be transmitted before a stuff bit is inserted, then the answer is five.

So I believe the question needs to be clarified depending on what exactly is meant.
What I intended to ask was how long would a complete message be if there were no stuff bits. This gives you a number to work with to guage the effect of differences between the transmitter clock and the receiver clock. Since they will never be exactly equal, the question relates to how probable is a correction, allowed by the SJW field, in a message of a given length without stuff bits. Then assuming every 5th bit is a stuff bit you have a bound on the probability of clock adjustments in a worst case message.
 

drjohsmith

Joined Dec 13, 2021
1,609
Fyi
The systems I've worked on, the receivers self calibrate the bit periods on the fly .
All sorts of algo in place , but in practise the different systems / specs were getting a pain to implement , so the "search" receive was universal.
 

Thread Starter

Embededd

Joined Jun 4, 2025
157
What I intended to ask was how long would a complete message be if there were no stuff bits.
then for a standard CAN data frame with an 11-bit identifier and 8 data bytes, the total frame length is 108 bits.

This includes:

  • SOF: 1 bit
  • Arbitration field: 12 bits
  • Control field: 6 bits
  • Data field: 64 bits
  • CRC field (15-bit CRC + 1-bit delimiter): 16 bits
  • ACK field: 2 bits
  • EOF: 7 bits

Total = 108 bits

Suppose four nodes A, B, C, and D are connected to the same CAN bus.

If Node A starts transmitting and sends the Start of Frame (SOF), my understanding is that the bus is now considered busy, so the other nodes must wait until the current frame is completed and the bus becomes idle again before attempting to transmit.

If that understanding is correct, then consider the case where Node A transmits five consecutive bits of the same value (for example, five recessive bits: 11111) in a part of the frame where bit stuffing is active.

I think, Node A's CAN transmitter automatically insert the complementary bit (in this case, a 0) as part of the transmitted bit stream, while all other nodes' simply monitor the bus and remove that stuffed bit during reception?
 

Papabravo

Joined Feb 24, 2006
22,083
The status of the bus is not determined until the end of the arbitration field. The node with the lowest message identifier (greatest number of leading dominant bits) wins the arbitration and continues transmitting. The other nodes with identifiers which are numerically greater than the winning node will switch to receive mode and look for errors. The actual mechanism for losing arbitration is to transmit a recessive bit as part of the identifier field and see a dominant bit from the receiver. The losing transmitter immediately accepts the loss and switches to being a receiver.
 

Thread Starter

Embededd

Joined Jun 4, 2025
157
The status of the bus is not determined until the end of the arbitration field. The node with the lowest message identifier (greatest number of leading dominant bits) wins the arbitration and continues transmitting. The other nodes with identifiers which are numerically greater than the winning node will switch to receive mode and look for errors. The actual mechanism for losing arbitration is to transmit a recessive bit as part of the identifier field and see a dominant bit from the receiver. The losing transmitter immediately accepts the loss and switches to being a receiver.
I would like to share my current understanding of CAN communication. Please correct me if anything I say is incorrect or misleading, because I do not want to keep any wrong concepts in my mind.

CAN is a message-based protocol. This means that when one node transmits a message, all other nodes on the CAN bus can receive that message. Each receiving node decides whether to accept or ignore the message based on its acceptance filters and masks.

CAN is also a multi-master protocol, which means any node can start transmitting whenever the bus is idle.

When a node wants to transmit a message, it should follows a fixed frame format.

First we send the Start of Frame bit which indicates communication is starting.

Next sends the Arbitration field which contains the Message ID and RTR bit. The RTR bit decides whether the frame is a data frame or remote frame.

Then next is the Control field. It contains the IDE bit which decides whether the message ID is 11-bit or 29-bit. It also contains DLC which tells how many bytes of data are being sent. In Classical CAN maximum data size is 8 bytes. example If we want to send 2 bytes of data we need to say length is 2 bytes

After that actual data is transmitted.

Next is the CRC field which is used for error detection. The receiver recalculates the CRC and compares it with the received CRC value.

Then next is the ACK field. If at least one receiver gets the message correctly, it sends ACK to the transmitter.

Finally EOF (End of Frame) is sent which indicates communication is finished.

Now in CAN, multiple nodes may try to start transmission at the same time when the bus is idle. In that case arbitration happens.

CAN uses two logical bus states:

  • Dominant = logic 0
  • Recessive = logic 1

If both states are transmitted simultaneously, the dominant state overrides the recessive state.

For example:

Node A transmits identifier bits: 1 0 1
Node B transmits identifier bits: 1 0 0

At the third bit position:

Node A transmits recessive (1)
Node B transmits dominant (0)

The actual bus value becomes dominant (0). Node A detects that it transmitted a recessive bit but observed a dominant bit on the bus, so it knows it has lost arbitration. Node A immediately stops transmitting and switches to receive mode, while Node B continues transmitting.

This is called arbitration because the winning message is transmitted without corruption.

CAN also uses bit stuffing to maintain synchronization. From the Start of Frame (SOF) through the CRC sequence, if the transmitter detects five consecutive bits of the same value, it automatically inserts one bit of the opposite value.

For example:

11111 becomes 111110

The receiver removes this stuffed bit before processing the frame. If a receiver detects six consecutive bits of the same value, it recognizes this as a bit stuffing error.

Please let me know if this understanding is correct. If it is, I have a few additional doubts I would like to discuss.
 

Papabravo

Joined Feb 24, 2006
22,083
All of that appears to be substantially correct.

One more thing:

When ANY receiver on the network detects an error of any type it throws (transmits) an ERROR frame. There are two types of ERROR frames known as ERROR active and ERROR passive. An ERROR active frame is 7 consecutive dominant bits. This will cause any active transmitter to detect a STUFF error, and it will then proceed to also throw an ERROR frame. There are error counters inside every CAN controller that place the controller on one of three states:
  1. Error Active - normal operation. Detected errors are below the specified level.
  2. Error Passive - errors are increasingly frequent. The ERROR frame is 7 consecutive recessive bits.
  3. Bus Off - Node can no longer be allowed on the buss due to an excessive number of errors.
In the systems using 11-bit identifiers, the transition from Error Active to Error Passive was a count of 128. The transition from Error Passive to Bus Off was a count of 256. CAN Spec revisions since 2006 may or may not have changed these values.
 

Thread Starter

Embededd

Joined Jun 4, 2025
157
All of that appears to be substantially correct.
What I think is, if two nodes try to send messages with the same message ID at the same time, then arbitration cannot decide a winner in the arbitration field because both nodes are transmitting identical bits and both keep seeing the same bus value they transmitted. So both nodes continue transmission together. If the complete frame including data is also identical, then both nodes can successfully transmit the message together. But if any bit becomes different later in the frame, then the node transmitting recessive 1 and reading dominant 0 on the bus will lose arbitration and stop transmitting.

But practically, two different nodes are usually not supposed to send different messages with the same message ID because message ID normally represents a unique message type , so this situation is rare in real CAN systems
 
Top