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

type, date, updated

type	date	updated
report	2026-10-09	2026-10-13

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.
• The smart forfour 454 is the useful sibling. A sniffed 2006 forfour diesel shares our body/chassis frames (0C0, 119, 312, …) but not the engine ones; its notes are the first hypothesis for every shared ID.
• 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)
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 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 engine-side IDs a hint of what a petrol forfour or EU Colt would add.

The forfour Brabus is the sibling to look for. EcuTek's Colt CZT tuning manual (2005-on "CAN ECUs"): "The Smart ForFour Brabus edition is basically a Colt CZT with the fibreglass body"; one ProECU package tunes both. Brabus owners run CZT ECUs (MH8304F; ECUFlash definitions exist for CZT ROM 47110032 and Brabus 49100033, EvolutionM). So a Brabus's engine-ECU frames should be ours (if the JDM Ralliart's ECU matches the EU CZT's), while its body frames come from smart's SAM module: on the 454 "the SAM … sits at the awkward edge of Mitsubishi engine management and Mercedes body electronics" (smartcarmanuals). Expect, from a Brabus capture: engine frames equal, chassis frames (ABS, the shared electric steering) probably equal, body frames different. No Brabus or CZT capture is public; asking an owner for a minute of candump at the OBD port is the cheap way to get one. The same manual notes that the Euro CZT has no MAP sensor, so OBD PID 0B may be unsupported on the Z27 (obd-poller discovers that by itself). The smart fortwo 451 (hackaday.io) shares 423 as the cluster status frame, little else.

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.

Automated decoding, in the literature

Published tools do what the capture checklist sets up: record known values next to the raw frames and search the frames for them. LibreCAN fits OBD-II replies for powertrain signals and phone sensors for body ones (GNSS plays that part here); CAN-D and ByCAN find signal boundaries from bit flip rates, then byte order and signedness, then match. None reads our logs; the method — classify bits (counter, constant, live), cut signals, try both endiannesses, fit against OBD values at matching timestamps, rank — is the analysis tool to write.

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.