mikkeli
32d5df87ab
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013kj58Jugkic783b8ZrtTVZ
38 lines
1.6 KiB
Markdown
38 lines
1.6 KiB
Markdown
---
|
|
type: default
|
|
---
|
|
# Initial plan
|
|
|
|
## What actually needs building
|
|
|
|
| Need | Answer | Ours? |
|
|
|---|---|---|
|
|
| A CAN bus that isn't a car | `vcan` — kernel module, no bitrate to configure | No |
|
|
| Replay real captures | `canplayer`, with frame mapping so a log recorded on `can1` plays onto `vcan0` | No |
|
|
| Traffic before any capture exists | **ICSim** — simulated cluster with speed, doors, indicators | No |
|
|
| GNSS fix | GPX or synthetic track → `yukart/gnss/fix` | **Yes**, small |
|
|
| Local broker | a mosquitto config for the workstation | Trivial |
|
|
| App boundary peer | only if the full stack proves too heavy for Flutter iteration | **Deferred** |
|
|
|
|
Two of the three fixtures are configuration, not code.
|
|
|
|
## Why ICSim matters more than it looks
|
|
|
|
Phase 2 is the hard part of this project: correlating observed frames against a
|
|
written event log to work out what the Z27AG is saying. ICSim is built for exactly
|
|
that exercise — a simulated cluster with controllable speed, doors and indicators,
|
|
and four noise levels where level 0 is clean packets and level 3 randomises
|
|
arbitration IDs and byte positions.
|
|
|
|
So the whole decode workflow can be practised, and the decoder written and tested,
|
|
before a single real capture exists. That is worth doing while the PCBs are
|
|
unassembled.
|
|
|
|
## Order
|
|
|
|
1. `vcan` bring-up script — everything else needs a bus.
|
|
2. ICSim, vendored or documented, driving `vcan0`.
|
|
3. GNSS fixture publishing `yukart/gnss/fix`.
|
|
4. Local mosquitto config, and a single entry point that brings the whole fake car up.
|
|
5. `canplayer` wrappers — only useful once Phase 1 has produced real captures.
|