Software ACKs casue excess traffic. #1

New issue

Closed

opened 2026-05-24 11:20:03 +03:00 by splatink · 2 comments

splatink commented

2026-05-24 11:20:03 +03:00

Owner

By sniffing traffic with wireshark we can see the protocol and hardware itself sends a single ACK packet back any time it receives a message.

By default, this ACK packet is completely ignored in software, making ESPNOW connectionless (fire-and-forget). By using ACK in software, I have implemented a way to not only retransmit on failure, but also get status of remote commands.

This casues a double ACK.

For example the command /status means

packet for the command
hardware ack back
software ack back
hardware ack
command reply (0xEA) back
hardware ack
software ack (ok) back
hardware ack

Very heavy traffic for a single command. Not only is the command itself already sending an ACK back in hardware, but any software ACKs cause even more hardware ACKs.

Instead, write a wrapper function for transmitting any type of message (text, commands), that fires a packet, waits for a hardware ACK, if not, re-transmits.

For identifying what the ACK was for (and printing MSG OK, MSG FAIL, CHAN CH OK etc), just print it out locally when you get the command reply (0xEA, 0xEB etc). If you sent a message, print out the real ACK instead.

By sniffing traffic with wireshark we can see the protocol and hardware itself sends a single ACK packet back any time it receives a message. By default, this ACK packet is completely ignored in software, making ESPNOW connectionless (fire-and-forget). By using ACK in software, I have implemented a way to not only retransmit on failure, but also get status of remote commands. This casues a double ACK. For example the command /status means - packet for the command - hardware ack back - software ack back - hardware ack - command reply (0xEA) back - hardware ack - software ack (ok) back - hardware ack Very heavy traffic for a single command. Not only is the command itself already sending an ACK back in hardware, but any software ACKs cause even more hardware ACKs. Instead, write a wrapper function for transmitting any type of message (text, commands), that fires a packet, waits for a hardware ACK, if not, re-transmits. For identifying _what_ the ACK was for (and printing MSG OK, MSG FAIL, CHAN CH OK etc), just print it out locally when you get the command reply (0xEA, 0xEB etc). If you sent a message, print out the real ACK instead.

splatink added the

bug

enhancement

labels

2026-05-24 11:20:03 +03:00

splatink self-assigned this

2026-05-24 11:20:03 +03:00

splatink started working

2026-05-24 11:38:36 +03:00

splatink stopped working

2026-05-24 12:03:39 +03:00

25 minutes 3 seconds