leodesigner
Messages recieved but ignored due to CRC mismatch, when mixing ESP8266 and ESP32 devices
I'm trying to implement the esp_mesh_pir_sensor node, in combination with the USB master esp_mesh_gw_node . (both slightly modified, mostly cosmetic...)
It works when both devices are of the same ESP category, ESP8266 or ESP32.
But when mixing a ESP8266 with a ESP32, regardless of which type is master or node, I get a CRC error when receiving (with DEBUG_PRINTS activated), and all messages gets ignored - in both directions, on both devices.
The actual messages are received and decrypted, seemingly OK. But somehow either the CRC calculation, or the content for the calculation, is handled differently by the two ESP types. As a "copy-paste C++ amateur", I'd really need some help tracking this issue.
Here are some serial log outputs with DEBUG_PRINTS activated. (Timestamps are from my terminal app)
ESP32 master - Receiving message from ESP8266 node:
[19834.07h.33m.20s.134] Recv from: 2c:3a:e8:32:90:b6
[19834.07h.33m.20s.134] REC[RAW]:
[19834.07h.33m.20s.135] 01 01 01 03 7B 06 D1 81 83 E3 01 8C F0 5C 21 2A ....{........\!*
[19834.07h.33m.20s.138] 15 01 D3 E8 68 89 B0 1E 5F A0 48 B4 7D A2 80 02 ....h..._.H.}...
[19834.07h.33m.20s.142] 49 24 D6 82 2C BE I$..,.
[19834.07h.33m.20s.144] Length: 38
[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.151] REC HEADER:
[19834.07h.33m.20s.152] 01 01 01 03 7B 06 07 05 01 4C 16 DC 00 00 00 ....{....L.....
[19834.07h.33m.20s.155] Length: 15
[19834.07h.33m.20s.156] #CRC: 29879 1659
[19834.07h.33m.20s.156] 0x1,0x1,0x1,0x3,0x7B,
[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.......
[19834.07h.33m.20s.164] 00 00 00 00 00 01 92 AF BB B6 BF 12 AC 5B 05 D6 .............[..
[19834.07h.33m.20s.167] 74 01 C8 EA BE 08 61 6C 75 65 20 7B 22 42 61 74 t.....alue.{"Bat
[19834.07h.33m.20s.171] 74 65 72 79 56 6F 6C 74 22 3A 33 2E 36 33 7D 0A teryVolt":3.63}.
[19834.07h.33m.20s.174] 00 00 00 00 00 01 14 36 68 61 A6 64 7D 34 CF AF .......6ha.d}4..
[19834.07h.33m.20s.178] 8E 28 BA 44 DB C0 3A 31 33 34 30 2C 22 43 6F 75 .(.D..:1340,"Cou
[19834.07h.33m.20s.181] 6E 74 65 72 22 3A 39 31 35 2C 22 54 69 6D 65 42 nter":915,"TimeB
[19834.07h.33m.20s.184] 6F 6F 74 22 3A 34 32 7D 0A 00 00 00 00 00 00 00 oot":42}........
[19834.07h.33m.20s.188] 00 00 00 00 00 00 0C 17 00 69 95 09 4F B0 6B F6 .........i..O.k.
[19834.07h.33m.20s.191] B0 6E AE 5F 8F 38 FB 3F 00 00 00 00 00 00 00 00 .n._.8.?........
[19834.07h.33m.20s.195] 00 00 00 00 48 49 08 40 F0 BF 00 40 30 0A 06 00 ....HI.@...@0...
[19834.07h.33m.20s.198] D4 FF 08 80 F0 B1 FC 3F .......?
[19834.07h.33m.20s.199] Length: 200
[19834.07h.33m.20s.201]
[19834.07h.33m.20s.202]
[19834.07h.33m.20s.202] 01 01 01 03 7B 06 D1 81 83 E3 01 8C F0 5C 21 2A ....{........\!*
[19834.07h.33m.20s.205] 15 01 D3 E8 68 89 B0 1E 5F A0 48 B4 7D A2 80 02 ....h..._.H.}...
[19834.07h.33m.20s.208] 49 24 D6 82 2C BE 00 00 00 F7 2C 01 00 EC 96 FC I$..,.....,.....
[19834.07h.33m.20s.212] 3F EC 96 FC 3F F7 05 B3 99 C5 C0 E0 5E FD C4 53 ?...?.......^..S
[19834.07h.33m.20s.214] 7B DA E4 75 C2 06 F6 BC AA E5 B8 3D 81 5A C3 80 {..u.......=.Z..
[19834.07h.33m.20s.219] 9F FA 31 57 4A 5F 00 00 00 00 00 00 00 00 00 00 ..1WJ_..........
[19834.07h.33m.20s.222] 00 4C D3 FC 3F E4 10 0C C0 90 D3 FC 3F 00 00 00 .L..?.......?...
[19834.07h.33m.20s.224] 00 12 64 00 00 07 00 00 00 00 00 00 00 00 7F D2 ..d.............
[19834.07h.33m.20s.228] 06 00 00 04 01 80 00 00 00 74 D1 23 F0 D4 03 FC .........t.#....
[19834.07h.33m.20s.231] 3F 1C AA 4F 63 AB 00 00 00 A0 00 01 BE CB 27 5B ?..Oc.........'[
[19834.07h.33m.20s.235] FA 14 FB 05 4C 00 00 40 76 C1 10 0C 00 D0 00 00 ....L..@v.......
[19834.07h.33m.20s.238] 00 FF FF FF FF D0 00 00 00 FF FF FF FF FF FF 24 ...............$
[19834.07h.33m.20s.241] 6F 28 A5 D3 E0 FF FF FF o(......
[19834.07h.33m.20s.244] Length: 200
Corresponding output from the ESP8266 node (first time-synk request after boot):
[19834.07h.33m.20s.127] Annonce + Request instant time sync from mesh.
[19834.07h.33m.20s.128] Send0:
[19834.07h.33m.20s.128] 01 01 01 03 7B 06 07 05 01 4C 16 DC 00 00 00 00 ....{....L......
[19834.07h.33m.20s.129] 00 00 00 00 54 65 73 74 31 ....Test1
[19834.07h.33m.20s.129] Length: 25
[19834.07h.33m.20s.130] Send[RAW]:
[19834.07h.33m.20s.130] 01 01 01 03 7B 06 D1 81 83 E3 01 8C F0 5C 21 2A ....{........\!*
[19834.07h.33m.20s.131] 15 01 D3 E8 68 89 B0 1E 5F A0 48 B4 7D A2 80 02 ....h..._.H.}...
[19834.07h.33m.20s.131] 49 24 D6 82 2C BE I$..,.
[19834.07h.33m.20s.132] Length: 38
ESP8266 node - Receiving message from ESP32 master (the periodic time-sync):
[19834.07h.33m.21s.781] Recv from: 24:6f:28:a5:d3:e0
[19834.07h.33m.21s.781] REC[RAW]:
[19834.07h.33m.21s.782] 01 01 01 00 CE 99 0B 8D AD 2F E7 9F 64 14 50 36 ........./..d.P6
[19834.07h.33m.21s.782] DF D1 E3 2E 99 2E ......
[19834.07h.33m.21s.783] Length: 22
[19834.07h.33m.21s.783] REC:
[19834.07h.33m.21s.783] 01 01 01 00 CE 99 02 00 29 3D 8C 8D 3A C1 24 66 ........)=..:.$f
[19834.07h.33m.21s.784] 00 00 00 ...
[19834.07h.33m.21s.784] Length: 19
[19834.07h.33m.21s.785] REC HEADER:
[19834.07h.33m.21s.785] 01 01 01 00 CE 99 02 00 29 3D 8C 8D 3A C1 ........)=..:.
[19834.07h.33m.21s.785] Length: 14
[19834.07h.33m.21s.786] #CRC: 31778 39374
[19834.07h.33m.21s.786]
[19834.07h.33m.21s.786]
[19834.07h.33m.21s.786] 01 01 01 00 CE 99 02 00 29 3D 8C 8D 3A C1 24 66 ........)=..:.$f
[19834.07h.33m.21s.787] 00 00 00 00 00 00 7E B6 39 98 DA B8 29 9E 65 14 ........9...).e.
[19834.07h.33m.21s.788] EA 46 2C 72 36 24 FF FF FF FF FF FF FF FF FF FF .F,r6$..........
[19834.07h.33m.21s.789] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
[19834.07h.33m.21s.790] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
[19834.07h.33m.21s.790] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
[19834.07h.33m.21s.791] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
[19834.07h.33m.21s.794] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
[19834.07h.33m.21s.794] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
[19834.07h.33m.21s.794] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
[19834.07h.33m.21s.799] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
[19834.07h.33m.21s.799] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
[19834.07h.33m.21s.799] FF FF FF FF FF FF FF FF ........
[19834.07h.33m.21s.799] Length: 200
[19834.07h.33m.21s.799]
[19834.07h.33m.21s.799]
[19834.07h.33m.21s.799] 01 01 01 00 CE 99 0B 8D AD 2F E7 9F 64 14 50 36 ........./..d.P6
[19834.07h.33m.21s.799] DF D1 E3 2E 99 2E 00 00 00 00 00 00 00 00 00 00 ................
[19834.07h.33m.21s.799] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[19834.07h.33m.21s.800] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[19834.07h.33m.21s.800] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[19834.07h.33m.21s.801] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[19834.07h.33m.21s.802] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[19834.07h.33m.21s.803] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[19834.07h.33m.21s.804] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[19834.07h.33m.21s.804] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[19834.07h.33m.21s.805] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[19834.07h.33m.21s.806] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[19834.07h.33m.21s.807] 00 00 00 00 00 00 00 00 ........
[19834.07h.33m.21s.809] Length: 200
Corresponding output from the ESP32 master:
[19834.07h.33m.21s.767] Send time sync message!!
[19834.07h.33m.21s.767] Send0:
[19834.07h.33m.21s.769] 01 01 01 00 CE 99 02 00 29 3D 8C 8D 3A C1 24 66 ........)=..:.$f
[19834.07h.33m.21s.771] 00 00 00 00 ....
[19834.07h.33m.21s.773] Length: 20
[19834.07h.33m.21s.774] Send[RAW]:
[19834.07h.33m.21s.774] 01 01 01 00 CE 99 0B 8D AD 2F E7 9F 64 14 50 36 ........./..d.P6
[19834.07h.33m.21s.779] DF D1 E3 2E 99 2E ......
[19834.07h.33m.21s.785] Length: 22
I'm attaching the full log-files from both devices during a "one-shot" from booting of the node device, with initial time-sync request and publishing of a mqtt message, + one periodic time-sync from the master. (The node is configured to 3 retries for both time-sync request and publishing.) EspNowMesh GW32 - CRC-error from ESP8266 node Test1.txt EspNowMesh Test1 - CRC-error from ESP32 master.txt
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...
I have slave esp32 nodes and they work fine with esp8266 master, need to take a look closer why is this happening.
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).
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.
My environment is a bit different: MacOS (Intel) and VSCode + PlatformIO The structure size might be related to compiler options. (#pragma)
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 https://github.com/espressif/esp-idf/issues/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
