Tag Archives: protocol

Updated Extended OBD-II definitions

Added 7 PIDs (0x10A1, 0x10A3..0x10A7, 0x1137), some are petrol-only, some diesel-only, some mixed.
See Extended OBD-II definitions page.
Downloads (spreadsheet, CSV) as well as ParsePID project are up to date.
Note that some PIDs have not been tested on actual cars yet – feedback is appreciated!

Mode 23 – Read Memory

According to some of my notes, Euro 5 diesel models, or cars that support Extended/Enhanced OBD-II in general, might support mode/service 23 for dumping ROM or RAM blocks:

Format is similar or same as ReadMemoryByAddress (23 hex) service specified UDS (Unified Diagnostic Services, ISO 14229) protocol:

"23 <Format> <Address[]> <Length[]>"

Several $23 formats can be supported, Euro 5 diesel:

  1. "23 14 A1 A2 A3 A4 L1"
  2. "23 24 A1 A2 A3 A4 L1 L2"

As you can guess, format byte e.g. 0x14 means:

  • 4 address bytes → uint32 big endian, encoded in low nibble of format byte
  • 1 length byte → uint8, encoded in high nibble of format


Stock firmware usually restrict available address ranges, allowing only partial dumps. ROM calibration data and RAM regions might work. Knowing how to reflash and reverse-engineer the logic, such restrictions can be patched and therefore eliminated.


Depends on actual implementation, (early) Euro 5 diesel ROM logic:

  • 0 < length ≤ 0x400 (dec 1024) bytes otherwise NRC 31
  • other formats or request message lengths yield NRC 13
NRC (hex) Description
13 Incorrect message length or invalid format
31 Request out of range


Euro 5 diesel (1.5 MiB ROM, SH7059 chip) example – dump beginning at ROM calibration data:

Start address = 0xC0000
Length (per request) = 0x40 = 64 bytes

"23 14 00 0C 00 00 40"
Positive response: "63 <XX XX XX ... total 64 payload bytes ... XX XX>"

"23 14 00 0C 00 40 40"

"23 14 00 0C 00 80 40"

"23 14 00 0C 00 C0 40"

"23 14 00 0C 01 00 40"

Anyone able to confirm that these mode 23 commands and formats are working?

Personal experience on many different control units: Maximizing length per request yields max transfer speed, however application algorithm must be able to handle NRC codes and react properly.


Just published my new little C# project:

ParsePID is a console application to analyse Extended/Enhanced OBD-II mode 22 capabilities, specifically for Subaru diesel and petrol control units supporting this protocol.

Go to http://github.com/SubaruDieselCrew/ParsePID/

  • README document includes demo output, currently for a diesel and petrol model.
  • The project uses published definitions from page Extended OBD-II, saved as CSV (delimiter: tab) format.
  • There is no need to compile the code for yourself if you haven’t got own data.

As always, do not hesitate to provide feedback…

Definitions Download for Extended OBD-II

Uploaded first draft of definitions file for diagnostics protocol Extended/Enhanced OBD-II. Should be easy to work with, can export to CSV etc. Everyone is welcome to use the data as long as it is mentioned where it came from.
Also added a few more PIDs in the meantime.
Go to page: Extended OBD-II

Protocols page Extended OBD-II

Added 3 more DPF related PIDs on page Extended OBD-II:

114A Pressure Difference between DPF Inlet and Outlet
1155 Estimated Distance to Oil Change
1156 Running Distance since last DPF Regeneration

Will add some more over time…
Apparently newer petrol models now also use this protocol (exclusively apart OBD-II, no SSM2 anymore ?). Might add petrol specific PIDs in the future.
Also, apps like Torque have been confirmed working with this.
Anyone able to provide any data, testing new or known PIDs, screenshots of software including SSM etc. or spot any issues, please get in touch!

Updated protocols page Extended OBD-II

Updated protocols page Extended OBD-II:

  • corrected “Exhaust Gas Temperature (EGT) at DPF Inlet”
  • added “DPF Regeneration Count”

Euro 5/6 model owners please test and report results, thanks!

Would also be interesting to know (logging) software capable of using this protocol. Tactrix Openport 2.0 standalone logging, Torque perhaps???

Diesel ECU Patch v2

Patched the CAN-handler responsible for the SSM2-Read-Addresses (A8) command. Now we’ve got high-speed full RAM access.
Euro4 stock ROMs prevent RAM access (0xFF**** addresses) via CAN (ISO15765 actually). Previously we had to resort to slow SSM2 via Serial protocol.

The static screenshot does not really tell the difference though. This Linux application can do both modes. Speed in comparison is like this: logging roughly 120 items using SSM2 via CAN updates all values fluently – no noticable delay. In serial mode, it takes multiple seconds for a single refresh – really major difference!

Planned: Implementing CAN block read command for even more performance e.g. quick RAM snapshots. Either command “A0” like SSM2 via Serial or Extended OBD-II mode 0x23 (stock Euro5 diesels have this), or both.