ESPNow Acknowledge; broadcast vs peer-to-peer

[mmliam]

Currently using ESPnow in peer-to-peer, where a sender receives a message acknowledge from the receiver.

If a sender sends a broadcast to many receivers, do all receivers send acknowledges, or receivers do not acknowledge broadcast messages?

UPDATE: Seems I've found an answer to my question; broadcast messages are not acknowledged (which makes sense, as ACK transmissions from multiple receivers would collide):
https://www.instructables.com/ESPNow-a-Deeper-Look-Unicast-Vs-Broadcast-ACKs-Ret/

[glenn20]

Yes - as you have identified, broadcast messages are not acknowledged by the receiver. The send() always returns True.

As a consequence, broadcast messages are never re-transmitted. Unicast message will be retransmitted many times if no ack is received. This means that broadcast messages can be much less reliable in noisy environments.

[glenn20]

In fact, this video would suggest that retransmissions do occur with esp8266 as well: https://www.youtube.com/watch?v=Xmzk6v5qIjo.

[mmliam]

All I can say is the ESP8266 sends to an ESP32. I can monitor what the ESP32 receives in an IDE as I have it printout all received messages. The ESP32 receives all the transmissions from the ESP8266, but sometimes the ESP8266 does not get the ACK and transmits again (up to 2 more times). All retransmissions are separated by one second, as per my coding. If the ESP8266 were sending out retransmission bursts I would see that output to the IDE from the ESP32. The most transmissions the ESP32 receives from the the ESP8266 is the maximum of 3 per trigger event.

Also, in monitoring the ESP8266 sends I've found that the send return is a fixed 25ms, whether it returns true (ACK), or false (NACK). This would be consistent with ESPNow maintaining a deterministic synchronization between all senders.

Perhaps it's the version of micropython [v1.191(583K)] that I'm using. Frankly, I'm glad I can control the retransmissions, so I don't waste battery power (3 transmissions MAX). I wouldn't like it if ESPNow were automatically re-transmitting.

I noted in the video he was supposedly seeing ACK's during broadcast that he couldn't explain; I'm beginning to suspect WireShark. Also, the code he's using is Arduino (a C++ derivative), perhaps the ESPNow implementation is different than the micropython implementation for the ESP8266.

I was looking over the Espressif documentation for ESPNow, and so far have not found any discussion on automatic retransmissions. However, it does talk about the user coding a re-transmit procedure and assigning a sequence number in the message, so the receiver can filter out extra transmissions. This certainly doesn't sound like the ESPNow protocol does automatic retransmissions. Perhaps some implementation in a given language might include automatic retransmissions, but that would not be part of (or in my case desirable) ESPNow.

From the Espressif ESPNow documentation:

If receiving ack data timeouts, retransmit the ESP-NOW data. A sequence number can also be assigned to ESP-NOW data to drop the duplicate data.

BTW: I do sequence my transmissions, so I know exactly which transmissions from the ESP8266 were received by the ESP32 for a given event. I never get multiple receipts of a message with the same sequence number, as would be the case if the send routine was automatically re-transmitting.

[glenn20]

All retransmissions are separated by one second, as per my coding. If the ESP8266 were sending out retransmission bursts I would see that output to the IDE from the ESP32.

Ah, now I underdstand. The espnow retransmissions I am talking about are automatically performed deep down in the Espressif software stack and are a feature of the ESPNOW protocol. You will not see evidence of them in the IDE. So, whenever you get a failed send() it has actually tried to re-send the message multiple times within 25 milliseconds before send() returns.

Also, in monitoring the ESP8266 sends I've found that the send return is a fixed 25ms, whether it returns true (ACK), or false (NACK). This would be consistent with ESPNow maintaining a deterministic synchronization between all senders.

Have you tried this with a recent version of the espnow images? As I have mentioned previously, older versions were implemented so that there was an enforced busy-wait for at least 25ms. Newer versions return within a few ms if the send was successful on the first transmit.

Perhaps it's the version of micropython [v1.191(583K)] that I'm using. Frankly, I'm glad I can control the retransmissions, so I don't waste battery power (3 transmissions MAX). I wouldn't like it if ESPNow were automatically re-transmitting.

Sorry to tell you that I believe it is (confirmed on ESP32 and others have reported it for the ESP8266) - and we have no control over that. It is inbuilt to the ESPNow protocol.

Note that these retransmissions are completely transparent to the user and I don't believe it makes any difference to your usage.

I noted in the video he was supposedly seeing ACK's during broadcast that he couldn't explain; I'm beginning to suspect WireShark. Also, the code he's using is Arduino (a C++ derivative), perhaps the ESPNow implementation is different than the micropython implementation for the ESP8266.

See also https://hackaday.io/project/161896-linux-espnow/log/154698-how-esp-now-really-works for additional evidence for the esp8266.

I was looking over the Espressif documentation for ESPNow, and so far have not found any discussion on automatic retransmissions. However, it does talk about the user coding a re-transmit procedure and assigning a sequence number in the message, so the receiver can filter out extra transmissions.

This is to address the fact that despite the fact an ACK has been received from the recipient, the packet MAY have been dropped in the application layer (eg. on micropython if the internal rxbuffer buffer is full).

BTW: I do sequence my transmissions, so I know exactly which transmissions from the ESP8266 were received by the ESP32 for a given event. I never get multiple receipts of a message with the same sequence number, as would be the case if the send routine was automatically re-transmitting.

[glenn20]

Oh - and...

Perhaps it's the version of micropython [v1.191(583K)] that I'm using. Frankly, I'm glad I can control the retransmissions, so I don't waste battery power (3 transmissions MAX).

