Through comparing a few ROMs recently I have noticed some significant changes regarding oil dilution.
So far it seems, this is about newer Euro 6 diesel ECU firmware only, meaning MY 2015+. Apparently, firmware containing modifications were created in May 2017, probably published since 2017-07.
The oil dilution ratio threshold to trigger DTC P1468 Oil Dilution is now 15 % instead of 10 %.
A couple of tables have been adjusted, for example “oil dilution evaporation” is now defined up to 15 % and a few DPF regeneration behaviour tweaks.
Also, the relationship between log items “Distance To Oil Change [km]” and “Oil Dilution Ratio [%]” is not linear anymore, rather nonlinear in fact.
Both graphs were created out of 2015/2016/2017 Outback Diesel CVT ROM data:
JB4K104B, ROM date 2017-05:
Older Euro 6 CID
JB4K102B, ROM date 2016-10, and probably still applicable to all Euro 4/5 models:
I will update related pages in the near future.
For now, if you are affected, don’t use my custom “Oil Dilution 2” log item anymore.
If you like, you can use this simple formula instead, but it is only valid between 0 % and 8 %:
OilDilutionRatio3[%](DistanceToOilChange[km]) = 60-DistanceToOilChange/250
Since diagnostic item “Distance to Oil Change” is scaled in [100 km], above formula provides oil dilution in 0.4 % steps. Accuracy has become worse but is still better than standard log item “Oil Dilution Ratio” which only provides integer resolution. Not sure if logging apps such as Torque can handle table lookup or piece-wise functions.
Posted in Boxer Diesel, ECU Analysis, Euro6, Graph, Maintenance, Table
Tagged BoxerDiesel, Diesel, dilution, DPF, Euro6, maintenance, oil, plot
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!
Posted in Boxer Diesel, CAN, ECU Analysis, Euro5, Extended OBD-II, ISO15765, Protocol
Tagged BoxerDiesel, Euro5, ISO15765, Logging, petrol, protocol, Subaru
Perhaps another color map for EcuFlash might be interesting? I wrote a little SageMath python script to generate a ScoobyRom-like color map file.
EcuFlash using ScoobyRom color map
Note: Although generated color map matches ScoobyRom’s precisely, EcuFlash applies colors based on “
min” and “
max” specified in XML definitions.
Excerpt from EcuFlash definition file:
<scaling name="ChargeAirPressure" units="kPa" toexpr="x" frexpr="x" format="%.0f" min="0" max="255" inc="1" storagetype="uint8" endian="big"/>
Whereas ScoobyRom scales colors ranging from a map’s actually used mininum and maximum. For example, if you would change
min="100" in above scaling definition, low value colors would appear bluish like in ScoobyRom, effectively making map graphics cover more/most of available color range.
1) Download file scoobyrom-map.odt
2) Rename downloaded file to
ScoobyRom.map, since normal file extension is not allowed on wordpress.com.
3) Move file into EcuFlash’s color maps folder, i.e.
C:\Program Files (x86)\OpenECU\EcuFlash\colormaps\
4) Launch or restart EcuFlash.
5) Via EcuFlash menu: File → Options → Appearance → Default Color Map
(Btw., default color map directory can also be defined in Options)
Color Map File Format
Color map format is plain text ASCII file, usually 256 lines as in this case, specifying RGB values which will be applied to maps, from low to high:
153 153 255
153 154 255
153 156 255
152 157 255
255 110 103
255 107 102
255 105 102
255 102 102
What’s new in v0.8.2:
- Export as TunerPro XDF format.
- Support for ROM type SH72531 (1.25 MiB = 1280 KiB size)
- Display Reflash Count if known/available (Properties-window).
Project homepage: ScoobyRom Software
Already implemented in previous version is the ability to parse and display ROM Date (year-month-day), diesel as well as petrol type encodings. May not work for all ROM types (yet), though. AFAIK, ScoobyRom is the only software parsing this Denso specific date.
ScoobyRom 0.8.2 – Properties window, CID JZ4A211B
Due to my intense work on BMW ECUs in recent years, I got familiar with TunerPro which is a generic ROM editor. It is quite popular in the BMW community, it can handle lots of data format options. Its definition format “XDF” is XML-based as usual. As an exercise to verify XDF knowledge I implemented XDF output in ScoobyRom.
Compared to RomRaider, reading an XDF containing hundreds of tables is very fast, almost instant. TunerPro is Windows-only and closed-source however.
TunerPro 5.00.8853 screenshot, Windows 10 x64, XDF generated by ScoobyRom
Posted in Development, ECU Analysis, Graph, ScoobyRom, Software, TunerPro
Tagged C#, Denso, ECU, gnuplot, Mono, ScoobyRom, software, TunerPro
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:
"23 14 A1 A2 A3 A4 L1"
"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
||Incorrect message length or invalid format
||Request out of range
Euro 5 diesel (1.5 MiB ROM, SH7059 chip) example – dump beginning at ROM calibration data:
Start address =
Length (per request) =
0x40 = 64 bytes
"23 14 00 0C 00 00 40"
"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…
Posted in Development, ECU Analysis, Extended OBD-II, Protocol, Software
Tagged BoxerDiesel, C#, Logging, obd, protocol, software, Subaru