Ujin Kwon · 권우진

Numerical solvers, telemetry systems, control, and real-time engineering

Python · Raspberry Pi · u-blox ZED-F9R · RTK/NTRIP · Cloudflare Worker

A car-side telemetry runtime for racing operations: receiver setup, correction ingestion, buffered logging, live remote monitoring, and field recovery around unstable serial input and intermittent correction availability.

ZED-F9RUBX GPS/IMU + RTCM input
→
Raspberry Pi Collectorconfigure, collect, filter, log, recover
→
Cloudflare Workeringest latest debug state
→
Browser MonitorSSE updates + live map/debug view
→
Analysis GUIsegment-based review after collection

Problem

  • The runtime had to survive real field conditions, not lab-perfect sensor input.
  • Correction streams and serial transport could be unstable during operation.
  • The team needed both on-car logging and remote visibility without depending on a fragile manual workflow.

What I Built

  • Raspberry Pi runtime with systemd-managed startup, environment-based configuration, and automatic restart behavior.
  • ZED-F9R configuration path for measurement rate, message setup, and RTCM input preparation at startup.
  • RTK correction flow with NTRIP connection, GGA injection, RTCM queueing, retry handling, and fallback behavior.
  • Buffered logging for date-foldered drive logs, merged GPS/IMU CSV output, and optional raw UBX capture.
  • Fault handling for idle timeout, invalid GPS jumps, serial retry, PVT timeout handling, and optional receiver reconfiguration.
  • Remote monitoring path through Cloudflare Worker + Durable Object + SSE for browser-side live debug and mapping.

Why It Matters

  • This is not just a logger; it is an operational runtime built for track-side use.
  • The monitoring and recovery pieces make the system understandable when something goes wrong, instead of leaving operators blind.
  • The same collected data feeds the analysis workflow, so collection and review are part of one engineering loop.

What This Project Proves

  • Field-runtime mindset: I think about unstable inputs, retries, timeouts, and recoverability, not just happy-path logging.
  • Hardware-to-browser flow design: I can connect device IO, correction streams, service management, cloud relay, and operator visibility.
  • Operational continuity: I value tools that support collection, monitoring, and later analysis as one loop.

Evidence

  • The project description is tied to concrete runtime components: receiver configuration, NTRIP handling, buffered logs, remote state publishing, and browser streaming.
  • The architecture is explicitly connected to the downstream Racing Analyze GUI instead of being presented as an isolated script.
  • Field constraints and recovery behavior are treated as first-class design goals, which is the part most generic student telemetry demos usually skip.

Current Limits

  • This page still needs direct screenshots from the live monitor and logging artifacts to become stronger than a text-only architecture summary.
  • I am not publishing unverified operational numbers here yet; adding measured recovery and logging-rate data would strengthen this page further.