id: 132356b6dfee4d2abdb5a7c6b328e375
parent_id: 
item_type: 1
item_id: 6c0dcb2a567348fd9796f50c790082e4
item_updated_time: 1780311158021
title_diff: "[{\"diffs\":[[1,\"Sim Racing Telemetry Analysis Platform — Project Plan\"]],\"start1\":0,\"start2\":0,\"length1\":0,\"length2\":53}]"
body_diff: "[{\"diffs\":[[1,\"# Sim Racing Telemetry Analysis Platform\\\n\\\n> Conversation research notes and project plan for a cross-platform telemetry system for sim racing on Linux.\\\n\\\n---\\\n\\\n## 1. Telemetry APIs — Key Findings\\\n\\\n### Assetto Corsa (Classic)\\\n- **Primary method**: Shared Memory (Windows)\\\n- **Cross-platform option**: **Lua plugin API** — runs inside the game process, works under Proton/Linux\\\n- The Lua API (`ac.getCarState()`, `ac.getSessionState()`, `ac.getPhysics()`) exposes nearly all telemetry data that shared memory provides\\\n- Missing: some high-frequency raw physics vectors (1000Hz), but Lua provides filtered values suitable for analysis\\\n- Native UDP output also exists but may need format parsing\\\n\\\n### Assetto Corsa Evo\\\n- Uses shared memory like classic AC, but **reworked in v0.6**\\\n- Structure similar to ACC but initially only the physics file was populated\\\n- **Official Shared Memory API Documentation released May 15, 2026**\\\n- Lua SDK still in development — will follow same pattern as classic AC\\\n- Verdict: Don't buy ACC yet; invest in EVO for the future\\\n\\\n### Assetto Corsa Competizione (ACC)\\\n- Shared memory only (Windows)\\\n- Would require a relay tool (e.g., `ACC_ShmemUDP_Relay`) to send data via UDP from Windows — adds complexity\\\n- **Decision: Skip for now, focus on EVO instead**\\\n\\\n### Assetto Corsa Rally\\\n- Shared memory (SimHub support confirmed in v9.10.7)\\\n- No native UDP confirmed\\\n- Coaching value: **High** — detailed tire and surface data\\\n\\\n### Dirt Rally 2.0\\\n- **Well-documented UDP telemetry output** — the clear choice for Linux\\\n- UDP Frequency configurable (5–60 Hz)\\\n- Community tools exist (e.g., `dr2_logger`)\\\n- Coaching value: **High** — pace note timing, braking points per surface, suspension behavior\\\n\\\n### Dirt Rally 1.0\\\n- Same Codemasters engine as DR2.0, UDP support probable\\\n- Coaching value: **High**\\\n\\\n### Dirt 4\\\n- Older, official UDP support less clear\\\n- Coaching value: **Medium**\\\n\\\n### Project CARS 1 & 2\\\n- **UDP feed is the only viable method on Linux**\\\n- Shared memory is Windows-only (memory-mapped files), not accessible even under Proton\\\n- **No plugin API available** (unlike AC)\\\n- Well-documented binary UDP packet structure\\\n- Config: UDP Protocol Version set to \\\"Project Cars 1\\\" recommended\\\n\\\n---\\\n\\\n## 2. Why Shared Memory over UDP?\\\n\\\nTelemetry tools prefer shared memory for local access because:\\\n\\\n| Advantage | Shared Memory | UDP |\\\n|---|---|---|\\\n| Latency | Nanoseconds | Milliseconds |\\\n| Throughput | Direct memory access | Network stack overhead |\\\n| Multiple consumers | One-write, many-read (zero extra cost) | Separate stream per consumer |\\\n| Data copies | None | Serialization/deserialization |\\\n| Synchronization | Lock-lock-free circular buffers | Packet sequencing, loss handling |\\\n| Scope | Local machine only | Network-transparent |\\\n\\\n**Bottom line**: For multiple local tools (SimHub, CrewChief, dashboards), shared memory is far more efficient. UDP is the fallback for Linux/networked setups.\\\n\\\n---\\\n\\\n## 3. Why the Lua Plugin Approach (Not Shared Memory Executable)\\\n\\\n- Shared memory bridge executables are **Windows-only** — won't work natively on Linux\\\n- A **Lua plugin runs inside the game process** under Proton, so it works cross-platform\\\n- The Lua API provides 95%+ of the data shared memory offers\\\n- This is the clean Linux-native path\\\n\\\n### Starting Point: `ac-tracer` by Tobi\\\n- CSP Lua-based application for driver input telemetry\\\n- Can be forked and adapted — proven data reading and processing pipeline\\\n- High-frequency data capture suitable for coaching\\\n- Provides patterns for: data reading, signal processing, real-time analysis, in-game UI\\\n- **Main modification needed**: Add UDP output module (serialize data + send via socket)\\\n\\\n---\\\n\\\n## 4. Architecture — Independent Machine Deployment\\\n\\\nPlugins run on the game machines; the Rust receiver runs on a separate analysis machine. DR2 has native UDP output — no code needed on the DR2 machine.\\\n\\\n```\\\nGame Machine (AC / Proton)                Analysis Machine\\\n┌──────────────────────────┐              ┌─────────────────────────────────────┐\\\n│  ac-telemetry-plugin     │              │  rusty-telemetry                    │\\\n│  (Lua plugin inside AC)  │──UDP :5005──→│                                     │\\\n│  Reads ac.* API, sends   │   JSON       │  ┌───────────┐  ┌────────────────┐ │\\\n│  JSON over network       │              │  │ Receiver  │→ │ Parser-AC      │ │\\\n└──────────────────────────┘              │  │ (multi-   │  │ (JSON → model) │ │\\\n                                          │  │  port UDP)│  ├────────────────┤ │\\\n                                          │  │           │→ │ Parser-DR2     │ │\\\nGame Machine (DR2 / native)               │  │           │  │ (binary→model) │ │\\\n┌──────────────────────────┐              │  └───────────┘  └───────┬────────┘ │\\\n│  Dirt Rally 2.0          │──UDP────────→│                         │          │\\\n│  (native UDP output,     │  Binary      │  ┌──────────────┐  ┌───▼────────┐ │\\\n│   no plugin needed)      │              │  │ Storage      │  │ Analyzer   │ │\\\n└──────────────────────────┘              │  │ (SQLite)     │←─│ Engine     │ │\\\n                                          │  └──────────────┘  └────────────┘ │\\\n                                          │  ┌──────────────┐  ┌────────────┐ │\\\n                                          │  │ REST + WS    │  │ Web        │ │\\\n                                          │  │ API (Axum)   │→ │ Dashboard  │ │\\\n                                          │  └──────────────┘  └────────────┘ │\\\n                                          │  ┌──────────────┐                  │\\\n                                          │  │ AI Coach     │                  │\\\n                                          │  │ (GLM-5.1)    │                  │\\\n                                          │  └──────────────┘                  │\\\n                                          └─────────────────────────────────────┘\\\n```\\\n\\\n---\\\n\\\n## 5. Repositories\\\n\\\n### Repo 1: `ac-telemetry-plugin` (AC Lua Plugin)\\\n\\\n| Field | Value |\\\n|---|---|\\\n| **Language** | Lua (LuaJIT) |\\\n| **IDE** | IntelliJ IDEA + EmmyLua plugin |\\\n| **Local path** | `~/IdeaProjects/ac-telemetry-plugin` |\\\n| **Remote** | `git@<host>:sim-racing/ac-telemetry-plugin.git` |\\\n| **Runs on** | Game machine (inside AC / Proton) |\\\n| **Dependencies** | LuaSocket (bundled with AC), dkjson or Protobuf |\\\n| **Starting point** | Fork of `ac-tracer` by Tobi on GitHub |\\\n\\\n**Components**: Reads telemetry via `ac.*` API, serializes to JSON, sends via UDP to the analysis machine.\\\n\\\n### Repo 2: `rusty-telemetry` (Main Rust Backend)\\\n\\\n| Field | Value |\\\n|---|---|\\\n| **Language** | Rust |\\\n| **IDE** | RustRover |\\\n| **Local path** | `~/RustroverProjects/rusty-telemetry` |\\\n| **Remote** | `git@<host>:sim-racing/rusty-telemetry.git` |\\\n| **Runs on** | Analysis machine (independent from game machines) |\\\n| **Stack** | Tokio (async), Serde (JSON), SQLx + SQLite (storage), Axum (API), Yew/Leptos (frontend) |\\\n\\\n**Components**: Multi-source UDP receiver, game-specific parsers (AC JSON, DR2 binary), SQLite storage, REST/WebSocket API, web dashboard, AI coaching integration.\\\n\\\n#### Cargo Workspace Layout\\\n\\\n```\\\nrusty-telemetry/\\\n├── Cargo.toml                    (workspace root)\\\n├── crates/\\\n│   ├── core/                     (shared types, traits, config)\\\n│   ├── receiver/                 (multi-port UDP listener)\\\n│   ├── parser-ac/                (AC JSON → generic telemetry model)\\\n│   ├── parser-dr2/               (DR2 binary → generic telemetry model)\\\n│   ├── storage/                  (SQLite persistence, migrations)\\\n│   ├── analyzer/                 (derived metrics, lap comparison, track mapping)\\\n│   ├── api/                      (REST + WebSocket server, Axum)\\\n│   └── web/                      (frontend — Yew/Leptos or static SPA)\\\n├── bin/\\\n│   └── rusty-telemetry.rs        (main binary, wires crates together)\\\n├── migrations/                   (SQLx migrations)\\\n└── config/                       (default config files)\\\n```\\\n\\\nEach parser implements a common `TelemetryParser` trait from `core`. Adding a new game is `cargo new crates/parser-evo` + implement the trait.\\\n\\\n### Why 2 Repos (Not 3)\\\n\\\nThe original plan had a third repo for the DR2 listener. That was folded into `rusty-telemetry` because:\\\n- DR2 has **native UDP output** — no code runs on the DR2 machine\\\n- The DR2 parser is a module (~200–400 lines), not an independent service\\\n- It shares the same UDP listener infrastructure and data model\\\n- One `cargo test` / `cargo build` covers everything\\\n\\\nA third repo would only be needed if a game requires a **relay process on the game machine** (e.g., ACC shared-memory-to-UDP bridge on Windows). That would be `rusty-acc-relay`, but YAGNI until ACC is actually added.\\\n\\\n---\\\n\\\n## 6. Data Format — JSON Schema (Phase 1)\\\n\\\nFrom Lua plugin → Rust listener on port 5005:\\\n\\\n```json\\\n{\\\n  \\\"timestamp\\\": 1716123456.789,\\\n  \\\"speed_kmh\\\": 245.3,\\\n  \\\"rpm\\\": 8750,\\\n  \\\"gear\\\": 6,\\\n  \\\"throttle\\\": 0.85,\\\n  \\\"brake\\\": 0.0,\\\n  \\\"steering\\\": 0.12,\\\n  \\\"g_forces\\\": { \\\"x\\\": 0.5, \\\"y\\\": -0.2, \\\"z\\\": 1.0 },\\\n  \\\"wheel_slip\\\": [0.1, 0.1, 0.0, 0.0],\\\n  \\\"suspension_travel\\\": [0.15, 0.14, 0.16, 0.15],\\\n  \\\"lap_time\\\": 85.234,\\\n  \\\"lap_count\\\": 5\\\n}\\\n```\\\n\\\nFuture: Migrate to **Protocol Buffers** for efficiency. Define a generic `.proto` schema with common fields + `oneof` for game-specific extensions.\\\n\\\n---\\\n\\\n## 7. Implementation Phases\\\n\\\n### Phase 1: Core Infrastructure (Weeks 1–6)\\\n- **1.1** AC Lua Plugin prototype (IntelliJ + EmmyLua)\\\n  - Set up project, implement shared memory reader via `ac.getCarState()`\\\n  - Create UDP sender module with JSON encoding\\\n  - Test with simple Rust listener\\\n  - Target: 60Hz+ data frequency\\\n- **1.2** `rusty-telemetry` workspace skeleton (RustRover)\\\n  - Create Cargo workspace with `core`, `receiver`, `parser-ac` crates\\\n  - Multi-port UDP listener (port 5005 for AC, separate port for DR2)\\\n  - SQLite database with migrations\\\n  - Basic REST API endpoints\\\n- **1.3** DR2.0 parser crate\\\n  - Add `parser-dr2` crate to workspace\\\n  - Analyze DR2.0 UDP packet structure, implement binary parser\\\n  - Map to generic telemetry model\\\n\\\n### Phase 2: Data Analysis & Storage (Weeks 7–12)\\\n- Derived metrics: G-forces, slip ratios, derivatives (jerk, slip angle)\\\n- Data decimation strategy (full data for 5 min, then 1-second averages)\\\n- Session/lap management and comparison\\\n- Track mapping and sector analysis\\\n- Export: CSV, MoTeC compatible format\\\n\\\n### Phase 3: Web Visualization (Weeks 13–18)\\\n- Real-time telemetry dashboard\\\n- Lap comparison overlays (trace overlay — reference lap vs user)\\\n- Track map with position trail\\\n- Time-distance plots, histograms\\\n- Driver input dashboard: steering vs G-force, throttle/brake trace\\\n\\\n### Phase 4: AI Coaching with GLM-5.1 (Weeks 19–24)\\\n- Feature extraction from telemetry patterns\\\n- Structured prompts with relevant data excerpts\\\n- GLM-5.1 API integration with function calling for structured coaching\\\n- Coaching tips displayed in web interface\\\n- Reference lap upload & correlation\\\n\\\n---\\\n\\\n## 8. Development Tools\\\n\\\n| Component | IDE | Project Path | AI Assistant |\\\n|---|---|---|---|\\\n| `ac-telemetry-plugin` | IntelliJ IDEA + EmmyLua | `~/IdeaProjects/ac-telemetry-plugin` | Kilo Code + GLM 5.1 |\\\n| `rusty-telemetry` | RustRover | `~/RustroverProjects/rusty-telemetry` | Kilo Code + GLM 5.1 |\\\n| Web UI (within `rusty-telemetry`) | RustRover | `~/RustroverProjects/rusty-telemetry/crates/web` | Kilo Code + GLM 5.1 |\\\n\\\n### Kilo Code Prompt Patterns\\\n- **Architect Mode**: Design schemas, data flow, Protobuf definitions\\\n- **Code Mode**: Generate boilerplate (UDP listener, Lua plugin structure, parsers)\\\n- **Debug Mode**: Analyze errors from Rust compiler or Lua runtime\\\n\\\n---\\\n\\\n## 9. Rally Game Telemetry — Why It Matters\\\n\\\nRally telemetry is arguably **more valuable** than circuit racing because:\\\n- **Surface adaptation**: Analyze input changes between tarmac, gravel, snow\\\n- **Pace note correlation**: Overlay braking points with pace notes — are you braking too early/late?\\\n- **Technique breakdown**: Scandinavian flick — precise sequence of steering, braking, throttle\\\n- **Consistency under pressure**: Compare multiple runs on same stage\\\n- **Car setup validation**: Differential, suspension, gear settings vs grip/stability\\\n\\\n---\\\n\\\n## 10. Key References\\\n\\\n- AC Shared Memory API Documentation\\\n- `acevo-shared-memory` Rust crate (struct definitions for EVO shared memory layout)\\\n- `ac-tracer` by Tobi on GitHub (CSP Lua telemetry app — starting point for plugin)\\\n- `acc-lua-sdk` on GitHub (Lua API reference)\\\n- Open Sim Relay (OpenSR) — architectural reference for plugin/relay pattern\\\n- DR2.0 UDP packet structure (official sharedmemory.h definition)\\\n- SimHub (reference for multi-game telemetry integration)\\\n- GLM-5.1 API for AI coaching\\\n\\\n---\\\n\\\n## 11. Success Metrics\\\n\\\n| Metric | Target |\\\n|---|---|\\\n| Data capture rate | 95%+ frames at 60Hz |\\\n| Storage efficiency | <1MB/min after decimation |\\\n| API response time | <200ms for historical queries |\\\n| AI coaching relevance | 70%+ useful suggestions |\\\n| Cross-game compatibility | 3+ games supported |\\\n\\\n---\\\n\\\n## 12. Game Support Priority\\\n\\\n| Priority | Game | Method | Status |\\\n|---|---|---|---|\\\n| 1 | Assetto Corsa (classic) | Lua Plugin → UDP | Phase 1 |\\\n| 2 | Dirt Rally 2.0 | Native UDP | Phase 1 |\\\n| 3 | Assetto Corsa Evo | Lua Plugin (when SDK ready) | Future |\\\n| 4 | Assetto Corsa Rally | Shared memory / SimHub ref | Future |\\\n| 5 | Dirt Rally 1.0 | UDP (same as DR2) | Future |\\\n| 6 | Project CARS 2 | UDP | Future |\\\n| 7 | ACC | Relay tool (if needed) | Low priority |\\\n\\\n---\\\n\\\n*Last updated: 2026-06-01*\\\n*Source: Research conversation on sim racing telemetry APIs and system design*\"]],\"start1\":0,\"start2\":0,\"length1\":0,\"length2\":13563}]"
metadata_diff: {"new":{"id":"6c0dcb2a567348fd9796f50c790082e4","parent_id":"0e8e00b432a840628faa4df5bc2068bc","latitude":"0.00000000","longitude":"0.00000000","altitude":"0.0000","author":"","source_url":"","is_todo":0,"todo_due":0,"todo_completed":0,"source":"joplin-desktop","source_application":"net.cozic.joplin-desktop","application_data":"","order":1780246628879,"markup_language":1,"is_shared":0,"share_id":"","conflict_original_id":"","master_key_id":"","user_data":"","deleted_time":0},"deleted":[]}
encryption_cipher_text: 
encryption_applied: 0
updated_time: 2026-06-01T10:57:41.463Z
created_time: 2026-06-01T10:57:41.463Z
type_: 13