Why is the ACK (acknowledge bit) in the CAN bus frames dominant? What could have been the rationale behind that design decision?
[I’m asking this question out of curiosity. I understand that this aspect of the CAN bus specification is what it is, and can not change.]
The ACK bit in any CAN data frame is dominant. Each receiving node sets the ACK dominant when it receives a data frame, and doesn’t detect errors. Dominant ACK acts as a wired NOR. When the transmitting node sees the ACK in the dominant state, it knows that at least one other node had received the frame without errors.
From the ACK bit alone, the transmitting node can’t determine if all nodes have received the message. From the ACK bit alone, the transmitting node can’t determine if the nodes to whom it may concern have received the message.
If this ambiguity needs to be resolved, then a higher level protocol which runs on top of CAN should have acknowledge frames. These would be CAN data frames with acknowledge information.
Was there another option?
I think that the other option was to make the ACK bit recessive. Each receiving node on the bus sets ACK recessive when it receives the data frame, and doesn’t detect errors. Recessive ACK acts as wired AND. The sending node sees the recessive ACK and concludes that its message have been sent successfully and every node on the bus had received it. If one node detects an error, then it drives the ACK bit dominant. The sender sees the dominant bit, and re-transmits, or takes other measures.
2 answers
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.
0 comment threads
In addition to what Lundin said, making ACK dominant means that something out there is actively responding, and that response is affirmative. If ACK were recessive, then the transmitting node being totally cut off from everything else would appear like no error.
Put another way, without an active affirmative response, you can't tell the difference between "everyone is happy with this frame", and "the system is so broken that nobody saw the frame".
0 comment threads
0 comment threads