In one Phyllo, we have two ESP32. Let’s call them main_esp and bottom_esp to match main_pcb and bottom_pcb. As far as WiFi communication is concerned, there are three types of possible data flows:
- main_esp ↔ client (typically a computer, for shell connection on the main_stm)
- main_esp ↔ main_esp (to play shared animations)
- main_esp ↔ bottom_esp (the two ESP32 from the same Phyllo to provide target rotation speed or maybe also turn off main_pcb)
For each flow, there must be a protocol to discover the IP addresses. One solution is to broadcast a request for a specific Phyllo IP address. This solution is especially useful for the shell client. However, this system requires to already know the ID of the Phyllos one is trying to connect to. Another possibility is to ask for the address of all the Phyllos in one fell swoop. This solution still needs some test to check whether this increases the risk of packet loss. To mitigate this risk, the last possibility I came up with is to reverse the situation and have all the Phyllos advertise their IP address regularly. This way the traffic will be more evenly distributed in time. Moreover, this last solution enables to passively update the table of detected Phyllos as well as, by setting a timeout, passively detect the disappearance of a Phyllo. If you have any experience in the area, we welcome any advice.
Another important background task is the detection of the Phyllos’ relative positions through IR detection. Though it uses IR detection, the link between this detection and the ID of a Phyllo is made through WiFi synchronization thanks to setting a time reference.
The last important background task is the time reference. The bottom_esp are in charge of providing this service continuously: regularly, and numbered top is broadcasted. The clients, the main_esp, can then synchronize on these top, either by resetting their clock or launching tasks on this top.
Then each of these links has a specific purpose:
To sum it up, a main_esp needs to run continuously:
- one UDP server to store and manage advertised IP addresses
- one UDP server to negotiate animations
- one UDP server to wait for IR advertising
- one UDP server to listen to time references
- one TCP server to accept shell connections.
A bottom_esp needs to run continuously:
- One UDP server to wait for speed commands
- One UDP server to pay attention to time reference advertisement.
At first glance it might seem like a lot of servers to run simultaneously. However, the port system is made exactly so that the socket API system can efficiently sort the packet. So we should use this low level sorting as much as possible.