Ujin Kwon · 권우진

Applied algorithms, vehicle software, telemetry runtimes, and analysis tools

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 20 Hz measurement, NAV-PVT, HPPOSLLH, RAWX, ESF-RAW, MON-HW/RF, and RTCM3 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.

Operational Result

  • 20 Hz receiver setup and UBX message configuration run as part of the managed startup path.
  • Local evidence remains on the car as date-foldered CSV and optional raw UBX logs.
  • Remote evidence exposes correction, GPS, serial, and timeout state through the browser monitor.
  • Downstream use connects the collected logs directly to the Racing Analyze GUI.

Validation Scope

  • The verified scope is the implemented device-to-log-to-monitor path and its recovery behavior.
  • No statistical uptime or positioning-accuracy claim is made without a dedicated field dataset.