This week’s assignment was to design, build, and connect wired or wireless nodes with network addresses and local input/output devices. In cooking terms, this meant building a kitchen where ingredients (data) could move cleanly between stations (devices).
My initial plan was elegant and minimal: a single board consisting of a XIAO ESP32-S3 connected to a TFT display. The entire board fit on one side and only required seven 0Ω resistors.
Unfortunately, I had to mill this board twice. On the first attempt, I unknowingly used a broken 1/32" PCB conservative end mill, which resulted in incomplete traces. Once remilled properly, I soldered the board and moved on to networking.
I successfully connected the ESP32-S3 to the shop WiFi. At this point, I had a true networked system:
The ESP32 printed its assigned IP address to the serial monitor. Entering that IP address into my phone’s browser allowed me to access the device’s UI.
This setup clearly demonstrated network fundamentals: IP addressing, client-server relationships, and stateless HTTP requests between nodes.
Despite the networking success, the TFT stubbornly displayed only a white screen. After extensive debugging, I realized the issue: I had assumed the TFT controller was an ST7735, but it was actually an ILI9163.
This incorrect assumption meant the display code was fundamentally incompatible. Rather than remilling yet another board and consuming another ESP32-S3, I decided to pivot.
I reused a PCB originally designed for my final project that had a faulty DFPlayer but a fully functional ESP32-S3 and MPU6050 accelerometer.
Because I had already solved the networking stack once, reconnecting this board to WiFi was straightforward.
This board successfully acted as a network node, hosting a webpage that streamed accelerometer data over HTTP. The ESP32 served dynamic content, and my phone consumed it as a client.
Despite early mistakes, the final system clearly demonstrated networked communication between devices.