Increase bandwidth of Wifi communication

[matthieuvigne]

For the context, I want to stream sensor data from the Arduino, using it as a WiFi access point. I was surprised by the low throughput of the connection: sending a 20-bytes packet in a single WiFIClient.write command takes around 6ms...

Digging into the code, I think I found two bottlenecks - unrelated and that can be addressed separately:

The communication speed between ESP32 and the RA4M1

This serial link is hard-coded on both sides at 115200 baud. I couldn't see any reason why this can't be higher - in fact I did a working proof of concept at 1000000 baud, and could see no unwanted side effects in my application. Thus I'm thinking we could either:

• hard-code a higher value: if there is really no side effect, why would we want to lower this communication speed? This is likely a bit naive, but it's extremely simple to implement
• implement an AT command to change the baud rate at runtime: I'm thinking of the ESP32 always booting at 115200 baud, but a command like AT+UART (as it's done on bluetooth dongles such as the HC-05) could change this.

I can write either version of the code (both for the ESP32 and the RA4M) depending on what seems best

The task scheduling of the ESP32

The parsing of AT command is done in an FreeRTOS task using vTaskDelay(1);, thus forcing a 1ms delay between the parsing of successive commands. This introduces a fixed 2 to 3ms overhead when using WiFIClient.write (because you have to send two commands and wait for their reply).

Searching online, I found the following project which seems to address this issue: https://github.com/mickeyl/esp-microsleep My idea was to reduce this sleep from 1ms to 100us. This is my first time working with the ESP32, so I didn't manage to integrate it in the compile chain (I feel like this belongs more to the arduino-esp32 project than to this one). I can dig further to get that working, but I wanted to get an opinion first on whether this is the right way to go. Maybe this will mess up other things in the task scheduling or introduce unwanted side effects (like latency on the WiFi side because we have less time to process these events if we dedicate more time to the serial port parsing).

[andreagilardoni]

The reason why that delay is present is to allow the watchdog task to run, thus avoiding the esp32 being stuck. I think the best solution for you is to compile a custom firmware for uno-r4-wifi-usb-bridge with the highest possible baudrate that can be achieved without having any issues in the uart signal

[matthieuvigne]

Thanks for the explanation. Indeed I've realized that just increasing the baudrate to 921600 is enough for my need for now, so I didn't focus on this second point about task scheduling anymore.