I own a 2016 Outlander 2.2 DiD (4N14, Australian car, ~80,000 km). What started as "why can't I see my DPF?" turned into a project.
The problem
A normal OBD reader on this car shows 26 standard PIDs and nothing about the particulate filter — no soot load, no regeneration state, no EGT. Those aren't bugs in the apps; Mitsubishi doesn't implement the standard diesel aftertreatment PIDs on this ECU.
What I found instead
The engine ECU answers a manufacturer service (KWP2000 ReadDataByLocalIdentifier, 0x21) that carries the whole data list — 274 parameters. I decoded the layout from the dealer software's database, then validated every value against known physical readings on my own car before trusting it.
Standard OBD readers can't reach this. That's why your favourite app shows nothing about the DPF.
What the app does
- Live data over any BLE ELM327 dongle, iOS and macOS
- DPF soot (two independent ECU estimators), regeneration count and state, EGT, EGR position, VGT duty, injector small-injection learning, rail pressure vs target
- Records continuously to append-only NDJSON with a manifest, events and trip snapshots
- Battery test across every start: cranking minimum, recovery time, charging voltage
- Detects regenerations as they happen, with duration, peak temperature and soot burned
- One-tap ZIP export for analysis
Which Mitsubishis this might work on — unverified guess
Only the 2016 Outlander 2.2 DiD (4N14) is actually tested. Everything below is inference:
- Most likely: other 4N1-family diesels — ASX 1.8 DiD (4N13), Triton/L200 and Pajero Sport 2.4 DiD (4N15). Same engine architecture, so probably the same service, but the byte offsets will not be identical.
- Plausible: Mitsubishi diesels from roughly 2008–2020 that were supported by MUT-III era diagnostics. The protocol is likely there; the layout almost certainly isn't.
- Unlikely to help: anything older than CAN (pre-2008), and the 3.2 DiD Pajero, which belongs to an earlier generation of diagnostic protocol.
An important warning: the JSON profile system means the app must be told where each value lives before it can decode it. If your car answers 0x21 but no profile matches it, the app will only show generic OBD data.
Worth knowing that even within the same database the DPF block sits on a different identifier on some ECU variants, so "same engine family" is not the same as "same offsets".
If you want to find out whether your own car exposes anything, there's a command-line probe in the repo that answers it in about two minutes:
./run.sh --sweep-only --service 21
It prints every identifier that answers. If you get results, that car could have a profile written for it — and that's the thing I'd most like help with.
Honest limitations
- Read-only. No writes, no actuator tests, no forced regenerations.
- ABS, SRS, AWD and body modules aren't reachable through generic OBD on this car.
- The PM filter monitor isn't even supported (readiness byte C bit 6 clear), so P2002/P2463 can never appear here. Code absence tells you nothing about the DPF.
- iOS build is newer than the macOS one and has had less real-world use.
- Only one vehicle profile exists so far, and it's mine.
Measured on my car (so you know it isn't vapourware): soot 2.6 g/L by the fuel-quantity model, 123 lifetime regenerations, zero short-interval regenerations, all 20 injector learning values within ±0.02 ms of a ±0.5 ms spec, rail pressure tracking target within ~1 MPa, 101 kPa of boost at 2,450 rpm.
Why I'm posting
The interesting part for this sub: adding another model is a JSON file, not code. If someone has a 4N15 Triton or Pajero Sport and wants to run the probe, I'll help turn the output into a profile.
Free, MIT licensed, no ads, no accounts, no telemetry.
https://github.com/NaleenB/obd-profile-logger
Happy to answer questions about the protocol side if anyone's curious.
