All the results presented here have been obtained following this procedure (using the code mentioned in the previous Log) :

• Every 1ms, the ESP32 sends a packet to the computer with a payload of 127 bytes. This payload contains the time of emission.
• A C++ code running on the computer (with the highest priority) receives this packet, copies the time of emission in a new packet (with a payload of 127 bytes), and sends it back to the ESP32
• The ESP32 receives this response and measures the round trip time.

Effect of the data rate on round trip time and packet loss :

The figure 2 shows the round trip time and the number of packet loss depending on the data rate. Each point of the graph was obtained by averaging the values of 3 batches of 10,000 packets. These tests have been done both when the surrounding WiFi activity was 'very low' and 'normal'.

It seems that the data rate does not impact much the packet loss. A much more significant factor for the packet loss is the surrounding WiFi activity.

Moreover, as expected, the trend is that the higher is the data rate the shorter is the round trip. However, this relationship is not linear.

Further analysis on packet loss :

Since we choose to disable ACK to speed up the connection, we need to check that the packet loss is reasonable. However, the most important is that the loss is scattered. In fact, it would be very harmful in our robotic application to have big batches of packets being lost. It would mean that there is no feedback for 'long' periods of time.

The figure 4 shows that the size of the 'groups' of lost packets seems to follow a normal law centred on 0. The variance seems to be very low, so it is very rare (less than 0.1% in this example) to lose 3 or more packets in a row. Therefore the loss of packets is more acceptable.

Future improvements :

The next steps are :

• Try different Wireless Network Interface Cards on the computer to see how it impacts the performances
• Patch Linux on the computer to be real-time.