FDC Tracker Prototype: What I Built, What I Learned, and Why I’m Rebuilding

I built the first version of the FDC Tracker to run on a portable Raspberry Pi terminal for tracking fire missions, launcher tasking, and system status. It worked—but testing it in the real setup made the limits obvious. This post is a straight record of that prototype: the hardware, what the software did, what broke, and why I’m rebuilding from the ground up instead of patching.

Hardware Setup

The prototype ran on a simple, portable stack: a Raspberry Pi 5, a 15.6-inch portable touchscreen monitor, and a portable battery bank powering both. Cables connected the Pi to the monitor for video and touch, and the battery kept the whole thing running without a wall outlet.

Prototype setup: Pi, touchscreen, and battery bank. The dashboard is visible on the display.

The Pi lived in a white case with a fan; the monitor showed the tracker UI in a dark theme. In practice it behaved like a single-purpose terminal: one box, one screen, one app. That part of the idea held up.

One quirk: during boot the Pi sometimes threw a low-voltage warning. Once everything was up and running, operation was normal, but it’s something I’d want to account for in a production setup—either with a beefier power path or by tuning boot load.

Boot Process and Kiosk Mode

I didn’t want users to see a full desktop. The goal was “turn it on and get the tracker.” So the system boots straight into Firefox kiosk mode, which loads the tracker interface automatically. No taskbar, no browser chrome—just the app. That turned the Pi + monitor into a dedicated terminal rather than a general-purpose computer, and it’s one of the things that worked well from day one.

Tracker Software Features

The web app (version 1.0.2 in the prototype) exposed the main workflows I cared about.

System Information Dashboard — A dedicated view pulls live data from the Pi: CPU temperature, voltage, load, memory and disk usage, uptime, hostname, OS version, and CPU model. Handy for checking that the box was healthy in the field.

System Info view with Pi metrics and the placeholder for 1523 SINCGARS radio integration.

Fire mission tracking — The main interface lets you initiate fire missions, assign launcher taskings, and see launcher status (round types, round counts, standby time). Summary cards show active launchers, pods in inventory, and available rounds. The data model and flows here were enough to validate that the workflows made sense.

Reporting — A reporting section supports quick report generation and viewing. Basic, but it proved that baking reporting into the same terminal was viable.

Interactive guide — I added a step-by-step guide to walk users through workflows. In practice it was unstable: highlighting was laggy, it sometimes skipped steps, and navigation between steps was inconsistent. I’m not trying to salvage it in the prototype; it’s a candidate for a cleaner implementation in the rebuild.

Networking — The stack can detect and connect to other tracker instances on the same Wi-Fi network. Right now there’s no UI for it; connections only show up in backend console logs. So the capability exists but isn’t usable from the touchscreen.

Planned radio integration — The UI has a placeholder for 1523 SINCGARS radio connection (configuration and monitoring). I never implemented it because the required cable wasn’t available during development. The placeholder is still there as a reminder for the next version.

Touchscreen Interface Issues

The prototype was built for a desktop browser and then run on a touchscreen. It functioned, but it wasn’t designed for touch.

Buttons were too small for reliable finger taps. Scroll behavior didn’t feel right for touch. Icon hitboxes were inconsistent—some areas too sensitive, others hard to hit. Overall, touch targets and feedback were an afterthought. Using it on the 15.6" display made it clear that fixing this would mean more than a few CSS tweaks; the layout and interaction model would need to be rethought. That was a major reason to treat the next version as a redesign, not a patch.

What Worked Well

A few things held up:

• Portable, single-purpose terminal — Pi + battery + kiosk mode gave a “turn on and use” experience.
• Core feature set — Fire mission tracking, launcher status, and system info were enough to prove the concept and use it in practice.
• System info dashboard — Having Pi health (temp, voltage, memory, disk) in-app was useful and didn’t require SSH.
• Reporting in the same UI — Keeping reports inside the tracker instead of a separate tool matched how I wanted to use it.

So as a first prototype, it did its job: it showed that the idea was viable and highlighted where the design was lacking.

Why the System Is Being Rebuilt

Patching the prototype would have meant:

• Reworking the entire UI for touch (target sizes, scroll, hitboxes, feedback).
• Fixing or replacing the interactive guide.
• Adding a proper UI for networking and sync.
• Revisiting state and data models that had grown tangled as features were added.

Doing that on top of the existing codebase would have been a long series of workarounds. I decided it was cleaner to rebuild with the right constraints from the start: touch-first UI, clearer architecture, and networking/sync as a first-class part of the design. That’s the direction I’m taking with the new system (documented in the WalkerTrack devlog).

Conclusion

The first FDC Tracker prototype was a functional but rough proof of concept. The hardware setup and kiosk workflow worked; the core tracking and reporting features were usable; and the system info view was genuinely helpful. What didn’t work was the touch experience and several half-finished or backend-only features. Rather than carry that debt forward, I’m treating this as a clear stopping point for the prototype and a baseline for the rebuild. If you’re working on something similar—a web app that has to live on a Pi and a touchscreen—hopefully this gives you a few concrete lessons from one pass through the loop.