An ACK (acknowledge) is a control signal or message sent by a receiver to confirm that data has been successfully received. It is a fundamental handshaking primitive used across a wide range of serial protocols, bus standards, and higher-level communication frameworks.
In practice
At the hardware protocol level, ACK appears most visibly in I2C, where the receiving device pulls SDA low during the ninth clock pulse to acknowledge each transferred byte. A missing ACK (NACK) on I2C can indicate an absent device, an incorrect address, a receiver that is busy or out of buffer space, or other conditions; the transmitter generally cannot determine the exact cause from bus behavior alone. Debugging I2C ACK failures with an oscilloscope or logic analyzer is one of the most common low-level embedded debugging tasks.
In CAN, the ACK slot is a single recessive bit in every data frame. Any node that successfully receives the frame overwrites that bit with a dominant level, confirming reception to the transmitter. Because any node on the bus can provide the ACK, a lone node transmitting to an empty bus will flag an ACK error on every frame.
At the software and protocol framing level, ACK takes the form of an explicit response packet or byte. UART-based protocols, SPI application layers, Modbus, and many proprietary embedded protocols use software ACK bytes (often 0x06 in ASCII-aware systems, or a protocol-defined code) to tell the sender that a command or packet was accepted. In these cases the ACK is an application- or protocol-layer convention carried over the underlying transport, not a feature of the transport itself. The article "Help, My Serial Data Has Been Framed: How To Handle Packets When All You Have Are Streams" discusses the broader context of packet framing in which software ACK/NACK handling fits.
A common pitfall is conflating delivery acknowledgment with processing acknowledgment. A hardware or link-layer ACK confirms reception or acceptance according to that protocol's criteria; it says nothing about whether the application successfully acted on the data. Robust embedded protocols typically define a separate application-level ACK or status response to cover this distinction, and must also handle the case where an ACK is lost in transit, which can cause the sender to retransmit an already-processed command.
Frequently asked
What is the difference between an ACK and a NACK?
An ACK signals successful reception or acceptance; a NACK (negative acknowledge) signals the opposite. In
I2C, ACK is SDA pulled low and NACK is SDA left high during the acknowledge clock pulse. In software protocols, NACK is often a distinct response code indicating an error, an unsupported command, or a busy state.
On I2C, who is responsible for sending the ACK?
The receiver of each byte sends the ACK. During data transfers initiated by a master write, the slave ACKs each byte. During a master read, the master ACKs each byte it wants to continue receiving, and sends a NACK on the final byte to signal the end of the read before issuing a STOP condition.
Why does my CAN node report ACK errors when no other node is connected?
In normal operation,
CAN requires at least one other node on the bus to provide the ACK. A transmitting node samples the ACK slot and, if it reads back recessive (no one pulled it dominant), it raises an ACK error. This is expected behavior when a node is isolated. For single-node testing, some CAN controllers offer a loopback or silent mode that suppresses this check.
Is a software ACK byte the same as a hardware ACK signal?
No. A hardware ACK is a protocol-defined electrical event at the link layer (such as the
I2C ninth-clock-pulse mechanism or the
CAN ACK slot). A software ACK is an application- or protocol-defined response message transmitted over any transport. They operate at different layers and serve different purposes; both can be present in the same system.
How should I handle a lost ACK in a request-response embedded protocol?
Implement a timeout on the sender side: if no ACK is received within a defined window, retransmit the request up to a maximum retry count, then report a communication error. To avoid processing a command twice when the ACK was lost but the command was received, consider adding sequence numbers or idempotency checks in the protocol design.
Differentiators vs similar concepts
ACK is sometimes confused with flow control mechanisms such as RTS/CTS. Flow control signals govern whether a sender is permitted to transmit; ACK confirms that a specific transmission was received. They can coexist in the same protocol and address different problems. ACK is also distinct from a
checksum or
CRC: a CRC detects errors in a frame, while an ACK is the receiver's explicit confirmation back to the sender that the frame arrived (optionally, without errors). The two are complementary and are frequently used together.
