Micropython ESPNow Send Timeout

[mmliam]

The default timeout for an ESPNow Send is 25ms; it will return in 25ms either having received an Ack or not.

Is there a way to change the 25ms default timeout?

Thanks MM

[glenn20]

I just ran some tests between two ESP32 devices to double check:

t1 = time.ticks_ms(); e.send(peer, 'ping'); t2 = time.ticks_ms(); print(time.dicks_diff(t1, t2))   # -> 2 ms if peer has wifi turned on
t1 = time.ticks_ms(); e.send(peer, 'ping'); t2 = time.ticks_ms(); print(time.dicks_diff(t1, t2))   # -> 25 ms if peer has wifi turned off
t1 = time.ticks_ms(); e.send(peer, 'ping', False); t2 = time.ticks_ms(); print(time.dicks_diff(t1, t2))   # -> 1 ms if peer has wifi turned on
t1 = time.ticks_ms(); e.send(peer, 'ping', False); t2 = time.ticks_ms(); print(time.dicks_diff(t1, t2))   # -> 1 ms if peer has wifi turned off

ie. with build from micropython master (or nightly builds) send() only takes 25 ms if there is no Ack from the peer and sync is set to True. This 25ms appears to represent a timeout set in the espressif espnow software stack and I am unaware of how to change that. However, you can set sync to False and ESPNow.send() will return immediately without waiting for Ack packets. In that case, you will not know if the message was received.

[glenn20]

Oh - I should add that in earlier versions there was a bug, where send() would wait for at least 25ms whether an Ack was received or not, but that should be fixed in the micropython nightly builds, images built from micropython master and my precompiled v1.20.0 espnow images.

[glenn20]

Oh...and for the curious...the ESPNOW protocol automatically sends multiple re-transmissions if no Ack is received. You can see this effect at https://github.com/glenn20/upy-esp32-experiments/blob/main/ESPNowvsWifiEnergyUsage/README.md#send-status-via-esnow-from-_bootpy-commit-fc62686 (note the timescale on the 3rd image).

[mmliam]

Hi Glenn,
Thanks for the reply.
I had posted this on the ESP8266 forum, as I'm using an ESP8266 to communicate with an ESP32. This was one reply:

Though ChatGPT says it is possible by using esp_now_set_p2p_send_timeout()

This seems like the Arduino format; perhaps only Arduino supports setting the timeout.

