CAN bus - Priority/collision

Question

I have a hard time understanding how a CAN bus can actually work. It looks to me like a scenario where everyone is talking at the same time.

The CAN bus is simply two wires that everyone is connected to, CAN-H and CAN-L, right? If we have lets say four nodes on it, with ID's 1, 2, 3, and 4, just to make it simple. The priority of the messages are arranged from highest id to lowest, 4, 3, 2, 1, right? CAN-H is always opposite of CAN-L, when CAN-H is high, CAN-L is low, and opposite, right?

But how do CAN bus avoid collision on the bus? Lets say node 3 is done talking, how do they decide who is next? If node 1 and 4 decides at the same time to transmit data to the bus, it would result that data that are transmitted to the bus is corrupt, since two nodes are transmitting at the same time?

If node 1 is transmitting binary 00100110 and node 3 is transmitting 11011001 at the same time, it would result that both CAN-H and CAN-L is high at the same time?

Can someone example to me how CAN avoids situations like this?

Answer 1

Funny that with so many correct answers, I still feel like something is amiss or not clear enough. Even most complete answer by @Nick does not correct some wrong assumptions in the question. So, I'll try to make it simpler.

CAN-H is always opposite of CAN-L, when CAN-H is high, CAN-L is low, and opposite, right?

Wrong. CAN physical layer is unique within many differential buses because it uses wired-AND signalling. While most of them indeed pull data lines in two opposite directions, CAN drivers work as open drain (CAN-L) and open-source (CAN-H). So CAN-L can be either low or high-Z, and CAN-H can be either high or high-Z (well... technically, the transceivers include weak biasing resistors pulling common mode to mid-supply). This prevents electrical collisions, since nodes either actively pull lines in the same direction or let them go and allow termination resistors to equalize the voltage between the lines.

The downside of this, of course, is that slew rate of the dominant-to-recessive transition cannot be increased beyond certain point, effectively limiting the bus speed.

If we have lets say four nodes on it, with ID's 1, 2, ...

CAN nodes do not have an ID. The IDs usually introduced by higher CAN-based protocols, such as CANopen. But keep reading...

The priority of the messages are arranged from highest id to lowest, 4, 3, 2, 1, right?

Wrong. The priority of the messages is defined by arbitration field, which includes message ID (either 11 or 29 bits) and RTR bit. I believe CAN FD includes even more bits into arbitration but I am a little bit fuzzy on that new standard.

The bit arbitration is done by CAN controller by monitoring the bus while they are sending. If a node detects a dominant level when it is sending a recessive level itself, it will immediately quit the arbitration process and become a receiver.

Since the dominant bit is logically 0, it follows that the message with numerically lowest arbitration field will win the arbitration, i.e message with ID=1 has priority over message with ID=4.

Now, back to node IDs. Some CAN-based protocols include either sender or target node ID as part of their message ID format. This will effectively create node hierarchy, so in this case node IDs will affect the priority. But again, this is not done on CAN data link layer.

how do CAN bus avoid collision on the bus?

The answer is - it does not. Or, more precisely, not completely. We already established that electrical collisions are avoided by wired-AND signalling.

Logical collisions can be avoided completely by making source node ID a part of arbitration field and enforcing node ID uniqueness. However it is rarely done in practice.

More often message IDs are carefully mapped by their priority in particular application and further distributed between nodes with different functions so that each node can only send messages within its own unique range. This approach further reduces chances of collision.

If node 1 and 4 decides at the same time to transmit data to the bus, it would result that data that are transmitted to the bus is corrupt, since two nodes are transmitting at the same time?

This scenario does not necessarily make data corrupt. If the messages have different arbitration fields the first node losing arbitration will stop transmitting, allowing the other node to send complete correct message.

This, of course, does not eliminate collisions entirely. If two nodes trying to send messages with identical arbitration fields they both will remain active after the arbitration and might collide in the data fields. If this happens, CRC will be used to detect frame error and the message will be discarded by the receivers, prompting re-transmitting by the senders.

In short, ACK confirmation bits, Error frames and CRC validation are used to ensure data integrity and deal with consequences of logical collisions.

Lets say node 3 is done talking, how do they decide who is next?

There is nothing in CAN data link layer to help with this. Any node can start sending as soon as it detects idle bus.

Although, there is one important detail in the CAN specification - the transmitting node is required to send 8 recessive bits after 3 bits intermission at the end of last frame, for 11 bits total. The nodes with pending messages wait for 7 recessive bits EOF and 3 bits intermission for 10 bits total before they can attempt to transmit. This guarantees that same node cannot send more than one remote or data frame if there are other nodes waiting for the bus to become idle.

However there are several methods to improve this behavior in higher layer protocols. For example, variable delay between bus going idle and starting the transmission can be introduced, making sure nodes have equal opportunities to start talking.

