Wiznet makers

Summary

Teslamax’s KSP-Controller is a project for building a custom control panel for Kerbal Space Program. At its current stage, it is organized as an experimental platform centered on the Adafruit ESP32-S3 Reverse TFT Feather, combining UI, input devices, USB HID, and wired networking. In this setup, the WIZnet W5500 serves as an auxiliary network interface, designed to handle Ethernet initialization at boot, DHCP or static IP configuration, and mDNS exposure in the form of ksp-controller.local.

Image source: AI-generated

What the Project Does

Kerbal Space Program (KSP) is a spaceflight simulation game in which players design and control spacecraft, aircraft, and rovers to carry out missions such as orbit insertion, docking, landing, and exploration. It is not a simple arcade-style control scheme. Elements such as thrust, fuel consumption, mass changes, gravity wells, and orbital mechanics affect the entire gameplay experience, which means both pre-flight design and in-flight control require careful handling. Because of this, KSP often benefits from more than a standard gamepad, and a dedicated control panel with multiple switches, mode changes, status indicators, and auxiliary input devices is especially well suited to the game.

That is exactly the core purpose of this project. Rather than limiting gameplay to a single general-purpose input device, it extends KSP control into a separate embedded panel with a physical interface. According to the repository, the current experimental phase validates a TFT menu UI, an I2C NeoKey keypad, expandable USB HID support, and optional Ethernet connectivity on an ESP32-S3 Feather-class board. In other words, inputs come from buttons, keypads, and encoders, outputs go to the display and LED feedback, and networking is positioned as a secondary channel for diagnostics, configuration, and name-based access.

Image source: AI-generated

From an architectural perspective, this repository is closer to an experimental backplane for validating separated functional blocks than to a final finished product. The README states that the current platform is an ESP32-S3 Feather-based experimental stage, while the final build may move to a Teensy 4.1. In other words, the present structure is intended to test UI, input handling, storage, and networking as individual modules first, and then migrate them to a final platform with more GPIO and performance headroom if needed.

Where WIZnet Fits

The exact WIZnet part identified in this project is the W5500. The hardware documents and BOM specify the Adafruit Ethernet FeatherWing as a W5500-based board, and the top-level PlatformIO configuration includes -DUSE_ETHERNET, -DETHERNET_CS=10, and the WIZ_Ethernet_Library repository as a dependency. In the documentation, its role is not just “internet connectivity” in a generic sense, but the addition of an SPI-based wired networking block to the Feather stack.

This choice also makes clear sense for embedded experimentation. The W5500 uses a hardwired TCP/IP architecture and provides up to 80 MHz SPI, a 32 KB internal buffer, and 8 hardware sockets, making it easier to reduce the networking burden on the MCU side. In a project like this, where the ESP32-S3 is simultaneously being used to test the display, inputs, and USB functions, separating the network function into a dedicated chip helps keep the firmware structure simpler. Since the repository also anticipates a larger I/O configuration in the final design, treating networking as an independent block is beneficial for modularizing the overall architecture.

That said, based on what can currently be verified, it would not be accurate to claim that the W5500 has already been fully implemented as the real-time telemetry path for KSP. The README and development notes mention goals such as “Ethernet-based diagnostics,” “optional HTTP config,” and “HID + Ethernet telemetry for KSP mods,” but the firmware code that can actually be confirmed currently stops at Ethernet initialization and mDNS responder startup. At this stage, the W5500 is therefore more accurately described as an experimental wired networking layer than as a finished game-integration communication path.

Implementation Notes

Evidence of W5500 usage exists in this repository not only at the documentation level, but also in the actual build configuration and firmware code.

First, the top-level platformio.ini includes the following settings:

File path: platformio.ini
These settings show that the project explicitly defines the SPI chip select pin and includes the WIZnet Ethernet library in the build. In other words, the W5500 is not just an optional hardware part; it is a network device tied into the firmware through preprocessor macros and library dependencies.

Second, firmware/src/main.cpp and firmware/src/net_config.h show the actual initialization flow:

File path: firmware/src/main.cpp

The network configuration function also contains the following calls:

File path: firmware/src/net_config.h

