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

---
type: report
date: 2026-10-09
updated: 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](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
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](https://ecutek.zendesk.com/hc/en-gb/article_attachments/204299089/Mitsubishi_Colt_CZT_-_Tuning.pdf)
(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](https://www.evolutionm.net/forums/ecu-flash/767782-xml-file-smart-brabus-w454.html)).
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](https://smartcarmanuals.com/models/454-forfour/)).
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, 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
`0B` may be unsupported on the Z27 (`obd-poller` discovers that by itself). The smart
fortwo 451 ([hackaday.io](https://hackaday.io/project/19931-smart-fortwo-can-bus-reverse-engineering))
shares `423` as the cluster status frame, little else.

### 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.

## 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](https://rtcl.eecs.umich.edu/rtclweb/assets/publications/2019/fv075-peseA.pdf)
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
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.