espnow and message len > 250 #18490

jbgagnon · 2025-11-28T09:51:19Z

jbgagnon
Nov 28, 2025

it seems possible in mp v1.26.1 to send message over 250 bytes with espnow and receive them (perhaps with espnow v2) but it may create bug in receive.
Must we change the mp code to protect from this bug or enhance to support espnow v2 ?

server code

import network
from espnow import ESPNow

def en_irq(en):
    try:
        mac, msg = en.irecv(0)  # don't wait
        print('msg', len(msg), mac)
    except Exception as ex:
        print('ex', ex)
        # need reseting for continue working
        en.active(False)
        en.active(True)
        
nif=network.WLAN(network.AP_IF)
nif.active(True)
en=ESPNow()
en.active(True)
en.irq(en_irq)

client code

from time import sleep_ms
import network
from espnow import ESPNow

nif=network.WLAN(network.AP_IF)
nif.active(True)
en=ESPNow()
en.active(True)
dst=b'\xFF' * 6
try: en.add_peer(dst, ifidx=0)
except: pass

for i in range(245,256):
    msg=b'*' * i
    print('send', i, len(msg))
    en.send(dst, msg, True)
    sleep_ms(200)

server results

msg 245 b'\x18\x8b\x0e*\x94\xb4'
msg 246 b'\x18\x8b\x0e*\x94\xb4'
msg 247 b'\x18\x8b\x0e*\x94\xb4'
msg 248 b'\x18\x8b\x0e*\x94\xb4'
msg 249 b'\x18\x8b\x0e*\x94\xb4'
msg 250 b'\x18\x8b\x0e*\x94\xb4'
ex ESPNow.recv(): buffer error
ex ESPNow.recv(): buffer error
ex ESPNow.recv(): buffer error
ex ESPNow.recv(): buffer error
ex ESPNow.recv(): buffer error

Answered by shariltumin

Nov 28, 2025

The solution seems quite simple. It just requires some simple modifications to the modespnow.c file.

$ diff modespnow.c modespnow.c-ORIG
75c75
<     uint16_t msg_len;           // Length of the message
---
>     uint8_t msg_len;            // Length of the message
90c90
<     (sizeof(espnow_pkt_t) + ESP_NOW_MAX_DATA_LEN_V2));
---
>     (sizeof(espnow_pkt_t) + ESP_NOW_MAX_DATA_LEN));
427c427
<     uint8_t *msg_buf = _get_bytes_len_w(msg, ESP_NOW_MAX_DATA_LEN_V2);
---
>     uint8_t *msg_buf = _get_bytes_len_w(msg, ESP_NOW_MAX_DATA_LEN);
438c438
<         || msg_len > ESP_NOW_MAX_DATA_LEN_V2
---
>         || msg_len > ESP_NOW_MAX_DATA_LEN
802c802
<     { MP_ROM_QSTR(MP_QSTR_MAX_DATA_LEN), MP…

View full answer

shariltumin · 2025-11-28T17:19:34Z

shariltumin
Nov 28, 2025

The solution seems quite simple. It just requires some simple modifications to the modespnow.c file.

$ diff modespnow.c modespnow.c-ORIG
75c75
<     uint16_t msg_len;           // Length of the message
---
>     uint8_t msg_len;            // Length of the message
90c90
<     (sizeof(espnow_pkt_t) + ESP_NOW_MAX_DATA_LEN_V2));
---
>     (sizeof(espnow_pkt_t) + ESP_NOW_MAX_DATA_LEN));
427c427
<     uint8_t *msg_buf = _get_bytes_len_w(msg, ESP_NOW_MAX_DATA_LEN_V2);
---
>     uint8_t *msg_buf = _get_bytes_len_w(msg, ESP_NOW_MAX_DATA_LEN);
438c438
<         || msg_len > ESP_NOW_MAX_DATA_LEN_V2
---
>         || msg_len > ESP_NOW_MAX_DATA_LEN
802c802
<     { MP_ROM_QSTR(MP_QSTR_MAX_DATA_LEN), MP_ROM_INT(ESP_NOW_MAX_DATA_LEN_V2)},
---
>     { MP_ROM_QSTR(MP_QSTR_MAX_DATA_LEN), MP_ROM_INT(ESP_NOW_MAX_DATA_LEN)},

The receiver is an ESP32-wroom that was compiled with ESP-IDF-5.5.1 and the modifies modespnow.c file.

Results from the server (receiver):

>>> msg 1464 b'\xf4\x12\xfa\xce\xd9\x9c'
msg 1465 b'\xf4\x12\xfa\xce\xd9\x9c'
msg 1466 b'\xf4\x12\xfa\xce\xd9\x9c'
msg 1467 b'\xf4\x12\xfa\xce\xd9\x9c'
msg 1468 b'\xf4\x12\xfa\xce\xd9\x9c'
msg 1469 b'\xf4\x12\xfa\xce\xd9\x9c'
msg 1470 b'\xf4\x12\xfa\xce\xd9\x9c'

The sender is an ESP32-wroom that runs MicroPython firmware with the original modespnow.c file.

I modified the client (sender) script:

...
for i in range(1464,1474):
    msg=b'*' * i
    print('send', i, len(msg))
    en.send(dst, msg, True)
    sleep_ms(600)

Results from the sender:

send 1464 1464
send 1465 1465
send 1466 1466
send 1467 1467
send 1468 1468
send 1469 1469
send 1470 1470
send 1471 1471
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "test_cln.py", line 26, in <module>
OSError: (-12390, 'ESP_ERR_ESPNOW_ARG')

The check is now with the sender, which seems reasonable to me, rather than with the recipient.

2 replies

jbgagnon Dec 1, 2025
Author

Great, that's perfect, thank you very much Shariltumin.

Now espnow performs just as well as udp (1470B > 1460B). Sensor data can be passed from espnow to udp via a relay without changing the format or requiring complex compression to fit within the 250B limit.

Should we submit a pool request to integrate this change into the next version?

shariltumin Dec 1, 2025

Be my guest, but it is probably best that Glenn be part of the loop to see what can be done. Some policy choices probably need to be made, like the size of the buffer and other things that I did not see from the code.

projectgus · 2025-12-03T03:59:05Z

projectgus
Dec 3, 2025
Collaborator

There's an existing PR for this at #16737

If you're interested to test or contribute then suggest focusing attention there.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MicroPython

espnow and message len > 250 #18490

Uh oh!

{{title}}

Uh oh!

Replies: 2 comments 2 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

MicroPython

espnow and message len > 250 #18490

Uh oh!

jbgagnon Nov 28, 2025

server code

client code

server results

Replies: 2 comments · 2 replies

Uh oh!

shariltumin Nov 28, 2025

Uh oh!

jbgagnon Dec 1, 2025 Author

Uh oh!

shariltumin Dec 1, 2025

Uh oh!

projectgus Dec 3, 2025 Collaborator

jbgagnon
Nov 28, 2025

Replies: 2 comments 2 replies

shariltumin
Nov 28, 2025

jbgagnon Dec 1, 2025
Author

projectgus
Dec 3, 2025
Collaborator