Current draw when transmitting ESPNOW

[OllyLi]

I am observing some interesting behavior.
I have one ESP32S3 module being TX and one being RX, communicating with ESPNOW.
The TX sends data every 20ms, and here are what I observed:
1. If the TX sends data in broadcast, the current draw of the whole module is around 100mA~150mA (5V), whether if the RX is ON or not.
2. If TX sends data in unicast, and RX is ON to receive it, the TX draws similar 100mA~150mA
3. If TX sends data in unicast, and RX is OFF (the TX send_cb would get status as FAILED), the TX draws ~300mA and the whole thing gets so hot and the module would randomly reboot itself maybe because of overheating...

I can observe this between from #2 to #3 by turning on/off the RX without touching the TX.

Lower the transmitting frequency does help. If the TX sends data every 200ms instead of 20ms, the average current draw would not be that dramatic.
I am sure I can work with lower data frequency but want to check if this is normal

Thanks!

[boarchuz]

Probably related (WiFi driver retrying many times): https://github.com/espressif/esp-idf/issues/9383

And that indicates that no changes are planned so you might consider exclusively using broadcasts instead, with your own acknowledgement implementation on top of that if necessary.

[MicroController]

The TX sends data every 20ms, and here are what I observed:
...
3. If TX sends data in unicast, and RX is OFF (the TX send_cb would get status as FAILED), the TX draws ~300mA and the whole thing gets so hot and the module would randomly reboot itself maybe because of overheating...

Note that with ESPNOW, especially unicast, you should wait for the TX callback, signalling the end of the transmission attempt, before trying to send the next packet. This is because ESPNOW does the sending asynchronously, and unicasts are automatically retried for some time if not acknowledged by the receiver.

Not sure that overheating would be the cause for the reboot though. Might be some resource shortage or a watchdog triggering if you 'overload' the WiFi stack with ESPNOW calls.

[OllyLi]

Probably related (WiFi driver retrying many times): https://github.com/espressif/esp-idf/issues/9383

And that indicates that no changes are planned so you might consider exclusively using broadcasts instead, with your own acknowledgement implementation on top of that if necessary.

That maybe the case.
As of the broadcast, the frame drop is too high for me. I guess because of missing the retry mentioned above?

[OllyLi]

The TX sends data every 20ms, and here are what I observed:
...
3. If TX sends data in unicast, and RX is OFF (the TX send_cb would get status as FAILED), the TX draws ~300mA and the whole thing gets so hot and the module would randomly reboot itself maybe because of overheating...

Note that with ESPNOW, especially unicast, you should wait for the TX callback, signalling the end of the transmission attempt, before trying to send the next packet. This is because ESPNOW does the sending asynchronously, and unicasts are automatically retried for some time if not acknowledged by the receiver.

Not sure that overheating would be the cause for the reboot though. Might be some resource shortage or a watchdog triggering if you 'overload' the WiFi stack with ESPNOW calls.

Thanks, I will take a look to see if my code was sending data before the callback.