Hi Foxabilo,
Thanks for the extra details. If you're using ESP32-WROOM modules then this is enough information to go on, I wanted to clarify if any of the RF circuit was custom or from a third party module vendor but it seems like this part is all from Espressif.
Looking at the TCP/IP packet capture, it does look like ACKs from the ESP32 to the other side are being delayed or lost somehow - the ACKs are coming several TCP packets late, and by the time the ESP32 sends the ACK then the available receive window size is always maximum again, implying that the ESP32 TCP/IP stack has processed the previously received bytes already but hadn't managed to "ACK" this yet. Whereas in the "good" capture the ACKs come more directly and you can see the available window size reduce as data is queued up in the TCP/IP stack for processing by the application layer.
An unusual thing is that there are no duplicate or redundant ACK packets in the "bad" capture, and they're consistently with the full window size (at last for the ones visible in the screen grab). When debugging RF problems I would expect a few retries and some random window size values, as WiFi has it's own ack/retry layer underneath the IP layer.
Suggest looking into three things, if possible:
- Check that no other variation in the ESP32 firmware may be causing unusual timing problems or resource starvation inside the firmware itself. The only thing I can think of is variation between SD cards, if you take the SD writes out of the equation (so the ESP32 just reads packet data and discards it), is there any difference? This is less likely, but worth ruling out. If the firmware is doing anything else concurrently with this transfer, try disabling that as well.
- Try to get a raw wifi "monitor mode" capture of the Wi-Fi data.
Some details can be found here. Essentially this gives a grab of all the raw Wi-Fi frames on the same channel as the network you're debugging. You won't be able to decode the Wi-Fi content due to WPA encryption (assuming Wi-Fi network is not open), you just see the metadata around each frame. However if there are RF problems then you'll see frame retransmits happening at the Wi-Fi layer, that are not visible at the TCP/IP layer.
- Try forcing a full RF calibration on each boot:
https://docs.espressif.com/projects/esp ... alibration