id: 81990bd067a64ad281c8a46dd23debef
parent_id: 485cf245d89b4bd994e5c3f19eb439f6
item_type: 1
item_id: 6c0dcb2a567348fd9796f50c790082e4
item_updated_time: 1782289568720
title_diff: "[]"
body_diff: "[{\"diffs\":[[0,\"| **\"],[-1,\"Language** | Rust |\\\n| **IDE** | RustRover |\\\n| **Local path** | `~/RustroverProjects/rusty-telemetry` |\\\n| **Remote** | `ssh://jan@192.168.1.2/home/jan/Development/Repositories/rusty-telemetry.git` |\\\n| **Codeberg** | `ssh://git@codeberg.org/jhunnius/rusty-telemetry` |\\\n| **Status** | **v0.7.0 — Session persistence, car characteristics DB, track_map removal** |\\\n| **API Reference** | [rusty-telemetry — REST API Reference](joplin://0c837f4e6b7e462a997cbc19e47c864a) |\\\n\\\n### Repo: `racecraft` (Vue.js Web Client)\\\n\\\n| Field | Value |\\\n|---|---|\\\n| **Language** | TypeScript, Vue 3 |\\\n| **IDE** | WebStorm |\\\n| **Local path** | `~/WebstormProjects/racecraft` |\\\n| **Remote** | `ssh://jan@192.168.1.2/home/jan/Development/Repositories/racecraft.git` |\\\n| **Codeberg** | `ssh://git@codeberg.org/jhunnius/racecraft` |\\\n| **Status** | **v0.1.5 — Characteristics views, tracks views, track_map removal** |\\\n| **Client Notes** | [racecraft — Vue.js Web Client Notes](joplin://50a09627d5d347009197b94bcee90411) |\\\n\\\n### Related Notes\\\n\\\n| Note | ID |\\\n|------|----|\\\n| [Architecture & Infrastructure](joplin://c1c3a7b2055642268ab230b95551f470) | Client vs. Server, Desktop Packaging, Pre-Calculated Data |\\\n| [AC — UDP Protocol Spec](joplin://aed9f3be040943048273a16e05a8100f) | Assetto Corsa telemetry binary protocol |\\\n| [ACC — UDP Protocol Spec](joplin://6ae7005d9810437093d63470cff98b59) | ACC telemetry protocol (registration + broadcast) |\\\n| [AC EVO — Telemetry Research](joplin://2171d34ab9c1431ea3a979d30d206e23) | AC EVO status — no known telemetry output yet |\\\n| [AC Rally — Telemetry Research](joplin://b7b331aa87544b6ebe5db5b8d7bcd2a0) | AC Rally status — UE5, no known telemetry output yet |\\\n| [PCARS — UDP Protocol Spec](joplin://c6bd2c45938246fa9d61776deae9874b) | Project CARS 1 & 2 telemetry binary protocol |\\\n| [DiRT Rally — UDP Protocol Spec](joplin://877a753ad06a40e08059834d8c8fb438) | DiRT Rally 1 & 2.0 telemetry (Codemasters format) |\\\n\\\n---\\\n\\\n## 9. Implementation Phases\\\n\\\n### Phase 1: Core Infrastructure\\\n\\\n- **1.0 Rewrite KSUDP to proper 3-phase handshake protocol** — IMPLEMENTED IN v0.3.0\\\n  - [x] Multi-port UDP binding (9996, 10101, 5606)\\\n  - [x] Per-feed status reporting with health indicators\\\n  - [x] Data dump to per-feed files\\\n  - [x] 3-phase handshake for KSUDP\\\n  - [x] Remove port 5005 (Lua plugin) — abandoned\\\n  - [x] Make port 10101 (Telemetry Tool) optional\\\n  - [x] Configurable via env vars: `GAME_HOST`, `LISTEN`, `BIND` (v0.4.1)\\\n  - [x] Remote operation support — game and listener can run on different machines (v0.4.1)\\\n  - [ ] Verify KSUDP streaming works with live AC session\\\n  - [ ] Verify PCARS works with live game session\\\n\\\n- **1.1 Binary parsers — IMPLEMENTED IN v0.3.0 + v0.4.0**\\\n  - [x] `parser-ksudp` for port 9996 (RTCarInfo struct, 6 unit tests)\\\n  - [x] `parser-telemetry-tool` for port 10101 (357-byte driver struct, 7 unit tests)\\\n  - [x] `binary_utils` shared module for safe packet reading\\\n  - [x] `parser-pcars` for port 5606 (auto-detect V1/V2, 7 unit tests)\\\n  - [x] Map all parsers to generic `TelemetryFrame` model\\\n  - [x] `parse_first_driver()` optimization for Telemetry Tool\\\n\\\n- **1.2 REMOVED** (was Lua plugin — abandoned, see Section 4)\\\n\\\n- **1.3 Telemetry Tool — WORKING, OPTIONAL**\\\n  - [x] Verified — 6.3 MB of valid binary data captured on port 10101\\\n  - [x] Binary parser implemented with validation checks\\\n  - [x] `parse_first_driver()` avoids unnecessary Vec allocation\\\n  - [x] Made optional in rusty-telemetry (shows as \\\"not available\\\" if bind fails)\\\n\\\n- **1.4 PCARS Support — IMPLEMENTED IN v0.4.0, ENHANCED 2026-06-08**\\\n  - [x] Auto-detect PCARS 1 (1367-byte packets) vs PCARS 2 (559-byte packets)\\\n  - [x] Parse V1 telemetry (speed, RPM, gear, inputs, tyres, engine, weather)\\\n  - [x] Parse V2 car physics (speed, RPM, gear, inputs, tyres, 3D position)\\\n  - [x] PCARS-specific fields in TelemetryFrame (oil/water temp, damage, weather)\\\n  - [x] Port 5606 as optional bind-listen feed (like Telemetry Tool)\\\n  - [x] V1 position data: world_position (3×i16), current_lap_distance, derived spline_position\\\n  - [x] V1 lap count from viewed participant entry\\\n  - [x] `TelemetryFrame::current_lap_distance` field\\\n  - [x] 7 unit tests for parser (was 5, +2 for V1 position)\\\n\\\n- **1.5 Code Quality — IMPLEMENTED IN v0.3.0 + v0.4.0**\\\n  - [x] Mutex not held during TUI rendering (clone FeedState before draw)\\\n  - [x] Parsing moved outside mutex lock (minimizes contention)\\\n  - [x] `expect()` replaced with graceful error handling on env vars\\\n  - [x] Shared `binary_utils` module eliminates parser duplication\\\n  - [x] Dead code removed (unused variants, methods)\\\n  - [x] `data_rate_kbps` renamed to `data_rate_kb_s` (correct unit)\\\n  - [x] 33 unit tests total (6 ksudp + 7 pcars + 7 telemetry_tool + 14 feed_state)\\\n\\\n- **1.6 REST API + Recording Manager — IMPLEMENTED IN v0.5.0**\\\n  - [x] `recording.rs` — RecordingManager with UUID-based session directories\\\n  - [x] `manifest.json` per recording with metadata (game, track, car, use_case, status, timestamps, feed stats)\\\n  - [x] Auto-start recording on launch\\\n  - [x] CRUD operations: create, list, get, stop, delete recordings\\\n  - [x] `api.rs` — REST API server using axum on configurable port (default 8080)\\\n  - [x] Live telemetry endpoint (`GET /api/live`) with feed snapshots\\\n  - [x] Recording management endpoints (list, create, stop, get, delete)\\\n  - [x] Raw feed binary download (`GET /api/recordings/{id}/data/{feed_name}`)\\\n  - [x] CORS enabled (permissive) for frontend integration\\\n  - [x] New dependencies: axum 0.8, axum-extra 0.10, serde 1, serde_json 1, uuid 1, tower-http 0.6\\\n  - [ ] Add API integration tests\\\n  - [ ] Add recording manager unit tests\\\n\\\n- **1.7 Workspace refactor** (deferred)\\\n  - [ ] Split into Cargo workspace with `core`, `receiver`, parsers\\\n  - [ ] SQLite database with migrations\\\n  - [ ] Basic REST API endpoints\\\n\\\n- **1.8 Session Management + Analysis — IMPLEMENTED IN v0.5.0**\\\n  - [x] `session.rs` — SessionManager with use-case sessions, runs, frame extraction from ring buffers\\\n  - [x] `analysis.rs` — Shift point analysis (gear RPM ranges, upshift detection, recommended shift RPM)\\\n  - [x] `analysis.rs` — Track map analysis (spline-aligned interpolation for center line)\\\n  - [x] `session.rs` — `data_truncated` flag for ring buffer wrap detection\\\n  - [x] `api.rs` — 9 new session endpoints (CRUD, run management, analysis triggers)\\\n  - [x] `recording.rs` — Ring buffer mutex held only during frame clone, not JSON serialization\\\n  - [x] `recording.rs` — Flush failure propagation (errors prevent Stopped status)\\\n  - [x] `recording.rs` — `stop_recording` holds active lock across flush (prevents race)\\\n  - [x] Mutex poisoning recovery on session API handlers\\\n  - [x] `gear_display` deduplicated into shared free function\\\n  - [ ] Add session/analysis unit tests\\\n  - [ ] Add ring buffer unit tests\\\n\\\n- **1.9 Run Management Enhancements — IMPLEMENTED IN v0.6.0 (both repos)**\\\n  - [x] **Feed merging for runs** — Allow merging two feeds into a single run for more accurate data\\\n    - `POST /api/sessions/{id}/runs` — extended with optional `merge_feeds: string[]`\\\n    - `session.rs` — `start_run` accepts merge feeds, `extract_run_frames` combines frames from multiple feeds\\\n    - racecraft: merge feeds toggle with feed checkboxes when starting a run\\\n  - [x] **Run deletion** — Delete individual runs, with session reopen option\\\n    - `DELETE /api/sessions/{id}/runs/{run_id}` — delete a run from a session (returns 204)\\\n    - `POST /api/sessions/{id}/reopen` — re-open completed session (status → active)\\\n    - racecraft: delete button per run with confirmation; reopen button on completed sessions\\\n\\\n- **1.10 Shifting Analysis Charts — IMPLEMENTED IN v0.1.2 (racecraft)**\\\n  - [x] RPM vs. Force scatter chart (x: RPM, y: acceleration_g)\\\n  - [x] Speed vs. Force scatter chart (x: speed_kmh, y: acceleration_g) — renamed from \\\"Gear Acceleration Curves\\\"\\\n  - [x] Speed vs. RPM scatter chart (x: speed_kmh, y: rpm) — gear ratio visualization\\\n\\\n- **1.11 Track Mapping Implementation — IMPLEMENTED 2026-06-08 (both repos)**\\\n  - [x] **PCARS V1 position data** — Read world_position (3×i16) and current_lap_distance from viewed participant, derive spline_position, 2 new unit tests\\\n  - [x] **Dual position mode** — Auto-detect spline vs. coordinate mode (`PositionMode` enum), compute cumulative 2D distance as pseudo-spline for PCARS/future games\\\n  - [x] **Persistent TrackModel** — `track_model.rs` module with `TrackModel`, `Corner`, `Sector`, `TrackModelSource` structs, serde serialization\\\n  - [x] **TrackModelStore** — Async CRUD at `data/tracks/<game>/<track_name>.json`, path traversal protection, `TrackSummary` for listings\\\n  - [x] **Track model building algorithm** — Resample boundaries (2000 points) → center line (midpoint) → track width → heading (atan2) → curvature κ = dθ/ds → smooth (moving avg) → corner detection (|κ| > 0.005) → 3 sectors → coordinate normalization to [0,1]²\\\n  - [x] **TrackMapping use case** — New `UseCase::TrackMapping` variant with step-by-step boundary recording guidance (left lap + right lap)\\\n  - [x] **Track API endpoints** — `GET /api/tracks`, `GET/DELETE /api/tracks/{game}/{track_name}`, `GET .../corners`, `POST /api/tracks/build`\\\n  - [x] **New TelemetryFrame field** — `current_lap_distance: Option<u16>`\\\n  - [x] `Game::to_track_dir_name()` helper for filesystem-safe game identifiers\\\n  - [x] **racecraft: Track API client** — `listTracks()`, `getTrack()`, `deleteTrack()`, `buildTrackModel()` functions\\\n  - [x] **racecraft: Track model types** — `TrackModel`, `TrackSummary`, `Corner`, `Sector`, `BuildTrackModelRequest`\\\n  - [x] **racecraft: Tracks Pinia store** — `fetchTracks()`, `fetchTrack()`, `deleteTrack()` actions\\\n  - [x] **racecraft: TracksView** — Track listing page with game labels, corner counts, delete action\\\n  - [x] **racecraft: TrackDetailView** — Full geometry rendering with Canvas 2D (boundaries, curvature heat map, corner markers, sector shading, toggle controls)\\\n  - [x] **racecraft: Track mapping workflow** — Build Track Model button on completed `track_mapping` sessions, validates left + right boundary runs\\\n  - [x] **racecraft: Navigation** — Tracks nav item, tracks routes, track_mapping use case option\\\n  - [ ] Add track model builder unit tests\\\n  - [ ] Verify track mapping workflow with live session data\\\n\\\n- **1.12 Session Persistence + Car Characteristics — IMPLEMENTED 2026-06-24 (both repos)**\\\n  - [x] **Persistent sessions** — Session metadata, runs, and analysis results survive server restart\\\n    - Metadata stored at `data/sessions/<id>.json` (runs, analysis, car_name)\\\n    - Frames stored separately at `data/sessions/<id>.frames.json` (lazy-loaded on demand)\\\n    - Metadata-only load on startup for fast session listing\\\n    - `ensure_frames_loaded()` lazy-loads frames before analysis/extraction\\\n    - Atomic writes (temp file + rename), compact JSON serialization\\\n    - Frame serialization offloaded to background thread (clone under lock, write off-thread)\\\n    - `car_name: Option<String>` cached on `UseCaseSession` (set during `stop_run`/`complete_session`)\\\n    - Recording runs normalized to `Stopped` on reload (stale ring-buffer markers)\\\n    - `extract_car_name()` helper scans frames for first non-empty car name\\\n  - [x] **Car characteristics aggregation** — Cross-session shift-point profiles per car\\\n    - `characteristics.rs` — aggregate shift-point data from all completed `shift_points` sessions\\\n    - `GET /api/characteristics/cars` — list all cars with session_count + recommended_shift_rpm\\\n    - `GET /api/characteristics/cars/{car}` — detailed per-gear RPM/speed ranges\\\n    - Typed `Deserialize` view structs (`ShiftPointAnalysisView`, `GearCurveView`) for analysis JSON\\\n  - [x] **Remove obsolete `track_map` use case** — Superseded by `track_mapping` (track_map was the old analysis-only variant)\\\n    - Removed from `UseCase` enum, `analysis.rs` dispatch\\\n    - Removed from racecraft types, views, router\\\n    - Deleted `TrackMapView.vue` in racecraft\\\n  - [x] **racecraft: CharacteristicsView** — Expandable car cards with per-gear RPM/speed ranges\\\n    - `listCarProfiles()` API client function\\\n    - `CarProfile`, `CarGearProfile` TypeScript types\\\n    - Characteristics nav item + route\\\n  - [x] **racecraft: UX fix** — `handleBuildTrack` now auto-runs `reAnalyze()` before `buildTrackModel()`\\\n  - [x] **TelemetryFrame** — Added `Deserialize` derive (needed for session frame round-trip)\\\n  - [x] Documentation updated: READMEs, AGENTS.md (both repos)\\\n\\\n---\\\n\\\n## 10–12. [Unchanged — Rally, References, Metrics]\\\n\\\n*(See note history for sections on Rally games, additional references, metrics definitions, and game priority rankings)*\\\n\\\n---\\\n\\\n## 13. Operations & Debugging Reference\\\n\\\n> **Full API documentation moved to:** [rusty-telemetry — REST API Reference](joplin://0c837f4e6b7e462a997cbc19e47c864a)\\\n> That note contains all endpoints, request/response formats, environment variables, and UDP port configuration.\\\n\\\n### Environment Variables (quick reference)\\\n\\\n| Variable | Purpose | Default |\\\n|----------|---------|---------|\\\n| `RUSTY_TELEMETRY_GAME_HOST` | IP of the sim machine | `127.0.0.1` |\\\n| `RUSTY_TELEMETRY_LISTEN` | Local bind for incoming feeds | `0.0.0.0` |\\\n| `RUSTY_TELEMETRY_API_PORT` | REST API port | `8080` |\\\n| `RUSTY_TELEMETRY_API_HOST` | REST API bind address | `127.0.0.1` |\\\n\\\n---\\\n\\\n## 14. Session Diagnostics\\\n\\\n### Session 2026-06-03 ~09:45 — Initial Capture\\\n*(See note history for details)*\\\n\\\n### Session 2026-06-03 19:32 — Investigation Results\\\n*(See note history for details)*\\\n\\\n### Startup Order for Next Session\\\n\\\n**Same machine:**\\\n1. Start game → let it initialize\\\n2. Start rusty-telemetry → auto-handshake, auto-start recording\\\n\\\n**Remote:**\\\n1. Start game on game machine\\\n2. Configure game to send to analysis machine's IP\\\n3. Start rusty-telemetry with `RUSTY_TELEMETRY_GAME_HOST=<game-IP>`\\\n\\\n---\\\n\\\n## 15. Change Log\\\n\\\n> **Per-repo change logs moved to:**\\\n> - [rusty-telemetry — REST API Reference](joplin://0c837f4e6b7e462a997cbc19e47c864a) (backend version history)\\\n> - [racecraft — Vue.js Web Client Notes](joplin://50a09627d5d347009197b94bcee90411) (frontend version history)\\\n\\\n### Recent Changes (summary)\\\n\\\n| Version | Date | Highlights |\\\n|---------|------|------------|\\\n| rusty-telemetry v0.7.0 | 2026-06-24 | Session persistence (split metadata/frames files, atomic writes, lazy load), car characteristics DB (`characteristics.rs`, 2 API endpoints), remove `track_map` use case, `Deserialize` on TelemetryFrame |\\\n| racecraft v0.1.5 | 2026-06-24 | CharacteristicsView (expandable car cards), tracks views committed, `track_map` removal, auto-analyze before build track model, API endpoint count updated (28) |\\\n| racecraft v0.1.4 | 2026-06-08 | Track mapping web client: TracksView, TrackDetailView (Canvas 2D geometry rendering with curvature heat map, corner markers, sectors), track API integration, build track model workflow in session detail, track_mapping use case |\\\n| Post-v0.6.0 | 2026-06-08 | Track mapping backend: persistent TrackModel, track API, PCARS V1 position, dual position mode, corner detection, boundary recording workflow |\\\n| rusty-telemetry v0.6.0 | 2026-06-06 | Run deletion, session reopen, feed merging |\\\n| racecraft v0.1.3 | 2026-06-06 | Run management UI, feed merging toggle, session reopen button |\\\n| racecraft v0.1.2 | 2026-06-06 | RPM vs. Force, Speed vs. RPM charts, chart renames |\\\n| racecraft v0.1.1 | 2026-06-05 | Dashboard status card layout (3-column grid) |\\\n| rusty-telemetry v0.5.0 | 2026-06-05 | REST API, recording manager, session analysis |\\\n| rusty-telemetry v0.4.1 | 2026-06-04 | Remote operation support (GAME_HOST/LISTEN split) |\\\n| rusty-telemetry v0.4.0 | 2026-06-04 | PCARS 1 & 2 support, binary_utils refactor |\\\n| rusty-telemetry v0.3.0 | 2026-06-04 | TUI, KSUDP handshake fix, binary parsers |\\\n\\\n---\\\n\\\n## 16. Product Roadmap — From Tool to Product\\\n\\\n> **Analysis date: 2026-06-06**\\\n> **Context: What it would take to turn rusty-telemetry + racecraft into a sellable product or service, for sim racing and potentially real racing.**\\\n\\\n---\\\n\\\n### 16.1 Current State Assessment\\\n\\\n**What we have (post-v0.7.0):**\\\n- A robust Rust backend that captures 60 Hz telemetry from Assetto Corsa (via Telemetry Tool on port 10101), with parsers for KSUDP and PCARS 1/2\\\n- A unified `TelemetryFrame` data model across all game protocols, now with PCARS V1 position data\\\n- A REST API (28 endpoints) with recording management, session management, run management (delete, merge feeds, reopen), analysis (shift points, track maps), track model persistence, and **car characteristics aggregation**\\\n- **Persistent sessions** — Session metadata, runs, analysis results, and frames survive server restart; lazy-loaded frames for fast startup; atomic writes\\\n- **Car characteristics database** — Aggregated shift-point profiles per car across all sessions (`characteristics.rs`, `GET /api/characteristics/cars`)\\\n- **Persistent track models** — `TrackModel` with center line, boundaries, curvature, auto-detected corners, sectors; stored at `data/tracks/<game>/<track_name>.json`\\\n- **Dual position mode** — works with both spline-based feeds (AC/Telemetry Tool) and coordinate-based feeds (PCARS), enabling track mapping across games\\\n- **Boundary recording workflow** — deliberate 2-lap track mapping with `TrackMapping` use case, web client with guided workflow and build track model button\\\n- A Vue 3 web frontend (racecraft) with dashboard, live feeds, session management, run management, shifting analysis charts, **car characteristics views**, track listing/detail views with Canvas 2D geometry rendering\\\n- Ring buffer architecture with JSONL persistence\\\n- Remote operation support (game and analysis machine can be separate)\\\n- Multi-game protocol support (AC, PCARS 1/2), though only AC verified with live sessions\\\n\\\n**What we DON'T have yet:**\\\n- No user authentication or multi-user support\\\n- No cloud deployment — runs locally only\\\n- No real-time WebSocket streaming to the frontend (polling `/api/live` only)\\\n- No AI-driven coaching or automated insights\\\n- No reference lap comparison (the \\\"Track Titan killer\\\" feature)\\\n- No community features (leaderboards, lap sharing, setup sharing)\\\n- No rally game support despite rally being mentioned in the training roadmap\\\n- No mobile companion app\\\n- No real-world telemetry integration (CAN bus, OBD-II, GPS data)\\\n\\\n---\\\n\\\n### 16.2 Competitive Landscape Analysis\\\n\\\n#### Tier 1: Direct Sim Racing Telemetry Competitors\\\n\\\n| Product | Games | Pricing | Key Features | Users | Backing |\\\n|---|---|---|---|---|---|\\\n| **Track Titan** | AC, ACC, F1, iRacing, AMS2, LMU, Forza | Freemium (free + paid tiers) | AI Coaching Flows, auto-setup download, F1 real lap analysis, community news | 285K+ members, 100M+ laps | Porsche Ventures, Axel Springer, Antler, former F1/WRC execs |\\\n| **SimRacingSetup** | F1 25/26 only (more planned) | Free + £4.99/mo telemetry + £99.99/yr Pro | Pro lap comparison, ERS/tyre maps, career tracking, leaderboards, web-based | 15K+ customers | Bootstrapped |\\\n| **VRS (Virtual Racing School)** | iRacing | Subscription | Telemetry analysis, coaching, data packs, setup optimization | ~50K iRacing-focused | Bootstrapped, iRacing-ecosystem |\\\n\\\n#### Tier 2: General Data Analysis Tools Used in Sim Racing\\\n\\\n| Product | Type | Pricing | Notes |\\\n|---|---|---|---|\\\n| **MoTeC i2** | Professional data analysis software | License-based (expensive) | Industry standard for real motorsport. Sim racers use it via exported data. |\\\n| **ATLAS (McLaren Applied)** | F1-grade telemetry system | Enterprise / F1-only | Multi-million dollar per season. |\\\n| **Cosworth Toolbox** | Real racing data analysis | License-based | WEC, IndyCar, Touring Cars |\\\n\\\n#### Tier 3: Community & Content Platforms\\\n\\\n| Product | Role | Rally Coverage | Notes |\\\n|---|---|---|---|\\\n| **OverTake.gg** (formerly RaceDepartment) | Sim racing community hub | Has WRC, AC Rally categories; partnered with Track Titan | The Track Titan × OverTake collaboration is the distribution model to study |\\\n| **RaceChrono** | Real-world mobile lap timer & data logger | n/a (real-world) | See **§18** for full RaceChrono inspiration analysis |\\\n\\\n---\\\n\\\n### 16.3 The Track Titan × OverTake Model\\\n\\\nTrack Titan's collaboration with OverTake.gg (2M+ registered users) is the case study for how to build a product in this space:\\\n\\\n1. **Track Titan** builds the telemetry + coaching technology (SaaS product)\\\n2. **OverTake.gg** provides the community, content, and distribution channel\\\n3. OverTake integrates Track Titan as a \\\"Community Benefit\\\"\\\n4. Both parties monetize: Track Titan through subscriptions, OverTake through premium memberships\\\n\\\n**Key lesson:** Distribution and community matter as much as technology. The sim racing market is fragmented across many games — a platform approach works better than a single-game tool. Freemium model lowers barrier to entry.\\\n\\\n---\\\n\\\n### 16.4 Rally Telemetry — The Underserved Market\\\n\\\n**No competitor serves rally telemetry.** This is a genuine differentiator.\\\n\\\n| Aspect | Circuit Racing | Rally |\\\n|---|---|---|\\\n| Track | Static, memorizable | Dynamic, pacenote-dependent |\\\n| Surface | Uniform | Mixed (gravel, tarmac, snow, ice, mud) |\\\n| Analysis unit | Lap time | Stage time |\\\n| Key metric | Consistency across laps | Commitment to pacenotes, surface adaptation |\\\n| Coaching focus | Braking points, racing line | Pacenote accuracy, weight transfer on loose surfaces |\\\n\\\n**AC Rally** (UE5, Early Access) is the key long-term opportunity. If KUNOS ports their telemetry infrastructure, we get rally-specific data with circuit-quality depth.\\\n\\\n**DiRT Rally 2.0** is the fastest path to rally coaching NOW. It uses the proven Codemasters UDP protocol (port 20777), includes **per-wheel surface type** (the single most important rally coaching field), and is a released, working game. See [DiRT Rally 1 & 2.0 — UDP Telemetry Protocol Specification](joplin://877a753ad06a40e08059834d8c8fb438).\\\n\\\n| Rally Game | Protocol Status | Surface Data | Availability | Our Priority |\\\n|---|---|---|---|---|\\\n| **DiRT Rally 2.0** | ✅ Proven (Codemasters UDP) | ✅ Per-wheel | Available now | HIGH — fastest path |\\\n| **DiRT Rally 1** | ✅ Proven (Codemasters UDP) | ❌ | Available now | MEDIUM |\\\n| **AC Rally** | ❌ Unknown (EA) | Unknown | Early Access | HIGH — long-term |\\\n| **EA Sports WRC** | ✅ Codemasters format | Likely | Available | LOW — not planned |\\\n\\\nSee [AC Rally — Telemetry Status & Research](joplin://b7b331aa87544b6ebe5db5b8d7bcd2a0) for full investigation plan.\\\n\\\n---\\\n\\\n### 16.5 Real-World Racing Telemetry\\\n\\\nReal racing teams already have expensive, purpose-built systems (MoTeC, ATLAS). The market gap is democratizing professional-grade analysis for:\\\n1. **Sim racers** wanting to improve (Track Titan's 285K users prove this market)\\\n2. **Club/amateur real racers** who can't afford MoTeC-level systems\\\n3. **Rally drivers at national level** who have NO accessible telemetry platform\\\n4. **Sim-to-real pipeline** — consistent analysis across both\\\n\\\n---\\\n\\\n### 16.6 Product Roadmap — From v0.7.0 to Sellable Product\\\n\\\n#### Phase A: Complete the Core (Months 1–3)\\\n\\\n| Milestone | Tasks | Success Metric |\\\n|---|---|---|\\\n| **A1: Verify with live sessions** | Test KSUDP + PCARS with real game sessions | All 3 feeds working reliably |\\\n| **A2: ~~§1.9~~ ✅ DONE** | Feed merging, run deletion, session reopen | Shipped in v0.6.0 / v0.1.3 |\\\n| **A3: ~~Track mapping~~ ✅ DONE** | TrackModel persistence, corner detection, track API, web client | Shipped 2026-06-08 (backend + racecraft v0.1.4) |\\\n| **A3b: ~~Session persistence + characteristics~~ ✅ DONE** | Persistent sessions, car characteristics DB, track_map removal | Shipped 2026-06-24 (v0.7.0 / v0.1.5) |\\\n| **A4: WebSocket streaming** | Replace REST polling with real-time WS | <50ms latency game → browser |\\\n| **A5: Lap detection** | Auto-detect laps from spline position crossing | Automatic lap segmentation |\\\n| **A6: Reference lap overlay** | Load reference lap, overlay current against it | Visual overlay with delta trace |\\\n| **A7: Tyre analysis** | Tyre temperature heat maps, wear projection | Degradation curve graphs |\\\n| **A8: Brake analysis** | Brake pressure traces, consistency scoring | Per-corner braking analysis |\\\n\\\n#### Phase B: Multi-Game & Rally Support (Months 4–6)\\\n\\\n| Milestone | Tasks | Success Metric |\\\n|---|---|---|\\\n| **B1: ACC support** | ACC UDP parser (registration + broadcast) | ACC sessions captured and analyzed |\\\n| **B2: iRacing support** | YAML file or memory-mapped file telemetry | iRacing sessions captured |\\\n| **B3: DiRT Rally support** | DiRT Rally 1 & 2.0 parser (port 20777, Codemasters format) | Rally stages captured with surface data |\\\n| **B4: Rally-specific analysis** | Stage-based analysis, surface detection, pacenote timing | Unique rally coaching insights |\\\n| **B5: F1 game support** | F1 2025/26 UDP telemetry (same Codemasters family as DiRT Rally) | F1 sessions — largest casual audience |\\\n\\\n#### Phase C: AI Coaching & Automation (Months 7–10)\\\n\\\n| Milestone | Tasks |\\\n|---|---|\\\n| **C1: Anomaly detection** | ML model to detect unusual inputs |\\\n| **C2: Coaching Flows** | Step-by-step guided analysis (\\\"Here's your biggest time loss\\\") |\\\n| **C3: Setup recommendations** | Correlate telemetry with setup changes |\\\n| **C4: LLM coaching chat** | Natural language questions about telemetry |\\\n| **C5: Rally pacenote analysis** | Correlate pacenotes with driver inputs |\\\n\\\n#### Phase D: Platform & Monetization (Months 11–18)\\\n\\\n| Milestone | Tasks |\\\n|---|---|\\\n| **D1: User accounts & cloud sync** | Auth, cloud storage, cross-device access |\\\n| **D2: Community features** | Leaderboards, lap sharing, setup sharing |\\\n| **D3: Freemium model** | Free basic + Pro tier |\\\n| **D4: Partnership** | OverTake-style distribution partnership |\\\n| **D5: Mobile companion** | Post-session review, coaching alerts |\\\n| **D6: Real-world telemetry** | OBD-II / CAN bus bridge for sim-to-real |\\\n\\\n---\\\n\\\n### 16.7 Revenue Model Options\\\n\\\n| Model | Pricing | Feasibility |\\\n|---|---|---|\\\n| **SaaS Subscription** (Track Titan model) | Free basic + £5–10/mo Pro + £15/mo Teams | High — proven model |\\\n| **One-time License** (MoTeC model) | $99–299 perpetual | Medium |\\\n| **Self-hosted» | £50–100/mo Docker image | Medium — esports teams, academies |\\\n\\\n**Recommended:** Start with SaaS Freemium, evolve toward real racing telemetry as premium tier.\\\n\\\n---\\\n\\\n### 16.8 Unique Differentiators\\\n\\\n1. **Circuit + Rally in one platform** — Nobody does this\\\n2. **Open-source core** — Builds trust and community\\\n3. **Rust performance** — 60 Hz with <50ms latency. Most competitors use Python/Electron\\\n4. **Self-hostable** — Privacy-conscious users, esports teams\\\n5. **Sim-to-real bridge** — Same tools for sim AND real track days\\\n6. **Local LLM coaching** — Privacy-preserving AI that runs locally\\\n\\\n---\\\n\\\n### 16.9 Key Risks & Mitigation\\\n\\\n| Risk | Probability | Impact | Mitigation |\\\n|---|---|---|---|\\\n| Track Titan expands to rally | Medium | High | Move fast on DiRT Rally support — proven protocol, ship before they do |\\\n| Game devs restrict telemetry | Low | Critical | Support many games |\\\n| AI coaching needs massive data | High | Medium | Start with rule-based coaching |\\\n| Real racing needs hardware | High | High | Defer, validate with sim first |\\\n| User acquisition cost too high | Medium | High | Partner with community platforms |\\\n\\\n---\\\n\\\n### 16.10 Recommended First Steps (Next 30 Days)\\\n\\\n1. ~~Ship §1.9~~ ✅ DONE (v0.6.0 / v0.1.3)\\\n2. ~~Ship track mapping~~ ✅ DONE (2026-06-08 — backend + racecraft v0.1.4)\\\n3. ~~Ship session persistence + characteristics~~ ✅ DONE (2026-06-24 — v0.7.0 / v0.1.5)\\\n4. **Verify with live AC session** — prove the whole stack works end-to-end\\\n5. **Add lap detection** — auto-segment laps from spline data\\\n6. **Build reference lap overlay** — the \\\"Track Titan killer\\\" feature\\\n7. **Purchase DiRT Rally 2.0** — cheapest path to rally telemetry (~€15 on sale)\\\n8. **Implement DiRT Rally parser** — proven protocol, 7 days estimated effort\\\n9. **Research AC Rally telemetry output** — determine if existing parsers work\\\n10. **Draft rally coaching model** — coaching for a stage vs. a lap\\\n\\\n---\\\n\\\n## 17. Analysis Use Cases — Track Mapping, Corner Analysis & Ideal Lap\\\n\\\n> **Analysis date: 2026-06-06**\\\n> **Goal: Define the next analysis use cases beyond shift points, with track mapping as the foundation for everything that follows.**\\\n\\\n---\\\n\\\n### 17.1 Why Track Mapping Must Come First — The Deliberate Boundary Recording Method\\\n\\\n**The core insight:** Every subsequent analysis feature (corner detection, grip mapping, theoretical best lap, optimal racing line) depends on an accurate model of the track geometry.\\\n\\\n**Deliberate boundary recording** (2 slow laps per track) gives ±0.5m accuracy vs. ±2–4m from auto-estimation from normal laps. The track model is persisted and keyed by `(game, track_name)`.\\\n\\\n**The track mapping workflow:**\\\n1. Load track, select car\\\n2. Start a `track_mapping` session\\\n3. **Run 1:** Left boundary (hug left edge)\\\n4. **Run 2:** Right boundary (hug right edge)\\\n5. System builds `TrackModel` automatically\\\n6. TrackModel persisted — all future sessions load it\\\n\\\n**Status (2026-06-08):** Steps 1–5 fully implemented end-to-end (backend + web client). The `TrackMapping` use case provides step-by-step guidance. The `POST /api/tracks/build` endpoint builds and persists the model from a completed session. The racecraft web client provides:\\\n- Session creation with `track_mapping` use case\\\n- \\\"Build Track Model\\\" button that validates left + right boundary runs\\\n- Track listing page and detail view with full geometry rendering\\\n- Step 6 (auto-loading track model for new sessions) is pending.\\\n\\\n---\\\n\\\n### 17.2 The Analysis Pipeline\\\n\\\n```\\\n60 Hz Telemetry → 1. Lap Detection → 2. Track Mapping → \\\n  3. Corner Analysis | 4. Grip Envelope | 5. Theoretical Best Lap →\\\n  6. Time Loss Attribution → 7. Coaching Output\\\n```\\\n\\\n**Status (2026-06-24):** Steps 1–2 partially implemented. Track mapping (step 2) is done end-to-end including web client. Lap detection (step 1) is still pending but is the next priority.\\\n\\\n---\\\n\\\n### 17.3 Lap Detection\\\n\\\nData source: `spline_position` (0.0–1.0). Lap crossing = spline wraps from ~1.0 to ~0.0. Edge cases: invalid laps (off-track), out laps, pit lane, slow crossings.\\\n\\\nEstimated effort: 1–2 days. Foundational — everything depends on it.\\\n\\\n---\\\n\\\n### 17.4 Track Mapping — Building the TrackModel\\\n\\\n**Status (2026-06-08): IMPLEMENTED (backend + web client).**\\\n\\\nNew use case: `track_mapping`. Persistent `TrackModel` stored at `data/tracks/<game>/<track_name>.json`.\\\n\\\nKey data: center_line, left/right boundaries, track_width, heading, curvature κ(s), auto-detected corners and sectors.\\\n\\\nAPI additions: `GET /api/tracks`, `GET /api/tracks/{game}/{track_name}`, `POST /api/tracks/build`, `DELETE /api/tracks/{game}/{track_name}`, `GET .../corners`.\\\n\\\nWeb client (racecraft v0.1.4):\\\n- Track API client functions: `listTracks()`, `getTrack()`, `deleteTrack()`, `buildTrackModel()`\\\n- Tracks Pinia store with CRUD actions\\\n- TracksView: list all stored track models with game labels, corner counts\\\n- TrackDetailView: Canvas 2D rendering with curvature heat map, corner markers, sector shading\\\n- SessionDetailView: \\\"Build Track Model\\\" workflow with boundary run validation\\\n\\\nTrack model building pipeline:\\\n1. Validate 2 boundaries (labeled \\\"left\\\" and \\\"right\\\", min 10 points each)\\\n2. Resample both boundaries to 2000 uniform points via spline interpolation\\\n3. Compute center line (midpoint of left/right at each sample)\\\n4. Compute track width (Euclidean distance left↔right at each sample)\\\n5. Compute heading (atan2 of direction vector between consecutive points)\\\n6. Compute curvature κ = dθ/ds (heading change / arc length)\\\n7. Smooth curvature with moving average\\\n8. Auto-detect corners (|κ| > 0.005 threshold, with hysteresis)\\\n9. Define 3 equal sectors\\\n10. Normalize all coordinates to [0,1]² using global bounds\\\n\\\nDual position mode: auto-detects whether frames have spline data (AC/TT) or only world coordinates (PCARS). For coordinate mode, cumulative 2D distance is used as a pseudo-spline.\\\n\\\n---\\\n\\\n### 17.5 Corner Analysis\\\n\\\nPer-corner breakdown: entry/mid/exit speed trace, G-forces, slip angles, input profile. Requires TrackModel for corner detection.\\\n\\\n**Status:** Track model now provides corners (entry/apex/exit spline positions, curvature peak). Web client renders corner markers on track detail view. Analysis logic still pending.\\\n\\\n---\\\n\\\n### 17.6 Grip Envelope\\\n\\\nFrom all laps: max lateral G, max accel G, max brake G, binned by speed. Produces the \\\"grip circle\\\" boundary. Used for coaching: \\\"car can do 1.4g, you used only 1.1g\\\".\\\n\\\n---\\\n\\\n### 17.7 Theoretical Best Lap\\\n\\\nStitch best sectors across multiple laps into one ideal lap. Produces optimal speed trace.\\\n\\\n---\\\n\\\n### 17.8 Time Loss Attribution\\\n\\\nPer corner per lap: delta vs. theoretical best, root cause (braking too early, not enough throttle, wrong line), where in corner time was lost.\\\n\\\n---\\\n\\\n### 17.9 Coaching Output\\\n\\\nFinal output: \\\"Turn 3: -0.4s. Braked 12m too early. Car can do 1.4g, you used only 1.1g. → Brake 12m later, carry 7 km/h more speed.\\\"\\\n\\\n---\\\n\\\n### 17.10 Implementation Priority\\\n\\\n| Use Case | Depends On | Estimated Effort | Priority | Status |\\\n|----------|-----------|-----------------|----------|--------|\\\n| Track mapping | Spline data / position data | 3–5 days | P0 — blocks corner/grip analysis | ✅ DONE (2026-06-08 — backend + web client) |\\\n| Lap detection | Spline data in TT feed | 1–2 days | P0 — blocks everything | Pending |\\\n| Corner analysis | Track model | 3–5 days | P1 | — |\\\n| Grip envelope | Track model | 2–3 days | P1 | — |\\\n| Theoretical best lap | Lap detection + sectors | 2–3 days | P1 | — |\\\n| Time loss attribution | Corner + grip + theoretical | 3–5 days | P2 | — |\\\n| Coaching output | All of the above | 5–10 days | P2 | — |\\\n\\\n---\\\n\\\n## 18. RaceChrono — Inspiration & Feature Ideas\\\n\\\n> **Added: 2026-06-23**\\\n> **Source:** https://racechrono.com — RaceChrono Oy (Finland), \\\"The #1 app for motorsports\\\"\\\n> **Context:** RaceChrono is the reference real-world lap timer / data logger app (iOS + Android, 100K+ active users, 4.6/5 Play Store). It targets **cars, motorbikes and go-karts** on closed circuits and point-to-point stages. It is the mobile / real-world analog of what racecraft could become on desktop + sim. Its feature set is a directly relevant source of product and UX ideas, especially for the real-world and karting expansion.\\\n\\\n### 18.1 What RaceChrono Is\\\n\\\n- **Platform:** Native iOS + Android app (RaceChrono Pro = paid with video; RaceChrono = free Android lap timer)\\\n- **Audience:** Track-day drivers, karters, motorcyclists, amateur & some professional racers. Explicitly markets go-karts.\\\n- **Founded 2007** (Nokia S60 origin), EU Regional Development Fund backed for \\\"next generation\\\" data processing.\\\n- **Core promise:** Replaces traditional lap timers and data loggers using a phone + cheap external sensors.\\\n\\\n### 18.2 RaceChrono Feature Set — Idea Source\\\n\\\n| RaceChrono Feature | RaceChrono Tier | racecraft Equivalent Today | Actionable Idea for Us |\\\n|---|---|---|---|\\\n| Lap timing with **sectors + optimal lap** | All | Lap detection pending (§17.3) | Ship lap detection + theoretical best lap (already on roadmap §17.7) |\\\n| **Predictive lap timing + delta-time graph** (live, in-session) | Pro | None — we have post-session only | **HIGH PRIORITY.** Live predictive timing + delta trace is the most-wanted cockpit feature. Ties directly to WebSocket streaming (§16.6 A4). |\\\n| **Track library of >2,000 pre-made tracks** | All | We map per-track manually | **The big one.** Validate our \\\"pre-calculated data library\\\" thesis (Architecture §5). A large, community-contributed track library is the real product/moat. Aim for this scale. |\\\n| **Custom user-defined circuit + point-to-point tracks** | All | TrackMapping use case (done) | Our boundary-recording method is MORE accurate than GPS — market this as a quality differentiator. |\\\n| **Synchronised graph + map + video analysis** | Pro | Graph + map done, no video | Add a synchronized video channel for real-world sessions (and sim replay capture). |\\\n| **Video recording with configurable data overlay** (hardware-accelerated export) | Pro | None | Long-term: render telemetry overlay onto dashcam/footage. Big marketing asset. |\\\n| **Multiple cameras + picture-in-picture export** | Pro | None | Defer — nice-to-have for pro tier. |\\\n| **GoPro® remote control + sync** | Pro | None | If we go real-world, GoPro/AI-1/Aim integration matters. |\\\n| **External GPS receivers** (high-rate, 10–50 Hz) | All | n/a (sim) | Core enabler for real-world / karting. Phone GPS is ~1 Hz, too coarse. |\\\n| **Bluetooth + Wi-Fi OBD-II readers** | All/Pro | None | **Sim-to-real bridge.** OBD-II gives RPM, speed, throttle, temps for real cars. Pairs with §16.6 D6. |\\\n| **Bluetooth LE heart-rate monitors** | Pro | None | Novel **biometric driver coaching** angle: correlate HR spikes with corner commitment / mistakes. Unique differentiator nobody does. |\\\n| **DIY data sources & sensors** | Pro | None | Plugin/extension model for custom data feeds — aligns with our feed architecture. |\\\n| **Unlimited session length (24h races)** | All | Ring buffers (limited) | Ensure storage + manifest scale to endurance sessions. |\\\n| **Data export** (.ODS summary, .NMEA, .VBO, .CSV) | Pro | Raw binary + JSONL | Add analysis-result export (CSV/Excel summary) — trivial, high perceived value. |\\\n| **Cross-platform (iOS + Android)** | All | Web/Tauri desktop | A mobile companion app for post-session review is on roadmap (§16.6 D5). RaceChrono shows mobile is the primary real-world surface. |\\\n\\\n### 18.3 Key Strategic Lessons from RaceChrono\\\n\\\n1. **The data library IS the product.** 2,000+ pre-made tracks is their moat. Our §5 \\\"pre-calculated data library\\\" plan is exactly right — prioritize community track-model contribution + a downloadable library early.\\\n2. **Phone-as-sensor + cheap hardware wins the mass market.** RaceChrono never built hardware; it ingests from commodity OBD-II/GPS/HR devices. We should keep a **hardware-agnostic ingestion layer** and never depend on selling our own sensors.\\\n3. **Video + data overlay is the killer marketing feature.** A driver sharing a lap video with a speed/RPM/track overlay is free viral marketing. Plan for it even if we build it late.\\\n4. **Predictive lap timing drives daily engagement.** It's the one feature racers check every single lap. Build it alongside WebSocket streaming.\\\n5. **Real-world + sim from one analysis engine** = our long-term edge. RaceChrono is real-world only and has no sim pipeline; Track Titan is sim only with no real-world. Owning both is wide-open.\\\n6. **Biometrics are an unexplored frontier.** HR-monitor integration for \\\"you braked early every time your heart rate spiked in the braking zone\\\" coaching is genuinely novel.\\\n\\\n### 18.4 Concrete RaceChrono-Inspired Additions to Our Roadmap\\\n\\\n| Idea | Maps To | Priority |\\\n|---|---|---|\\\n| Live predictive lap timing + delta graph | §16.6 A4/A5/A6 (WS + lap detection + reference lap) | P0 |\\\n| Community track-model library (target 100s → 1,000s of tracks) | Architecture §5, §16.6 D1/D2 | P1 |\\\n| Hardware-agnostic ingestion: GPS / OBD-II / external sensor feeds | §16.6 D6, new TelemetryFrame sources | P1 |\\\n| Synchronized video channel + data overlay export | New feature line | P2 |\\\n| CSV / Excel session-summary export | New endpoint | P2 |\\\n| Biometric driver coaching (HR monitor) | New feature line | P3 |\\\n| Mobile companion app (post-session review) | §16.6 D5 | P3 |\\\n\\\n---\\\n\\\n## 19. Karting Market & Styria Karting Partnership\\\n\\\n> **Added: 2026-06-23** (partner verified 2026-06-23)\\\n> **Context:** Karting is a natural and currently underserved adjacent market. It bridges sim and real-world racing, has a passionate enthusiast + amateur-competition audience, and offers a concrete go-to-market path via a **local partner: Styria Karting (Kalsdorf/Zettling, Styria)**.\\\n\\\n### 19.1 Why Karting Fits racecraft\\\n\\\n- **Real-world telemetry gap:** Karts have almost no built-in data acquisition. Enthusiasts and rental/amateur racers rely on phone GPS (1 Hz, inaccurate) or expensive Aim/Unipro displays. This is exactly RaceChrono's sweet spot (§18) — and RaceChrono's mass-market weakness (GPS accuracy) is our potential edge.\\\n- **Bridge between sim and real:** Sim racing-to-karting is a recognized pipeline (many karting schools and sim centers pair them). racecraft could offer **one coaching engine across sim practice and real kart laps**.\\\n- **Lower barrier to hardware:** Karting data sources are simple — wheel speed pickup, engine RPM, optional GPS, optional OBD-II on some 4-stroke karts. Minimal custom hardware needed.\\\n- **Coaching needs are concrete and high-value:** braking consistency, racing line, sector deltas, theoretical best lap, consistency across stints. All are already on our roadmap (§17).\\\n- **Strong community + content loop:** Karters love comparing laps and sharing data (social/leaderboard dynamics) — feeds the data-network flywheel (§5).\\\n\\\n### 19.2 Karting-Specific Features to Consider\\\n\\\n| Feature | Why It Matters for Karting | Our Status |\\\n|---|---|---|\\\n| Theoretical best lap + sector deltas | The #1 thing karters want to improve | §17.7 — planned |\\\n| Racing-line / line-deviation coaching | Margins are tiny in karting; line is everything | §17 corner analysis — planned |\\\n| Consistency scoring across stints | Detect fatigue / setup changes over a session | New metric |\\\n| Grip/surface awareness (outdoor tracks, changing grip) | Outdoor karting grip varies hugely by weather | Real-world surface data needed |\\\n| Lightweight mobile capture (phone + external GPS) | Karters won't bring a laptop trackside | §16.6 D5 mobile companion |\\\n| Lap-by-lap shareable video+overlay | Viral social content at the track | §18 video overlay idea |\\\n| Rental-kart leaderboard by venue | Engages casual/rental drivers, drives acquisition | New community feature |\\\n\\\n### 19.3 Anchor Partner: Styria Karting (VERIFIED)\\\n\\\n> **Partner confirmed:** https://styriakarting.at/ — StyriaKarting, \\\"Ihre Kartstrecken in Graz Umgebung\\\" (Kalsdorf / Zettling, Styria, Austria).\\\n\\\n**Why this is an ideal pilot partner:**\\\n\\\n| Attribute | Detail |\\\n|---|---|\\\n| **Operator** | StyriaKarting (Styria Karting) — regional karting operator, Graz Umgebung |\\\n| **Website** | https://styriakarting.at/ |\\\n| **Locations** | Two sites: **Indoor** (Feldkirchenstraße 30, 8401 Kalsdorf) and **Outdoor** (Industriestraße 39, 8401 Zettling) |\\\n| **Tracks (4 layouts)** | **Outdoor Spielberg** — 380 m, 200 cc 6.5 PS rental karts, +2 kids karts + double-seater. **Outdoor Nordschleife** — 13 PS 390 cc sport karts, ages 16+. **Outdoor Le Mans** — Spielberg + Nordschleife combined = **1,260 m**, 13 PS sport karts. **Indoor** — 290 m covered (with outdoor section), 200 cc 6.5 PS. |\\\n| **Audience breadth** | Families, friends, corporate events, birthdays (casual) AND beginners/amateurs/pros (competitive) — see below |\\\n| **Race program** | \\\"Mindestens 2 Rennen pro Woche\\\" (≥2 races/week); free practice sessions; beginner/amateur/pro categories |\\\n| **Timing infra** | Already publishes **Ergebnisse (results)** on the site → they already run timing/transponder systems (likely MYLAPS-style). This is critical: a data layer already exists we could enrich. |\\\n| **Motorsportclub** | Affiliated **Styria Karting Motorsportclub** (https://styriakarting-motorsportclub.at/) — structured competitive community, ideal coaching cohort |\\\n| **Contact** | office@styriakarting.at (outdoor) / indoor@styriakarting.at; outdoor +43 3135 56 8 76 / indoor +43 3135 57 890 |\\\n| **Season** | Outdoor Mar–Oct; Indoor year-round (14:00–22:00 wk / 11:00–22:00 wknd) |\\\n| **Why it fits** | Local → low-friction, in-person testing; multi-layout venue (small rental → full 1.2 km sport kart) lets us validate across difficulty levels; existing timing + a motorsport club give us a ready user base and a baseline to compare our analysis against |\\\n\\\n### 19.4 Proposed Styria Karting Pilot — Concept\\\n\\\n| Aspect | Proposal |\\\n|---|---|\\\n| **Partner** | Styria Karting (Kalsdorf/Zettling, Styria) |\\\n| **What they provide** | Real karting track(s) for data capture + track modelling; access to drivers/sessions (motorsport club members); venue as distribution channel; existing timing data to validate against |\\\n| **What we provide** | Free pilot of racecraft analysis for their drivers; venue-branded leaderboards; coaching reports; **TrackModels of all 4 layouts** (esp. the 1,260 m Le Mans layout); CSV/post-session summaries |\\\n| **Pilot scope** | 1 track first (recommend Le Mans — longest, most corners, best coaching value), ~10–20 motorsport-club drivers over 2–4 sessions; capture real telemetry (external GPS + engine RPM), build TrackModels, validate coaching output vs. venue's published lap times |\\\n| **Validation goals** | (1) Can we capture usable karting data with cheap hardware? (2) Do drivers find the coaching actionable vs. their own feel? (3) Does a venue-branded leaderboard drive engagement/acquisition? (4) Do our theoretical-best-lap / sector deltas align with their existing timing? |\\\n| **Commercial model (if pilot succeeds)** | Revenue share or per-venue license; white-label \\\"powered by racecraft\\\" on the venue site; freemium for individual drivers with upsell (coaching reports, video overlay) |\\\n| **Differentiator to pitch** | Their current timing = lap times only. We add **line, braking, consistency, theoretical best lap** — the analysis layer their timing system lacks. Cheap (phone + 10 Hz GPS) vs. Aim/Unipro gear. |\\\n\\\n### 19.5 Immediate Next Steps — Karting Track\\\n\\\n1. **Reach out to Styria Karting** — contact via office@styriakarting.at; pitch the free pilot + venue-branded leaderboard (no hardware cost to them). Lead with the motorsport club cohort.\\\n2. **Define karting data capture MVP** — minimum viable source: external 10 Hz GPS + engine RPM pickup. Decide phone-based capture (RaceChrono-style, §18) vs. small logger. Note the Indoor track is covered — GPS may be unreliable there; prioritize Outdoor (Spielberg/Nordschleife/Le Mans).\\\n3. **Build TrackModels for the 4 layouts** — once access is granted, run our boundary-recording method on each layout (esp. Le Mans 1,260 m). This also seeds our community track library (§18.4).\\\n4. **Draft a one-page pilot proposal** (free pilot → data + leaderboards → revenue share) tailored to their race nights.\\\n5. **Add karting** as a tracked segment in the product roadmap (§16.6) — likely a Phase B/C initiative alongside rally.\\\n6. **Investigate their timing system** — confirm what transponder/timing they use (results page implies MYLAPS/AMB-style) so we can integrate/compare rather than duplicate.\\\n\\\n---\\\n\\\n*Last updated: 2026-06-24 — v0.7.0 (rusty-telemetry) + v0.1.5 (racecraft): Session persistence (split metadata/frames, lazy load, atomic writes, off-thread serialization), car characteristics DB (`characteristics.rs`, 2 API endpoints), removed obsolete `track_map` use case, CharacteristicsView + CharacteristicsView, TracksView/TrackDetailView committed, auto-analyze before build track model, READMEs + AGENTS.md updated. Updated §8, §9 (1.12), §15, §16.1, §16.6, §16.10, §17.2.*\\\n*Next: verify with live AC session, add lap detection, purchase DiRT Rally 2.0, contact Styria Karting for pilot\"],[1,\"Status** | **v0.7.1 — Car grip analysis use case (envelope extraction)** |\\\n| **API Reference** | [rusty-telemetry — REST API Reference](joplin://0c837f4e6b7e462a997cbc19e47c864a) |\\\n\\\n### Repo: `racecraft` (Vue.js Web Client)\\\n\\\n| Field | Value |\\\n|---|---|\\\n| **Status** | **v0.1.6 — GripAnalysisView (grip envelope, grip circle, steering response)** |\\\n| **Client Notes** | [racecraft — Vue.js Web Client Notes](joplin://50a09627d5d347009197b94bcee90411) |\\\n\\\n---\\\n\\\n## 9. Implementation Phases\\\n\\\n*(Phases 1.0–1.12 unchanged — see note history for details)*\\\n\\\n- **1.13 Car Grip Analysis — IMPLEMENTED 2026-06-24 (both repos)**\\\n  - [x] **New `UseCase::CarGrip` variant** — race-pace grip characterization via envelope extraction\\\n    - Guidance: \\\"Drive 3–5 laps at race pace. Brake hard, carry speed through corners...\\\"\\\n    - No special driving protocols needed — the harder you push, the more complete the profile\\\n  - [x] **`analyze_car_grip()`** in `analysis.rs`:\\\n    - Speed-binned envelope: 10 km/h bins, peak |lateral G|, peak accel G, peak brake G per bin\\\n    - Grip circle scatter: (longitudinal_g, lateral_g) downsampled to ~800 points\\\n    - Steering response scatter: (steer, lateral_g, speed_kmh) downsampled to ~800 points\\\n    - Summary: max lateral/accel/brake/combined G, peak lateral speed\\\n    - Filters: excludes pit frames and speed < 5 km/h\\\n  - [x] **racecraft: GripAnalysisView** (`/analysis/grip/:id`) with 4 charts:\\\n    1. Grip Envelope (peak G vs speed — lateral/accel/brake lines)\\\n    2. Grip Circle (longitudinal G vs lateral G scatter — friction circle)\\\n    3. Cornering Grip vs Speed (peak lateral G vs speed)\\\n    4. Steering Response (steer angle vs lateral G scatter)\\\n  - [x] SessionDetailView: grip analysis quick stats (4 stat cards) + view button\\\n  - [x] `car_grip` added to UseCase type, `CarGripAnalysis` types, `isCarGripAnalysis` type guard\\\n  - [x] Global `.grid-4` CSS utility added\\\n  - [x] Documentation updated: READMEs (both repos), Joplin notes\\\n  - [ ] Add grip analysis unit tests\\\n  - [ ] Extend car characteristics to include grip data (currently shift-points only)\\\n  - [ ] Add slip-angle-based understeer detection (per-wheel slip_angle data available)\\\n\\\n---\\\n\\\n## 15. Change Log\\\n\\\n### Recent Changes (summary)\\\n\\\n| Version | Date | Highlights |\\\n|---------|------|------------|\\\n| rusty-telemetry v0.7.1 | 2026-06-24 | Car grip analysis use case: `analyze_car_grip()` with envelope extraction (speed-binned peak G), grip circle scatter, steering response scatter |\\\n| racecraft v0.1.6 | 2026-06-24 | GripAnalysisView with 4 charts (grip envelope, grip circle, cornering grip vs speed, steering response), grip analysis types, SessionDetailView grip stats |\\\n| rusty-telemetry v0.7.0 | 2026-06-24 | Session persistence, car characteristics DB, remove `track_map` use case |\\\n| racecraft v0.1.5 | 2026-06-24 | CharacteristicsView, tracks views committed, track_map removal |\\\n| *(earlier versions — see note history)* | | |\\\n\\\n---\\\n\\\n## 17.6 Grip Envelope\\\n\\\n**Status (2026-06-24): Basic version IMPLEMENTED (car_grip use case).**\\\n\\\nFrom race-pace laps: peak lateral G, peak accel G, peak brake G, binned by speed (envelope extraction). Produces the \\\"grip circle\\\" boundary. Used for coaching: \\\"car can do 1.4g, you used only 1.1g\\\".\\\n\\\nImplemented via `car_grip` use case with `analyze_car_grip()`:\\\n- Speed-binned envelope (10 km/h bins, max |G| per bin)\\\n- Grip circle scatter (longitudinal vs lateral G)\\\n- Steering response scatter (steer angle vs lateral G)\\\n- Summary stats (max lateral/accel/brake/combined G)\\\n\\\nNext steps: per-wheel slip angle understeer detection, extend characteristics DB with grip data, future structured trials (e.g. slowly rising steering angle to detect slip onset).\\\n\\\n---\\\n\\\n## 17.10 Implementation Priority\\\n\\\n| Use Case | Depends On | Estimated Effort | Priority | Status |\\\n|----------|-----------|-----------------|----------|--------|\\\n| Track mapping | Spline data / position data | 3–5 days | P0 | ✅ DONE |\\\n| **Grip envelope** | Telemetry G-force data | 2–3 days | P1 | ✅ Basic DONE (car_grip use case — envelope extraction) |\\\n| Lap detection | Spline data in TT feed | 1–2 days | P0 | Pending |\\\n| Corner analysis | Track model + lap detection | 3–5 days | P1 | — |\\\n| Theoretical best lap | Lap detection + sectors | 2–3 days | P1 | — |\\\n| Time loss attribution | Corner + grip + theoretical | 3–5 days | P2 | — |\\\n| Coaching output | All of the above | 5–10 days | P2 | — |\\\n\\\n---\\\n\\\n*(Sections 10–14, 16, 18, 19 unchanged — see note history for full content)*\\\n\\\n---\\\n\\\n*Last updated: 2026-06-24 — v0.7.1 (rusty-telemetry) + v0.1.6 (racecraft): Car grip analysis use case with envelope extraction — `analyze_car_grip()` produces speed-binned peak G, grip circle scatter, steering response scatter. New GripAnalysisView with 4 charts. Updated §8, §9 (1.13), §15, §17.6, §17.10.*\\\n*Next: test car_grip with live AC session tonight, add lap detection, extend characteristics with grip data, add understeer detection from slip angles\"],[0,\".*\"]],\"start1\":221,\"start2\":221,\"length1\":47175,\"length2\":4960}]"
metadata_diff: {"new":{},"deleted":[]}
encryption_cipher_text: 
encryption_applied: 0
updated_time: 2026-06-24T08:27:24.457Z
created_time: 2026-06-24T08:27:24.457Z
type_: 13