contracts/docs/impl/reports/Z27AG-CAN-PRIOR-ART.md

type, date

type	date
report	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 <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	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" (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	Index of public CAN ID collections; Mitsubishi: Lancer 2008 (habr, RU), 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 (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 and others	Per-model overrides; the Lancer one is empty. No Colt repo
habr 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	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	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.