I'm using build v1.191(583K) on the ESP8266, and firmware-esp32-GENERIC on the ESP32.
The timing tests I've done suggests the ESPNow send return is fixed at 25ms whether an Ack is received or not. I didn't think this was a bug, I thought this was to maintain time synchronization between all transmitting stations (which for me happens to be 5 ESP8266's), so that the transmission order is maintained. In the case of motion detectors,it would be a problem if the first station to detect was reported after the second station because of a difference in time delays. Granted we're only talking about milliseconds, but under the right circumstances it could happen.

My code does the following, an ESPNow send is issued; if the send returns without an ACK the routine tries twice again to re-transmit waiting one second in between retries. On the third Send failure it quits.
What I'm seeing is that the ESP32 receives the first transmission every time, but sometimes the most distant ESP8266 does a second send (I never see a third send). In other words it apparently didn't get the first ACK. I thought that perhaps the ESPNow timeout might be little too short, and it wasn't waiting long enough for the first ACK; therefore increasing the Send timeout might preclude the second transmission.

Do you have any thoughts on this?
Mike M.

[glenn20]

I don't believe increasing the timeout will address the issue, after all, radio waves travel 300km in one millisecond, so it won't be a propagation time issue. I think its more likely to be a wifi interference or signal strength issue. I don't know about esp_now_set_p2p_timeout(). I will look into it (google returns nothing), but I don't think that will help. Note that if the ESPNOW doesnt receive a response within a millisecond or so, it retransmits the message many times. It is all these retransmission and wait for response that takes 25ms (see the 3rd graph at https://github.com/glenn20/upy-esp32-experiments/blob/main/ESPNowvsWifiEnergyUsage/README.md ).

…

On Thu, 11 May 2023, 12:42 am mmliam, ***@***.***> wrote: Hi Glenn, Thanks for the reply. I had posted this on the ESP8266 forum, as I'm using an ESP8266 to communicate with an ESP32. This was one reply: Though ChatGPT says it is possible by using esp_now_set_p2p_send_timeout() This seems like the Arduino format; perhaps only Arduino supports setting the timeout. I'm using build v1.191(583K) on the ESP8266, and firmware-esp32-GENERIC on the ESP32. The timing tests I've done suggests the ESPNow send return is fixed at 25ms whether an Ack is received or not. I didn't think this was a bug, I thought this was to maintain time synchronization between all transmitting stations, which for me happens to be 5 ESP8266's. My code does the following, an ESPNow send is issued; if the send returns without an ACK the routine tries twice again to re-transmit waiting one second in between retries. On the third Send failure it quits. What I'm seeing is that the ESP32 receives the first transmission every time, but sometimes the most distant ESP8266 does a second send (I never see a third send). In other words it apparently didn't get the first ACK. I thought that perhaps that the ESPNow timeout might be little too short, and it wasn't waiting long enough for the first ACK; therefore increasing the Send timeout might preclude the second transmission. Do you have any thoughts on this? Mike M. — Reply to this email directly, view it on GitHub <#11454 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVEQR4P4I2AUAVKD2DC23DXFOSLZANCNFSM6AAAAAAX4BW6EQ> . You are receiving this because you commented.Message ID: ***@***.*** com>

[glenn20]

Oh - and one other thing to check on the esp8266 devices. Make sure you call sta.disconnect() after sta.active(True). If you have ever connected that device to a wifi AP in the past, it will automatically reconnect after being enabled and that enables power saving mode.

In the end, wifi signals are subject to interference (eg. I lose some packets on devices too close to my microwave ;-).

[mmliam]

Thanks for the reminder Glenn, just checked to be sure; I do a sta.disconnect() after sta.active(True).

BTW: I'm in the process of numbering my retransmissions to see if I'm doing the it, or ESPNow is doing it. Stay-tuned I'll let you know. Is there a way I can contact you directly?

[mmliam]

Glenn,
I re-programmed a remote-device, my Gateway and the code running on the main host PC to receive a count as to how many times a remote-device has to transmit a given message (3 max) before receiving an ACK. For the remote-device I used for testing it only needed to transmit once to receive an ACK. I'm not seeing any other spurious transmissions.
Glenn

I don't believe increasing the timeout will address the issue, after all,
radio waves travel 300km in one millisecond, so it won't be a propagation
time issue.

BTW: The timeout has nothing to do with propagation delay, it's the allowed time for the receiver to respond with an ACK after receiving a transmission. Apparently, Espressif saw the need to allow up to 25ms to respond, as the receiver maybe time-sharing between processes. That's why I thought if my receiver couldn't respond within the allotted 25ms time, because it was performing other tasks, increasing that timeout might be useful to test that possibility.

[glenn20]

Apparently, Espressif saw the need to allow up to 25ms to respond, as the receiver maybe time-sharing between processes. That's why I thought if my receiver couldn't respond within the allotted 25ms time, because it was performing other tasks, increasing that timeout might be useful to test that possibility.

The protocol expects a device will respond within a millisecond or so if the packet is received. If it doesn't get that response, it expects it was lost (mainly due to interference or wifi collisions) and retransmits the message up to 13 times over about 15ms. The 25ms window is for all those repeated transmit attempts and wait for response - not so much to give the device extra time to respond to the initial transmission. Like I say, if the message is recieved, send() returns within 2ms.

[mmliam]

I hear what you're saying, but that's not what I'm seeing. The transmissions from the remote device never fail to be received by the Gateway, The current programming in this remote-device tries twice to send per event and both are received by the Gateway; it's just that the remote-device is not receiving the ACK. If the remote-device were trying up to 13 times in 15ms after failing to receive an ACK, I would see those transmissions in the Gateway; I'm not. I only see the two transmissions from the remote-device separated by the one second programmed delay. BTW: The remote-device uses an ESP8266 (specifically an ESP-07 module), you did your testing with an ESP32, perhaps it's ESPNow Send may function differently.

As an update, I tried a high-gain antenna on the Gateway to increase the effective power of it's ACK transmission; that appears to be working. Now I'm only getting one transmission from the remote-device per event. The only potential problem is the way the high-gain antenna works. While it's still effectively an omnidirectional dipole, it achieves it's higher gain by flattening the toroidal pattern; it gains in the toroidal plane of the antenna, but sacrifices signal above and below the plane. Given where I plan to place additional remote devices, it hopefully won't be a problem.