Post History

71%

+3 −0

Q&A Why is the ACK (acknowledge bit) in the CAN bus frames dominant? What could have been the rationale behind that design decision?

You are forgetting that the transmitter plays part of it too. ACK is dominant simply because the transmitter sends ACK as recessive and any receiver must be able to override the recessive state of ...

posted 4y ago by Lundin‭ · edited 4y ago by Lundin‭

Answer

#3: Post edited by

Lundin‭ · 2020-10-30T10:06:21Z (about 4 years ago)
typo

Copy Link

Raw

Markdown

You are forgetting that the transmitter plays part of it too. ACK is dominant simply because the transmitter sends ACK as recessive and any receiver must be able to override the recessive state of the transmitter's ACK bit. There's no "three state" or such available to the transmitter.
CAN works like that in general, with the "CSMA/CA" collision avoidance. A transmitter tries to send out a bit, then checks if that bit indeed ended up at the expected level on the bus. If not - someone else sent a dominant bit, after which the node that tried to send humbly withdraws from the bus and makes another attempt to send when it is time for the next frame - for now, someone else with higher priority got the bus.
Also, CAN is decentralized and one specific node doesn't really care about "every other node on the bus". What should it do in case "every node but one got the message" - that's not practical information. Which one didn't get it? Why should the sender care? Was the node who didn't get the frame even interested in the data sent and how do we tell?
ACK serves to check if there is _at least one other node_ presnet. If not, there's a high chance that the transmitting node itself is broken/unplugged from the bus. That's much more useful information to the node itself: I might be broken, increase error counter and in case I keep getting no response over and over, go passive and fail-safe.

You are forgetting that the transmitter plays part of it too. ACK is dominant simply because the transmitter sends ACK as recessive and any receiver must be able to override the recessive state of the transmitter's ACK bit. There's no "three state" or such available to the transmitter.
CAN works like that in general, with the "CSMA/CA" collision avoidance. A transmitter tries to send out a bit, then checks if that bit indeed ended up at the expected level on the bus. If not - someone else sent a dominant bit, after which the node that tried to send humbly withdraws from the bus and makes another attempt to send when it is time for the next frame - for now, someone else with higher priority got the bus.
Also, CAN is decentralized and one specific node doesn't really care about "every other node on the bus". What should it do in case "every node but one got the message" - that's not practical information. Which one didn't get it? Why should the sender care? Was the node who didn't get the frame even interested in the data sent and how do we tell?
ACK serves to check if there is _at least one other node_ present. If not, there's a high chance that the transmitting node itself is broken/unplugged from the bus. That's much more useful information to the node itself: I might be broken, increase error counter and in case I keep getting no response over and over, go passive and fail-safe.

#2: Post edited by

Lundin‭ · 2020-10-30T08:33:07Z (about 4 years ago)

Copy Link

Raw

Markdown

You are forgetting that the transmitter plays part of it too. ACK is dominant simply because the transmitter sends ACK as recessive and any receiver must be able to override the recessive state of the transmitter's ACK bit. There's no "three state" or such available to the transmitter.
CAN works like that in general, with the "CSMA/CA" collision avoidance. A transmitter tries to send out a bit, then checks if that bit indeed ended up at the expected level on the bus. If not - someone else sent a dominant bit, after which the node that tried to send humbly withdraws from the bus and makes another attempt to send when it is time for the next frame - for now, someone else with higher priority got the bus.
Also, CAN is decentralized and one specific node doesn't really care about "every other node on the bus". What should it do in case "every node but one got the message" - that's not practical information. Which one didn't get it? Why should the sender care? Was the node who didn't get the frame even interested in the data sent and how do we tell?
ACK serves to check if there is _at least one other node_. If not, there's a high chance that the transmitting node itself is broken/unplugged from the bus. That's much more useful information to the node itself: I might be broken, increase error counter and in case I keep getting no response over and over, go passive and fail-safe.

You are forgetting that the transmitter plays part of it too. ACK is dominant simply because the transmitter sends ACK as recessive and any receiver must be able to override the recessive state of the transmitter's ACK bit. There's no "three state" or such available to the transmitter.
CAN works like that in general, with the "CSMA/CA" collision avoidance. A transmitter tries to send out a bit, then checks if that bit indeed ended up at the expected level on the bus. If not - someone else sent a dominant bit, after which the node that tried to send humbly withdraws from the bus and makes another attempt to send when it is time for the next frame - for now, someone else with higher priority got the bus.
Also, CAN is decentralized and one specific node doesn't really care about "every other node on the bus". What should it do in case "every node but one got the message" - that's not practical information. Which one didn't get it? Why should the sender care? Was the node who didn't get the frame even interested in the data sent and how do we tell?
ACK serves to check if there is _at least one other node_ presnet. If not, there's a high chance that the transmitting node itself is broken/unplugged from the bus. That's much more useful information to the node itself: I might be broken, increase error counter and in case I keep getting no response over and over, go passive and fail-safe.

#1: Initial revision by

Lundin‭ · 2020-10-30T08:31:21Z (about 4 years ago)

Copy Link

Raw

Markdown

You are forgetting that the transmitter plays part of it too. ACK is dominant simply because the transmitter sends ACK as recessive and any receiver must be able to override the recessive state of the transmitter's ACK bit. There's no "three state" or such available to the transmitter.

CAN works like that in general, with the "CSMA/CA" collision avoidance. A transmitter tries to send out a bit, then checks if that bit indeed ended up at the expected level on the bus. If not - someone else sent a dominant bit, after which the node that tried to send humbly withdraws from the bus and makes another attempt to send when it is time for the next frame - for now, someone else with higher priority got the bus.

Also, CAN is decentralized and one specific node doesn't really care about "every other node on the bus". What should it do in case "every node but one got the message" - that's not practical information. Which one didn't get it? Why should the sender care? Was the node who didn't get the frame even interested in the data sent and how do we tell?

ACK serves to check if there is _at least one other node_. If not, there's a high chance that the transmitting node itself is broken/unplugged from the bus. That's much more useful information to the node itself: I might be broken, increase error counter and in case I keep getting no response over and over, go passive and fail-safe.

Communities

Post History