More complicated mechanisms include round-robin scenarios or centralized bus management nodes that orchestrate communication.

Answer 2

First let's clarify something. CAN bus addressing works on message IDs. CAN bus itself doesn't have node IDs. (One could create a scheme for where some kind of node ID is a part of the message ID, or a part of the data. But such scheme isn't required by the CAN bus spec.)

But how do CAN bus avoid collision on the bus? Lets say node 3 is done talking, how do they decide who is next? If node 1 and 4 decides at the same time to transmit data to the bus, it would result that data that are transmitted to the bus is corrupt, since two nodes are transmitting at the same time?

The arbitration in the CAN bus is based on message IDs. A message with the smallest ID wins the arbitration. CAN bus defines 0 as "dominant" and 1 as "recessive". The logic levels for 0 are actively driven by transistors. The logic levels for 1 are passively pulled by resistors.

When a node wants to transmit a 1, it releases the lines an allows it to be pulled by resistors. The transmitting node also monitors the line to see if it actually gets pulled to 1. If it doesn't get pulled to 1, that means that some other node had driven the lines to 0. This contested 0 isn't a collision or an undefined condition. It's a bonafide bit. The node which wanted to transmit a 1 knows that it had lost the arbitration, and it stops transmitting the frame (until the bus is free).

If node A is transmitting binary 00100110 and node C is transmitting 11011001 at the same time, it would result that both CAN-H and CAN-L is high at the same time?

Let's look at the very first bit in this example. Node C will try to transmit 1. But it will be be unable to transmit 1, because node A is transmitting 0 at the same time. 0 is stronger than 1. Node C will know that somebody else is transmitting 0, and node C will stop transmitting until the bus is free.

Answer 3

There’s a collision detection algorithm which relies on the fact that the physical layer works with dominant and recessive signals. Dominant refers to logical bit 0 and recessive 1. It’s called dominant because any node which wants to transmit 0 can bring the bus to 0 even if another node tries to change the bus to 1. Ok, now CAN doesn’t have a master node, and yes, any node can start a transmission any time it feels like after checking that the bus is idle.

Now the algorithm takes place. Whenever a node starts transmitting a message it begins sending a unique ID, which is the message ID. While it writes 0s and 1s into the bus it also reads the bus to confirm that the bus is changing according to its ID. Why? Because the ID is what determines the message priority. If there’s another node trying to send a message It’s doing the same thing but with a different ID. At some point there’ll be a collision because one node will be writing 0 and reading 0 but the other node will try to write 1 but it will read 0 (remember 0 is dominant). The last node must than stop sending the message because it detected a collision and the first node can finish its transmission. After the message is finished the node which lost the priority can retry sending its message and the cycle starts all over.

Answer 4

1.) CAN does NOT avoid situations such as collision. As a shared network of babbling ports collisions are part of the communication process.

2.) Let's say Port A puts data on a shared CAN bus. At the instant it put data on the bus there was no 'collision' flag, which senses collisions by both voltage and current corruption which corrupts the data, forcing highs and lows to be 'mangled', and detection of existing data on the bus.

3.) Now Port B attempts to put data on the same bus, but 1 of 2 things happens.

• Collision/Busy flag is set due to detection of data on the bus, so it waits so many mS before trying again. It will keep trying after short delays until the Busy flag is clear. The port with the highest priority wins any collision event.

• No Busy/Collision flag set so it puts data on the bus, but within a few bits of the first byte a collision is detected and the Busy/Collision flag is set for this port. It aborts transmission and resets its byte pointer to resend the first byte when possible. It can only hold or take the bus if it has the higher priority.

4.) This means Port B goes into a retry and delay mode until it can put data on the bus with no collision detected. It clears its collision flag and sends the data. It now owns the bus even if other ports try to put data on it, as they will sense the data first or collide with it, setting their own collision flag and going into a retry-delay loop until the bus is clear. It can only hold or take the bus if it has the higher priority.

5.) This sounds like mayhem where little data can flow. The key to making this work is different delay times before a retry is attempted. If the ports have a priority assigned to them the highest priority has the shortest wait time, but even so all ports on a shared line can send at least 1 data packet per second.

6.) Remember that CAN is used like I2C for short burst of data. Unless coded otherwise any port can be a master, though a true master can reset all ports on the bus if collisions dominate traffic flow instead of data packets. The programmer has a few arbitrary choices about delays and any priorities and if there is a master that can reset the bus, etc.

7.) For the most part internal hardware is supposed to keep things running from the start, but a skilled programmer can make it run better. In a large shared bus there are very likely some ports/devices that need to have a high priority assigned to them, such as low battery detection, main power fault, etc.

8.) Because there is no set protocol (other than common sense), a variety of protocols can be used. Per data packet only an ACK and possibly a CRC is required, to give a sense of start and stop and check for errors. Collisions can result in errors so a CRC checksum is a good idea.