- **Diagnostic requests are well covered.** Mitsubishi's MUT-III protocol is
KWP2000 over ISO 15765 (`0x21 <local id>` "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) |
| [billyjack2/CAN-DBC-Collection](https://github.com/billyjack2/CAN-DBC-Collection) `MITSUBISHI/COLT/can1v3.dbc` | AiM logger driver "Mitsubishi Colt" as a DBC: wheel speeds `200`/`208`, pedal `210` byte 2, brake switch `300`, rpm `308`, speed and fuel `412`, battery `416`, coolant `608` | The EU Colt / forfour engine-side set (it matches the forfour notes below), **not the Z27's**: of its IDs only `210` and `300` exist here, and neither fits — `210` byte 2 stays `08` through a throttle blip while bytes 4–5 follow rpm; `300` is 4 bytes, not 8 |
| [I2000C/SmartCruiseControl](https://github.com/I2000C/SmartCruiseControl) `doc/CAN bus reverse engineering.md` (MIT) | Smart forfour 454, 2006, **1.5 CDI diesel**, sniffed: ~30 IDs with lengths and byte notes. Decoded: `09E` odometer (bytes 4–6, 0.1 km), `200` handbrake + three speeds (×0.05 km/h, big-endian), `208` brake intensity + speeds, `210` pedal (byte 2), `212` pedal sensor 2, `308` rpm (bytes 1–2), `408` fuel litres, `40C`/`412` dash speed, `416` battery (0.1 V), `423` ignition / lights / indicators / doors bitfield, `608` coolant (−40) and fuel rate | **The closest relative found.** Body and chassis frames match ours: `0C0` (5 bytes, byte 3 always `07`, byte 4 counter; ours `6DFF0007xx`), `119` (byte 5 `08`), `312` (four 16-bit words), and `2F1`, `300`, `443`, `423` exist on both. The engine-side frames do not (`308`, `608`, `200`/`208` absent here; `210`, `423` other lengths and layouts) — plausibly because that car's engine ECU is Mercedes' diesel one and ours is Mitsubishi's 4G15T |
The Z27 Colt is a 2002 platform shared with the smart forfour (W454); the CZT /
Ralliart's 4G15T is also the forfour Brabus engine, and parts listings show the
sharing reaches the electrics (Z30 engine ECUs carry Mercedes-style `A135…` part
numbers; the steering rack is the 454's). The forfour notes bear that out for the
body bus. Their layouts are the first hypothesis for every shared ID, and their
is public, and none is being sought: the Z27's own recordings are the source. The same manual notes that the **Euro CZT has no MAP sensor**, so OBD PID
| [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
fits OBD-II replies for powertrain signals and phone sensors for body ones (GNSS
plays that part here); [CAN-D](https://www.ornl.gov/publication/can-d-modular-four-step-pipeline-comprehensively-decoding-controller-area-network-data)
and [ByCAN](https://arxiv.org/html/2408.09265v1) find signal boundaries from bit
flip rates, then byte order and signedness, then match. None reads our logs; the
