diff --git a/docs/impl/reports/Z27AG-CAN-PRIOR-ART.md b/docs/impl/reports/Z27AG-CAN-PRIOR-ART.md new file mode 100644 index 0000000..99198cb --- /dev/null +++ b/docs/impl/reports/Z27AG-CAN-PRIOR-ART.md @@ -0,0 +1,84 @@ +--- +type: report +date: 2026-10-09 +--- +# Z27AG CAN: prior art and a first look + +What exists publicly for decoding a Mitsubishi of this age, and what the first +10 s capture already shows. The input to Phase 2: not inventing what someone has +already published. + +## Short version + +- **Nothing public decodes the Z27 Colt's broadcast frames.** No DBC, no ID list, + for the Colt, Colt Ralliart, CZT or Version-R. The broadcast IDs have to be + reverse-engineered against our own recordings. +- **Diagnostic requests are well covered.** Mitsubishi's MUT-III protocol is + KWP2000 over ISO 15765 (`0x21 ` "mode 21" requests), and OBDb publishes + open, machine-readable definitions for many Mitsubishi ECUs. Those are the fast + path to named signals, and the ground truth for decoding the broadcast ones. +- **Standard OBD-II mode 01** (RPM 0x0C, speed 0x0D, coolant 0x05, …) works on any + car of this age and is what `obd-poller` should start with — all nine signals in + `schema/signals.json` are mode 01 PIDs. + +## Sources + +### Broadcast frames + +| Source | What it has | Use to us | +|---|---|---| +| [ECUMASTER ADU application note, Evo X](https://www.ecumaster.cz/download/evoX.pdf) | Evo X OBD port at 500 kbps, pins 6/14, no terminator; a channel list (rpm, speed, tps, clt, wheel speeds, indicators, lights, gear) but the IDs only inside their `.canx` file | Same bus conventions as ours; no IDs | +| [EvolutionM "Evo X real CAN packets"](https://www.evolutionm.net/forums/evo-x-engine-management-tuning-forums/552550-evo-x-real-can-packets.html) (forum, blocks automated fetch) | Evo X: RPM in `0x308` bytes 1–2; throttle in `0x210` bytes 0–1 | `0x210` exists on our bus too, but with a **different layout** (6 bytes; the RPM-like value is in bytes 4–5). Evo X IDs do not transfer | +| [awesome-automotive-can-id](https://github.com/iDoka/awesome-automotive-can-id) | Index of public CAN ID collections; Mitsubishi: Lancer 2008 ([habr, RU](https://habr.com/ru/post/448658/)), i-MiEV | Lancer article covers diagnostics, not broadcast (below) | + +The Z27 Colt is a 2002 platform shared with the smart forfour (W454). If any +broadcast matrix carries over it is more likely from that side than from the Evo +X — a direction to look in, not a finding. No forfour ID list turned up either. + +### Diagnostic requests + +| Source | What it has | +|---|---| +| [OBDb/Mitsubishi](https://github.com/OBDb/Mitsubishi) (CC BY-SA 4.0) | Make-level signal set: request header, response header, request, bit position, scaling. E.g. combination meter `6A0`→`514`: `21 A3` fuel level (byte 2, −16, %), `21 AD` odometer (24 bit, km), `21 AF` dashboard voltage (÷10, V). A/C `688`→`511`: `21 13` engine RPM and vehicle speed. TPMS `600`/`773` | +| [OBDb/Mitsubishi-Lancer](https://github.com/OBDb/Mitsubishi-Lancer) and others | Per-model overrides; the Lancer one is empty. No Colt repo | +| [habr 448658](https://habr.com/ru/post/448658/), Lancer X 2008 | MUT-III over CAN: ESP `21 02` → steering angle, bytes 2–3, int16 × 0.04375 °; security access `27 01` / `27 02` gates writes, not reads | +| [EvoScan](https://evoscan.com/) | Commercial logger with MUT-III support for the EU Colt CZT / Ralliart (4G15T). Its parameter definitions are the most complete source for engine mode-21 requests on our exact engine; not open | +| [EcuTek Colt suite](https://www.tpwengineering.com/products/ecutek-vehicle-tuning-mitsubishi-colt) | Confirms the 2005+ EU Colt CZT / Ralliart ECU speaks CAN for flashing; nothing published | + +OBDb's definitions are from newer Mitsubishis (roughly 2008 on). Whether the Z27's +meter and A/C units answer at the same addresses is a question one listen-only +look at the bus during a MUT-III session — or one careful request — would settle. + +## What the first capture shows + +`z27ag-20261009-163736-ign.log`: engine idling, parked, a light touch of +throttle around t ≈ 4–5 s. 27 periodic IDs, ~893 frames/s. Every observation +below is a candidate until checked against OBD-II mode 01 in the same recording. + +| ID | Period | Candidate | +|---|---|---| +| `210` | 20 ms | **Engine speed**: bytes 4–5, big-endian, 1 rpm/bit — ~845 at idle, rising to ~900 with the throttle blip and back | +| `13D` | 20 ms | **Engine speed again**: bytes 0–1, little-endian, ≈ 2× `210`'s value (0.5 rpm/bit?) — moves in lockstep with it | +| `312` | 20 ms | Four 16-bit big-endian words near 0x07B0–0x0940, all noisy, two follow the blip. Sensor values; load or pressure, not wheel speed (parked) | +| `449` | 200 ms | Bytes 0, 1, 3 = 0x6F, 0x5F, 0x71: with the usual −40 offset, 71, 55, 73 °C — temperatures of a warm engine | +| `0C0` | 10 ms | Byte 4 low nibble a 4-bit rolling counter; high nibble looks like a checksum | +| `119`, `149`, `156` | 20 ms | Byte 6 low nibble a rolling counter, byte 7 a checksum (neither plain sum nor XOR) | +| `149` | 20 ms | Bytes 0 and 4 noisy around a centre: an inertial sensor (yaw / lateral g) is the usual owner of such a frame | +| `710`–`713` | 200 ms | Slow, mostly constant: body/meter status | + +Counters and checksums matter only for transmitting, which is out of scope. The +decoder ignores those bits. + +## What would move Phase 2 fastest + +1. **Record mode 01 alongside the broadcast.** One `obd-poller` session polling + RPM, speed, coolant and throttle at ~2 Hz confirms or kills the `210` / `13D` / + `449` candidates in an afternoon. +2. **Try OBDb's meter and A/C requests** (`6A0`, `688`) once. If the Z27 answers, + fuel level and odometer come for free — neither is easy to find in broadcast. +3. **A drive with GNSS and marks.** Speed against GNSS speed finds the wheel-speed + frame; marked indicators, lights and brake find the body frames. + +Steps 1 and 2 transmit, so they wait for the deliberate move of `can_pcan` out of +listen-only (svc-core's initial plan). Step 3 needs only the recorder, which is +running on the car unit.