038906012 HA SG4922 edc15vm - EGR missing (map present at 0x55096, EB/C0 axis pair)

[Flamchu]

Reporting a map the detector misses on an EDC15VM, with what I found while digging into it.

Version: 1.2.3, built from source at 61fce3b (current master), detector version 49. Not an old build.

About the file: the EGR grid is a flat 8500 because I zeroed it myself in another tool, editing cell values only. I cannot say whether the car had an earlier remap before I read it. Mentioning this up front since I saw you ask about tuned files in #32 — but see the experiment below: the flattening is not what hides the map.

Symptom

cargo run --release --example expected_report on it:

fichier: sample.bin | ecu: EDC15VM | maps: 70
!! EGR                                                           0 / 2
   Driver wish                                                   2 / 2
   ...
!! IQ by MAP limiter                                             0 / 2
   ...
TOTAL 35 / 39 (90 %)

ECU: Bosch EDC15VM (70%), HW 0281011309, SW 038906012 HA SG4922, 512 KB, VP44 pump.

(The IQ by MAP limiter line is also short; I did not look into that one.)

The EGR is in the file

TunerPro definitions written for this exact binary put EGR 01 at 0x055096, with its codeblock-1 twin at 0x075096. The structure reads out cleanly:

X_ID = 0xEBDA   high = 0xEB   len = 16    IQ axis  @0x55058   0 … 5355
Y_ID = 0xC048   high = 0xC0   len = 13    rpm axis @0x5507C   0 … 5100
data @0x55096   16 × 13 = 416 bytes       cells: uniform 8500 (EGR deleted)

Both identifiers pass is_valid_axis_id, both lengths pass is_valid_length, and the [X_ID][X_len][X_data][Y_ID][Y_len][Y_data][cells] layout is intact, so try_detect_map does build the candidate.

Where it goes

name_known_maps (edc15vm/mod.rs:786) reaches the EGR rule for 416-byte maps only through edc15vm/mod.rs:942:

else if matches!(axes, (0xDD, 0xC0) | (0xC0, 0xDD) | (0xDC, 0xC0) | (0xC0, 0xDC)) {

EB/C0 matches no rule at that size, so named stays false and the candidate is dropped by // Only keep classified maps (edc15vm/mod.rs:1379). Nothing on that path reads the cell values, so the flat data is not what causes it.

What I tried, and why I am not sending it as a PR

Adding (0xEB, 0xC0) | (0xC0, 0xEB) to that one matches! is enough to bring the map back, and your existing profile gates appear to do the discriminating on their own — the file holds four EB/C0 416-byte candidates, and the other pair (0x554F2 / 0x754F2) is rejected on rpm[0] = 2440. With that change: 72 maps, EGR 2 / 2, TOTAL 37 / 39 (95 %), dump_maps diffed before/after shows 2 added and nothing removed or otherwise changed, factors coming out 0.1 / 0.01 as your existing EGR rule sets them.

But I do not think that is enough to call it correct, for two reasons:

One file, and no corpus. Your bar in CONTRIBUTING.md is a detector that behaves on files it has never seen, and I cannot demonstrate that from a single binary. If a stock 038906012 turns out to carry DD there and EB is somehow specific to this file, the rule would exist for one dump and should not ship.

Two things suggest EB is factory structure here rather than damage from my edit:

• the axis header at 0x55054 is byte-identical to the one at 0x75054 in the other codeblock (da eb 10 00). I only wrote cell values, and a value edit would not produce matching headers in two places.
• EB/C0 is already accepted for this family a few lines above, in the 480/512/544 branch (edc15vm/mod.rs:827), so the identifier is not foreign here.

The flat data is not the cause

I checked this rather than assumed it, on copies, changing one thing at a time:

variant	X axis ID	EGR cells	1.2.3 detector
as-is	EB	flat 8500	absent — 70 maps
refilled with a plausible 2300..8500 ramp	EB	208 distinct	absent — 70 maps
two bytes changed, data left flat	DD	flat 8500	found — 72 maps
both	DD	208 distinct	found — 72 maps

Refilling the map changes nothing; flipping only the axis identifier brings it back even with the data still completely flat. So the classifier's reaction is to the axis pair alone, which also means the detector is perfectly happy to name a deleted EGR — nothing here is a "tuned file" problem.

Happy to send you the dump privately — it is not my file to publish, so I would rather not attach it here. If a stock 038906012 shows the same EB/C0 pair then the one-line change is probably all it needs, and I can open it as a PR with tests and a DETECTOR_VERSION bump. If it does not, then this is a tuned-file case and you will know far better than me what the right anchor is.