Messages recieved but ignored due to CRC mismatch, when mixing ESP8266 and ESP32 devices about espnowfloodingmeshlibrary2

[314159-r]

Looking through my loggs, There is a difference in how the messages data part is "constructed" (after the header).
The ESP8266 is adding 4 bytes with zero value in the beginning, before the deviceName - Whereas the ESP32 don't...

ESP8266 node time sync request, picked up by a ESP32 (same as the first bloc in prev. post):

[19834.07h.33m.20s.145] REC:
[19834.07h.33m.20s.145]            01 01 01 03 7B 06 07 05 01 4C 16 DC 00 00 00 00  ....{....L......
[19834.07h.33m.20s.148]            00 00 00 00  ....
                                                          ^   ^   ^   ^  
[19834.07h.33m.20s.149]                    Length: 20
...
[19834.07h.33m.20s.156] #CRC: 29879 1659
[19834.07h.33m.20s.158] 
[19834.07h.33m.20s.158]            01 01 01 03 7B 06 07 05 01 4C 16 DC 00 00 00 00  ....{....L......
[19834.07h.33m.20s.162]            00 00 00 00 54 65 73 74 31 00 00 00 00 00 00 00  ....Test1.......
...

The deviceName is truncated from the "REC:" output, but can be seen in the CRC dump (Test1).

---

ESP32 node time sync request, picked up by a ESP8266 (node):

[19834.15h.31m.32s.798] REC:
[19834.15h.31m.32s.798]            01 01 01 03 04 44 07 05 01 05 F8 85 4D 31 25 66  .....D......M1%f
[19834.15h.31m.32s.799]            54 65 73 74 32 00 83 4B  Test2..K
[19834.15h.31m.32s.799]                    Length: 24
...
[19834.15h.31m.32s.801] #CRC: 21668 17412
[19834.15h.31m.32s.801] 0x1,0x1,0x1,0x3,0x4,
[19834.15h.31m.32s.801] 
[19834.15h.31m.32s.801]            01 01 01 03 04 44 07 05 01 05 F8 85 4D 31 25 66  .....D......M1%f
[19834.15h.31m.32s.802]            54 65 73 74 32 00 83 4B 69 5B 37 2F B8 67 78 68  Test2..Ki[7/.gxh
...

... and simultaneously by another ESP32 (master):

[19834.15h.31m.32s.804] REC:
[19834.15h.31m.32s.806]            01 01 01 03 04 44 07 05 01 05 F8 85 4D 31 25 66  .....D......M1%f
[19834.15h.31m.32s.810]            54 65 73 74  Test
[19834.15h.31m.32s.810]                    Length: 20

(The later is accepted as valid (ESP32 to ESP32), so no CRC error output )

Published mqtt messages look the same.
It seems reasonable that this cause the CRC mismatch.

---

I tried my best to dig through the code of EspNowFloodingMesh.cpp, without any slightest hints to why the two ESP-types do like this.
But this code level is way over my head...

[leodesigner]

I have slave esp32 nodes and they work fine with esp8266 master, need to take a look closer why is this happening.

[314159-r]

Interesting... I had to take a new dive into the subject.
Now I know what is happening. But I wish I could understand why...

The problem is what I mentioned in my previous post: The 4 extra zero-value bytes, that starts the "data" part of the message.

Somehow the the size of the struct header gets corrupt
(inside struct mesh_secred_part, inside struct meshFrame)
from: EspNowFloodingMesh.cpp:

struct header {
  uint8_t msgId;
  uint8_t length;
  uint32_t p1;
  time_t time;
};

The size of the header is supposed to be 10 bytes (1+1+4+4 bytes), but in all my ESP8266 devices, master o node, it gets the size of 14 bytes.

Hence, 4 extra bytes gets inserted before the "data" content, as can be seen in my previous post. This works fine between my ESP8266 devices. But all my ESP32 devices gets the correct size of the header (10 bytes), and as the CRC-calculation takes the header size into account, I get the CRC mismatch error when mixing ESPs.

I have verified that it is the actual size of the header that is the problem with some extra debugg printing, both while sending and receiving, inside the functions: msg_recv_cb(), and sendMsgId() (I have log files):

Serial.printf("sizeof(m.encrypted.header): %d\n", sizeof(m.encrypted.header));

(Just activating #DEBUG_PRINTS in EspNowFloodingMesh.h should be enough to se the log outputs as in my previous post.)

Now to the big question - How can the size get wrong..? and why only with ESP8266..?

If I declare a struct to be 10 bytes, and gets 14, I don't know where to look..?
If this don't affect you, I tend to suspect my build environment (Ubuntu, VS Code/PlatformIO, both installed this spring).

[314159-r]

I should perhaps mention that I'm currently experimenting with:

• 2pc of ESP8266 D1 mini, one master and one slave
• 1 ESP32 WROOM as master
• 1 ESP32-C3 as slave
• 1 ESP32-S2 as slave

I kind of opted for a ESP32 master, expecting higher capacity and speed. But either way, being able to use slaves of both types is essential.

[leodesigner]

My environment is a bit different:
MacOS (Intel) and VSCode + PlatformIO
The structure size might be related to compiler options.
(#pragma)

[zst123]

I faced the same issue with ESP32S3 master, and ESP8266 slave. The mismatch in size is because time_t is previously 32-bit but updated to 64-bit in newer versions of esp-idf v5.0 onwards. I am using Arduino IDE, so the updated esp-idf may have not been propagated consistently to all board files.

See espressif/esp-idf#584

A workaround is to modify EspNowFloodingMesh.cpp and change the time to uint64_t type.

struct header {
  uint8_t msgId;
  uint8_t length;
  uint32_t p1;
  uint64_t time;
};

After applying this fix, all my ESP devices communicate with each other properly

[314159-r]

Good find!

It suddenly appears so obvious when you point at it...