This code indicates a boot sequence in which the system reads settings from the SD card, brings up Ethernet using either DHCP or a static IP configuration, and then registers an mDNS hostname. That matters because it shows the network layer in this project is designed not just for basic link-up, but for an operational flow that includes configuration-file-based boot, address assignment, and name-based access. For an experimental device such as a KSP controller, this approach is useful because it allows the device to be located and configured without relying solely on direct USB access.

Practical Tips / Pitfalls

If you plan to place the W5500 and the SD card on the same SPI bus, chip select conflicts should be resolved first. The hardware documentation uses GPIO10 as the default Ethernet CS and notes that it can be moved to GPIO9 if another FeatherWing causes a conflict.

Because this project reads SD card configuration files before initializing Ethernet, it is worth verifying the fallback behavior when config.json or mac.txt is missing. The current code falls back to a default MAC address and DHCP in that case.

Power should not be treated lightly. The hardware documentation notes that an external 3.3 V regulator may be required under heavier current consumption. When stacking TFT, NeoPixel, Ethernet, and SD in one build, power stability may become the first real issue.

Although this repository uses the ESP32-S3 as an experimental platform, GPIO count and performance headroom may become limiting factors as the panel grows in size. The documentation separately discusses the possibility of moving to a Teensy 4.1 in the final stage.

If you want to extend KSP integration over Ethernet, it is better to separate the currently implemented networking features from the future telemetry goals. What is confirmed now is Ethernet initialization and mDNS; the actual KSP telemetry loop appears only at the level of a conceptual sketch in the development notes.

From an EMI and wiring stability perspective, once USB, TFT, NeoPixel, and SPI Ethernet are placed in the same enclosure, it is better to move sooner rather than later from loose jumper-wire experimentation to shorter, fixed harnesses. The project currently assumes FeatherWing stacking and breadboard-style experimental assembly.

FAQ

Q1. Why is the WIZnet W5500 a good fit for this project?
A. The current structure experiments with TFT UI, I2C input, and USB HID expansion on the ESP32-S3. Under those conditions, it is simpler to offload networking into a dedicated hardwired TCP/IP chip like the W5500 rather than piling more network functionality onto the MCU’s internal software stack. The W5500 connects over SPI and provides 8 hardware sockets and a 32 KB internal buffer, making it easier to treat the networking layer as an independent block. The repository follows exactly that direction by including a W5500 FeatherWing and its dedicated library.

Q2. How does the W5500 connect to the platform in this project?
A. According to the documentation, the W5500 FeatherWing uses SPI, sharing the ESP32-S3 Feather’s MOSI, MISO, and SCK lines while using a dedicated CS pin. The proposed default CS is GPIO10, with GPIO9 available as an alternative if there is a conflict. In other words, the connection method is a shared SPI bus with a separate CS line, and that makes CS management essential when other SPI devices such as an SD card are present.

Q3. What exactly does the W5500 do in this project?
A. The verifiable role at this point is wired network initialization, IP configuration, and mDNS hostname advertisement. The firmware reads the network settings from the SD card, applies DHCP or static IP through setupEthernet(...), and exposes a hostname through EthernetBonjour.begin(...). At this stage, the W5500 is best understood as the network operations layer of the KSP control panel.

Q4. Can beginners follow this project?
A. It is somewhat difficult for complete beginners, because this is not a single-board example. It combines a TFT, keypad, SD card, Ethernet FeatherWing, configuration files, and a PlatformIO build environment. Even so, it is still a good structure for embedded experimentation. The best way to approach it is step by step: first confirm standalone ESP32-S3 boot and display output, then add the NeoKey, and then bring up the W5500 link and DHCP.

Q5. What is the difference between using W5500 Ethernet and Wi-Fi here?
A. Based on the repository documentation, the ESP32-S3 has built-in Wi-Fi and BLE, but the project also treats W5500-based wired Ethernet as an experimental option. Wired Ethernet offers more predictable IP acquisition and physical link state, which suits a panel-style device intended for fixed installation. Wi-Fi reduces cabling, but it also introduces more variables such as RF conditions, power behavior, and reconnect handling. In a project like this, where stable bench-top debugging matters, the W5500 is easier to control.