Racing Telemetry Stack

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.

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.

Runtime Design

• The collector is a systemd-managed runtime with receiver setup, correction handling, logging, and restart behavior.
• The monitoring and recovery pieces expose serial state, correction state, GPS validity, and timeout conditions to the operator.
• The same collected data feeds the analysis workflow, so collection and review are part of one engineering loop.

Result

• Configured and monitored a ZED-F9R-based Raspberry Pi telemetry runtime.
• Connected device IO, RTK correction streams, local logging, cloud relay, browser monitoring, and downstream analysis.
• Added retry, timeout, filtering, and recovery behavior around field data collection.

Evidence

• The project description is tied to concrete runtime components: receiver configuration, NTRIP handling, buffered CSV/UBX 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 part of the implementation: retries, timeouts, filtering, and monitoring are described as runtime features.

Evidence Scope

• This page describes implemented runtime behavior: receiver configuration, NTRIP handling, buffered logs, remote state publishing, and browser streaming.
• The emphasis is the working data path and field recovery behavior, not a statistical reliability claim.