https://github.com/glenn20/upy-esp32-experiments/tree/main/ESPNowvsWifiEnergyUsage shows that a failed send() consumes an extra 11 microWatt-hours of energy over a successful send().

[mmliam]

Well now I understand why I'm not seeing the additional transmissions.

See also https://hackaday.io/project/161896-linux-espnow/log/154698-how-esp-now-really-works for additional evidence for the esp8266.

From the above:

First bad news: ESP-NOW continues to send the packet again and again for 20ms !

I hope their is a way to disable this resend behavior... Indeed, for a robotic control, we prefer to wait for the next up-to-date packet than getting an outdated one, and jamming the channel

I agree; I hope there is away to disable the re-sends.

In fact, this video would suggest that retransmissions do occur with esp8266 as well: https://www.youtube.com/watch?v=Xmzk6v5qIjo.

From the video:
11 re-transmissions per send x 11 uW = (0.121mw per send) x (how many sends per day) [in my case 50] = 6mw x 365 days = 2.2watts. How long is that battery going to last? For the battery I'm using only 10 months, was hoping for 2.5 years. Without the burst extraneous re-transmissions I'd get way more than 2.5 years.

For my application where the sender is located there is wifi noise that causes the sender to fail getting ACK's so it does a lot of my programmed re-sends.

However, this has been a most enlightening discussion. I'm still amazed I can find nothing from the Esspressif ESPNow documentation that speaks to this important issue of automatic re-transmissions. Perhaps others have noticed unexpected battery drain, so the turned to Wire-Shark. Looks like I need to update and start using my Wire-Shark - lol

[glenn20]

I agree; I hope there is away to disable the re-sends. There is not. From the video: 11 re-transmissions per send x 11 uW

It is 11uWh for all the 11 retransmissions and they are only sent if no ack to first message.

…

= 0.121mw per send X how many sends per day (in my case 50) = 6mw x 365 days = 2.2watts. How long is that battery going to last? For my application where the sender is located there is wifi noise that causes the sender to fail getting ACK's so it does a lot of re-sends. — Reply to this email directly, view it on GitHub <#11705 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVEQR35672I3KRONWEYYNTXJ4TLPANCNFSM6AAAAAAY3A6EOM> . You are receiving this because you commented.Message ID: ***@***.*** com>

[mmliam]

Yes. As I have mentioned several times in the past, a successful send on esp32 takes about 2ms. A failed send takes 25ms. Which is completely consistent with expectations.

That's interesting, I don't get any difference in the send return time (ACK, or NACK); it's always 25ms. This I consider necessary to maintain synchronization between all my remote units..

Again, as I have mentioned numerous times now, there was a busy loop in earlier versions of the code that meant it took at least 25ms to execute a send.

Sorry, I missed you very last comment: So you're saying this "busy loop" was keeping the send return time consistent; ACK or NACK? Why was it changed (removing the much desired determinism it provided), and in what version of micropython did the change occur?

BTW: Something I never mentioned before; when the ESP-07 makes a transmission the current draw spikes to about 300ma (actual transmission), drops to 70ma for a coded 5 sec delay, then goes into hibernation. This is consistent with the current draw reported by others with similar modules. I actually have a 470uF cap over the ESP-07 power, as recommended by some other users, to assist with the transmission current spikes.

[glenn20]

So you're saying this "busy loop" was keeping the send return time consistent; ACK or NACK? Why was it changed (removing the much desired determinism it provided), and in what version of micropython did the change occur?

After sending a message with sync==True (the default) the code waits till the espressif software stack flags that an ACK has been received or has timed out (timeout is ~25ms - though not documented). After sending the message, the code would go into a loop, check if the ack has been received then invoke mp_hal_delay_ms(BUSY_WAIT_MS) before checking again. Unfortunately, I had forgotten that BUSY_WAIT_MS is set to 25ms (as this was the same delay in other busy loops to ensure other tasks get an opportunity to execute while busy-waiting). I have changed that code, so that it will return as soon as the ack is received.

I really think that the great majority of users would prefer that send() returns as soon as the ack is received.

[mmliam]

I understand the reason you made the change, but if it were me I would have included an extra (optional) parameter in the send(). That parameter being boolean defaulted to FALSE. For legacy code there would be no difference; a 25ms return for an ACK, or NACK. Set the optional parameter TRUE would result in an immediate return on ACK.

Alternatively, there could have been two versions of send(); not unlike recv() & irecv()

Best of both possible worlds :-)

[glenn20]

I understand the reason you made the change, but if it were me I would have included an extra (optional) parameter in the send(). That parameter being boolean defaulted to FALSE. For legacy code there would be no difference; a 25ms return for an ACK, or NACK. Set the optional parameter TRUE would result in an immediate return on ACK.

Alternatively, there could have been two versions of send(); not unlike recv() & irecv()

Best of both possible worlds :-)

I understand why you would like that for your particular use case, but I reckon it would have zero chance of being accepted for merge in the PR (and I'd agree with that :-).

[mmliam]

I understand why you would like that for your particular use case

I do suspect I'm not the only one; now I don't want to upgrade beyond 1.19.1 for concern it would mess-up the synchronism of sensors. I would need to create my own "busy loop" on send() True.

I reckon it would have zero chance of being accepted for merge in the PR (and I'd agree with that :-).

Pity. I reckon if it were done in the beginning it would be painless; only an extra feature. As it's been said nothing ventured, nothing gained :-)

BTW: I've asked this earlier; in what version of micropython did you make the change to the send() return?

Also, glenn please I hope you understand, I'm not trying to be overly critical, or difficult; I really do appreciate your opinion, expert help, and professionalism!