Short Description
FieldLink is a four-board ESP32-S3 learning platform that turns embedded systems education into an evidence-driven engineering workflow. Three instrumented sensor nodes transmit environmental and power telemetry over encrypted ESP-NOW to a base station. A local Mac console records, visualizes, audits, and safely controls the network. Codex helped take the project from a beginner's wiring question to tested firmware, protocol design, automated acceptance gates, and real-hardware evidence.
Inspiration
Embedded systems tutorials often stop when a sensor prints a plausible number. That leaves beginners without a way to learn the harder engineering questions: How do we know a packet is authentic? What happens when a node disappears? Can a long run be audited? Does the current sensor agree with a multimeter? Can someone else run the software without owning the hardware?
FieldLink was built to make those questions visible and testable. It is designed for remote environmental monitoring, emergency communication education, and ECE learning. It deliberately excludes targeting, jamming, spoofing, weapons, and offensive communication features.
What It Does
- Reads temperature, humidity, pressure, voltage, current, power, and energy from three ESP32-S3 sensor nodes.
- Sends versioned telemetry through encrypted ESP-NOW unicast to a base station.
- Rejects wrong identities, malformed packets, invalid authentication, and replayed counters while preserving valid traffic.
- Detects an offline node within ten seconds and tracks sequence gaps and reboots.
- Records raw Serial, JSONL events, packet CSV, and status CSV without overwriting earlier evidence.
- Provides a local live console with telemetry, health, loss, security counters, and timeout-limited diagnostic controls.
- Replays a checked-in real-hardware sample so judges can use the product without ESP32 boards.
- Uses a fixed 43-gate product acceptance contract instead of treating a successful compile as completion.
How We Built It
The nodes and base are written in beginner-readable Arduino C++ and built through PlatformIO in VS Code. The radio layer uses ESP-NOW with provisioned peer identities and encrypted unicast. A compact versioned packet protocol carries boot identities, monotonic counters, sensor flags, telemetry, and authenticated command acknowledgments.
The Mac product layer is deliberately dependency-light: Python reads the USB Serial stream, writes durable evidence files, serves the local console, and supports offline replay. Host-side C++ tests validate packet structures, while Python tests exercise recording, replay, acceptance, security counters, power-cycle evidence, and soak-run analysis.
The repository was created during the Build Week submission period. Its dated Git history begins on July 17, 2026 and records each independently reversible change.
How Codex And GPT-5.6 Were Used
Codex was the engineering partner throughout the project, not a one-shot code generator. It inspected live hardware and repository state, proposed small changes, wrote firmware and host tools, ran tests and builds, read real Serial telemetry, and refused to mark gates complete without physical evidence.
The human made the product and hardware decisions: the safety boundary, learning goal, component choices, wiring, multimeter probing, deployment priorities, and the requirement that teaching begin only after product acceptance. Codex accelerated:
- translating beginner requirements into a fixed, testable system contract;
- evolving one-node sensor code into a three-node encrypted network;
- building a durable recorder and coherent local console;
- finding and fixing false-positive acceptance risks;
- designing reproducible soak, calibration, power-cycle, and physical evidence;
- maintaining progress, decisions, environment memory, Git history, and backups.
GPT-5.6 and Codex were especially valuable at the hardware-software boundary. For example, when NODE 3 reported nearly zero current after a wiring change, Codex did not accept the value as a loaded measurement. It waited for another sample, identified an open circuit, guided a powered-off reseat, and then verified 13.6 mA in both the multimeter and INA219.
Challenges
The hardest part was separating plausible output from trustworthy evidence. USB device paths changed, recording sessions could be interrupted, node restarts could hide inside long tests, and a live snapshot could be copied inconsistently. Each failure mode became a concrete check: USB identity detection, atomic evidence files, session metadata tied to a clean Git commit, packet-rate and event-gap requirements, and backup refusal while recording is active.
Another challenge was keeping the architecture understandable for a beginner. The project uses explicit packets, small Python tools, readable diagnostics, and a staged acceptance contract rather than hiding behavior behind a large framework.
Accomplishments
- Three encrypted sensor nodes and one base station operate as a real network.
- A clean 12.50-hour three-node reliability window passed with no node reboot or offline state; per-node packet loss remained below 0.01 percent.
- All three INA219 modules were compared against a VICTOR 520 multimeter. Loaded current error was 1.5 percent, 3.0 percent, and 0.0 percent for NODE 1-3.
- The release verifier passes 79 Python tests and all eight PlatformIO environments, plus protocol, console, documentation, and whitespace checks.
- The fixed v1.0 contract currently has 36 of 43 gates accepted. Four-board power cycling is complete; remaining gates are honestly limited to final mechanical mounting and final delivery/tag steps.
What We Learned
The project changed the definition of progress from "the code runs" to "the claim has evidence." It also showed how an AI coding agent can support ECE learning when it preserves the student's decisions, exposes uncertainty, and connects firmware, radio protocols, data systems, tests, and physical measurements in one workflow.
What's Next
The immediate next step is completing nonconductive mounting, strain relief, and a guided power-cycle audit for all four boards. After v1.0 acceptance, FieldLink will enter a reverse-teaching mode where individual sensors, telemetry, and validation paths are safely disabled and restored so the student can trace the complete system. A future protocol-v3 research branch explores bounded multi-hop store-and-forward communication, but it is explicitly outside the current accepted product.
Judge Quick Start
No hardware is required for replay mode:
git clone https://github.com/finneaswang/FieldLink.git
cd FieldLink
./scripts/run_replay_demo.sh
Open http://127.0.0.1:8766. The sample is a compact extract from the accepted
three-node hardware session. Replay controls are intentionally disabled because no
live base station is connected.
For full software verification:
python3 -m venv .venv
.venv/bin/pip install -r requirements.txt
./scripts/verify_release.sh
PlatformIO, Node.js, and a C++ compiler are required for the complete verifier.
Log in or sign up for Devpost to join the conversation.