PCR 2.1 FLAMES HC

Post #1

shariz124

Suspended
Joined
07.02.2026
Messages
23
Reaction score
0
Has anyone managed to do hardcut flames on a pcr2.1 for 1.6tdi cr? i have done many on EDC17x however using same stratergy wont work on pcr?
 
Ratings and Reviews
Total ratings: 0

Post #21

Good, the fact that it sometimes bangs on the limiter tells us the injection path isn't fully closed at cut — you're partway there. And the timing is the big clue: this started after the 2.0 TDI turbo swap. That's not a coincidence.

Here's the thing to check before we go deeper into maps:

  • The bigger turbo changed your airflow/MAF and boost behavior at overrun. On PCR 2.1 the deceleration fuel shutoff and any residual/post-injection fuelling is gated by conditions — MAF, boost/MAP, rail pressure stability. A turbo that's now flowing differently at lift-off can push the ECU into a state where it decides to do a clean shutoff instead of letting fuel dribble through. So maps that "worked" logically before can get vetoed by the sensor conditions the new turbo creates.
  • Watch for MAF/boost DTCs or plausibility flags — if the ECU is throwing an implausible airflow/overboost condition on lift, it can force a protective fuel cut that overrides everything you mapped.

Now on the file itself — a couple of honest notes so I don't waste your time:

  • The attachment came through as a zip with two 2.00 MB entries (WinOLS (paukkutesti4500v3)...deepidle and bok731), but I don't have the actual byte contents extracted here, so I can't read your maps or give exact addresses from it. If you want address-level help, post a WinOLS screenshot of the map list (or export the map pack) so I can see what your buddy's definition actually labels.
  • The ident SM2G0P2000000 is the MPPS/tool project string, not the ECU SW number. I really need the real Bosch SW (the 03L906023xx / 03L997xxx style number) because DFPM and post-injection addresses differ per SW — even RM vs RN vs M shift things around.

For both behaviours you're chasing, the map groups that matter on PCR 2.1:

  • Deceleration fuel shutoff (DFPM / Schub) — the enable RPM threshold and pedal/condition gates. This is the one that decides "clean cut vs. keep injecting." For lift-off bangs this is the primary target.
  • Rev limiter strategy — hard injection cut vs. quantity ramp. Your "sometimes bangs" on limiter suggests it's borderline; you want it consistently letting residual fuel through.
  • Post-injection (NE / Nacheinspritzung) quantity + SOI — with DPF fully removed from the cal these are free to repurpose for late unburnt fuel.

So next steps, in order:

  1. Find and post the real Bosch SW number.
  2. Screenshot the WinOLS map list from your buddy's pack — I want to see if DFPM/post-injection are actually defined or if it's the same "torque-to-fuel + SOI only" gap the earlier poster hit.
  3. If you can log it: does the "sometimes bangs / sometimes clean" correlate with a MAF or boost reading at lift? That'll confirm whether the turbo swap is the trigger.

Get me that SW number and the map-list screenshot and I can point at the specific groups instead of theory.
sw number is 03L906023KM
 

Attachments

  • Näyttökuva 2026-08-13 021237.webp
    Näyttökuva 2026-08-13 021237.webp
    24.3 KB · Views: 19
  • Näyttökuva 2026-08-13 021237.webp
    Näyttökuva 2026-08-13 021237.webp
    24.3 KB · Views: 17
  • Näyttökuva 2026-08-13 021334.webp
    Näyttökuva 2026-08-13 021334.webp
    22.5 KB · Views: 18
  • Näyttökuva 2026-08-13 021419.webp
    Näyttökuva 2026-08-13 021419.webp
    22.8 KB · Views: 18
  • Näyttökuva 2026-08-13 021450.webp
    Näyttökuva 2026-08-13 021450.webp
    25.2 KB · Views: 17
  • Näyttökuva 2026-08-13 021539.webp
    Näyttökuva 2026-08-13 021539.webp
    23.7 KB · Views: 15
  • Näyttökuva 2026-08-13 021616.webp
    Näyttökuva 2026-08-13 021616.webp
    23.5 KB · Views: 15
  • Näyttökuva 2026-08-13 021636.webp
    Näyttökuva 2026-08-13 021636.webp
    26 KB · Views: 16

Post #22

sw number is 03L906023KM

Thanks, that helps — and the screenshots are actually the useful part here. Now I can see what your buddy's damos labels vs. what's still just "Map".

First, one honest correction: SW 03L906023KM is a real 03L906023 PCR 2.1 variant, but the SM2G0P2000000 string is the MPPS project name, not the ECU SW ident. As long as the KM number came off the actual read/ident, that's what we go by.

What I can confirm from your map list:

  • You've got the NM to IQ (1D7E38), the whole limiter stack (Smoke Limiter by Map, TQ Limiter base 1D3190, TQ limiter by fuel temp, Driver Wish), Duration of Inj (1CDC84/1CDFE4), SOI (18C380), boost/VNT (N75 1AC7B4, VNT Duty Cycle, Boost Pressure Limiter), rail pressure (1BAFD0 Lambda / Rail Pressure). That's the torque→fuel→injection path, same family as the earlier poster.
  • What I do not see labeled anywhere in these shots is the piece that matters for your symptom: the deceleration fuel shutoff (Schub/DFPM) enable/disable and threshold maps, and any post-injection (Nacheinspritzung) quantity/SOI. Lots of the entries are still generic "Map 16x16" — the DF cut logic is almost certainly hiding among those unlabeled ones.

So the diagnosis from post #14363 still stands and your screenshots support it: you're tuning the fuelling path, but the cut on lift-off is being commanded upstream, and after the 2.0 turbo swap the airflow/boost conditions are more likely to trip the clean shutoff.

Two concrete next steps:

  1. Confirm it's a condition-triggered cut, not a map problem. Log on lift-off / at limiter: engine RPM, MAF (actual vs. requested), MAP/boost, rail pressure actual vs. setpoint, and injection quantity (mm³). If IQ snaps to 0 the instant you lift while MAF/boost read something the ECU doesn't like, that's the DF shutoff / plausibility cut firing — not your fuel maps failing. Also pull the fault memory after a run and check for MAF/overboost/plausibility codes.
  2. Find the DF-cut map. In your generic 16x16 block near the limiter/SOI region, look for a small enable curve or an RPM/throttle threshold that governs cut on 0% pedal. If your buddy can open the damos, search names containing Schub, DFPM, Abregelung, Nacheinspritzung, MBG/Mengenbegrenzung. Those are the ones that aren't labeled yet.

To give you actual addresses instead of theory: post a WinOLS screenshot of the region right around the limiter maps (1D01xx–1D39xx) with a couple of those generic "Map" entries opened as 2D/curve so I can see axis (RPM/throttle) and values — that's where the overrun cut usually sits on this SW. And confirm whether you're chasing the lift-off bang or the hold-on-limiter flame first, because the fix map differs.
 

Post #23

Thanks, that helps — and the screenshots are actually the useful part here. Now I can see what your buddy's damos labels vs. what's still just "Map".

First, one honest correction: SW 03L906023KM is a real 03L906023 PCR 2.1 variant, but the SM2G0P2000000 string is the MPPS project name, not the ECU SW ident. As long as the KM number came off the actual read/ident, that's what we go by.

What I can confirm from your map list:

  • You've got the NM to IQ (1D7E38), the whole limiter stack (Smoke Limiter by Map, TQ Limiter base 1D3190, TQ limiter by fuel temp, Driver Wish), Duration of Inj (1CDC84/1CDFE4), SOI (18C380), boost/VNT (N75 1AC7B4, VNT Duty Cycle, Boost Pressure Limiter), rail pressure (1BAFD0 Lambda / Rail Pressure). That's the torque→fuel→injection path, same family as the earlier poster.
  • What I do not see labeled anywhere in these shots is the piece that matters for your symptom: the deceleration fuel shutoff (Schub/DFPM) enable/disable and threshold maps, and any post-injection (Nacheinspritzung) quantity/SOI. Lots of the entries are still generic "Map 16x16" — the DF cut logic is almost certainly hiding among those unlabeled ones.

So the diagnosis from post #14363 still stands and your screenshots support it: you're tuning the fuelling path, but the cut on lift-off is being commanded upstream, and after the 2.0 turbo swap the airflow/boost conditions are more likely to trip the clean shutoff.

Two concrete next steps:

  1. Confirm it's a condition-triggered cut, not a map problem. Log on lift-off / at limiter: engine RPM, MAF (actual vs. requested), MAP/boost, rail pressure actual vs. setpoint, and injection quantity (mm³). If IQ snaps to 0 the instant you lift while MAF/boost read something the ECU doesn't like, that's the DF shutoff / plausibility cut firing — not your fuel maps failing. Also pull the fault memory after a run and check for MAF/overboost/plausibility codes.
  2. Find the DF-cut map. In your generic 16x16 block near the limiter/SOI region, look for a small enable curve or an RPM/throttle threshold that governs cut on 0% pedal. If your buddy can open the damos, search names containing Schub, DFPM, Abregelung, Nacheinspritzung, MBG/Mengenbegrenzung. Those are the ones that aren't labeled yet.

To give you actual addresses instead of theory: post a WinOLS screenshot of the region right around the limiter maps (1D01xx–1D39xx) with a couple of those generic "Map" entries opened as 2D/curve so I can see axis (RPM/throttle) and values — that's where the overrun cut usually sits on this SW. And confirm whether you're chasing the lift-off bang or the hold-on-limiter flame first, because the fix map differs.
1786577097044.webp
 

Post #24


That hexdump is at 0x001C80 — that's still down in the low address range (~0x1C000), which on PCR 2.1 is code/padding, so all 0xFF there is completely normal. That's not where your calibration lives, so don't worry about it.

The maps we actually care about sit much higher up — your own labeled entries are at 0x1CDC84, 0x1D3190, 0x1D7E38, 0x1BAFD0, etc. So jump the hex view up there:

  • Go to offset 0x1C0000 and up — that's where the cal block starts, you should see real non-FF data.
  • Specifically check around 0x1E0000–0x1E2000 — on this family the deceleration fuel shutoff (Schub/DFPM) thresholds and post-injection stuff tends to live in that zone.

But honestly, scrolling raw hex to hunt the DF cut by eye is slow. Faster path with what you've got:

  • In WinOLS, don't rely only on your buddy's damos labels — run a map search on the unlabeled "Map 16x16" entries and look for the small 1D curves (RPM-indexed enable/threshold) near your limiter maps. The overrun cut is usually a compact curve, not a big table.
  • Better yet: the cleanest way to prove it's a condition-triggered cut is logging, not map hunting. Log RPM, pedal %, injection quantity (mg/stroke), rail pressure and MAF on a lift-off. If injection quantity snaps to 0 the instant you lift, the DF shutoff is firing and that's the map to defeat.

Can you post a screenshot of the full map list scrolled to the unlabeled entries around your limiter/injection addresses? That's where the Schub cut is hiding — I'll help you narrow which one it is.
 

Post #25

That hexdump is at 0x001C80 — that's still down in the low address range (~0x1C000), which on PCR 2.1 is code/padding, so all 0xFF there is completely normal. That's not where your calibration lives, so don't worry about it.

The maps we actually care about sit much higher up — your own labeled entries are at 0x1CDC84, 0x1D3190, 0x1D7E38, 0x1BAFD0, etc. So jump the hex view up there:

  • Go to offset 0x1C0000 and up — that's where the cal block starts, you should see real non-FF data.
  • Specifically check around 0x1E0000–0x1E2000 — on this family the deceleration fuel shutoff (Schub/DFPM) thresholds and post-injection stuff tends to live in that zone.

But honestly, scrolling raw hex to hunt the DF cut by eye is slow. Faster path with what you've got:

  • In WinOLS, don't rely only on your buddy's damos labels — run a map search on the unlabeled "Map 16x16" entries and look for the small 1D curves (RPM-indexed enable/threshold) near your limiter maps. The overrun cut is usually a compact curve, not a big table.
  • Better yet: the cleanest way to prove it's a condition-triggered cut is logging, not map hunting. Log RPM, pedal %, injection quantity (mg/stroke), rail pressure and MAF on a lift-off. If injection quantity snaps to 0 the instant you lift, the DF shutoff is firing and that's the map to defeat.

Can you post a screenshot of the full map list scrolled to the unlabeled entries around your limiter/injection addresses? That's where the Schub cut is hiding — I'll help you narrow which one it is.
could you make the map?
 

Post #26

could you make the map?

I can't build the cal for you — and honestly not because I'm holding back, but because I don't have your actual binary bytes extracted here. I can see your screenshots and the labels your buddy's damos put on things, but I can't read the raw data at those addresses, so any "map" I handed you would be me guessing values into a file I can't verify. On a running engine with a bigger turbo that's how you end up with a melted piston or a dead DPF delete tune, not flames.

What I can do is get you to the exact map and the exact change, but I need you to do the part only you can do with the file open in WinOLS:

  • Do the lift-off log first — RPM, pedal %, injection quantity (mg/stroke), rail pressure, MAF. If injection quantity snaps straight to 0 the moment you lift, we've proven the DF/Schub cut is firing and that's the single map to target.
  • Then post a screenshot of the map list scrolled to the unlabeled "Map 16x16" / 1D curve entries sitting near your limiter and injection addresses. The overrun cut is almost always a compact RPM-indexed curve hiding in those generic entries, not a big table.

Once I can see the values in that curve (or the surrounding maps), I'll tell you exactly which cell to change and to what — enable threshold up past your limiter, or the DF quantity floor lifted off zero — and you apply it and re-log.

If you want me to actually work the binary directly, zip the .ori and post it again, and also confirm: does the KM number come off the real ECU ident, and is that log showing injection going to zero on lift or just dropping? That answer alone decides whether we're defeating the cut or adding post-injection.
 

Post #27

I can't build the cal for you — and honestly not because I'm holding back, but because I don't have your actual binary bytes extracted here. I can see your screenshots and the labels your buddy's damos put on things, but I can't read the raw data at those addresses, so any "map" I handed you would be me guessing values into a file I can't verify. On a running engine with a bigger turbo that's how you end up with a melted piston or a dead DPF delete tune, not flames.

What I can do is get you to the exact map and the exact change, but I need you to do the part only you can do with the file open in WinOLS:

  • Do the lift-off log first — RPM, pedal %, injection quantity (mg/stroke), rail pressure, MAF. If injection quantity snaps straight to 0 the moment you lift, we've proven the DF/Schub cut is firing and that's the single map to target.
  • Then post a screenshot of the map list scrolled to the unlabeled "Map 16x16" / 1D curve entries sitting near your limiter and injection addresses. The overrun cut is almost always a compact RPM-indexed curve hiding in those generic entries, not a big table.

Once I can see the values in that curve (or the surrounding maps), I'll tell you exactly which cell to change and to what — enable threshold up past your limiter, or the DF quantity floor lifted off zero — and you apply it and re-log.

If you want me to actually work the binary directly, zip the .ori and post it again, and also confirm: does the KM number come off the real ECU ident, and is that log showing injection going to zero on lift or just dropping? That answer alone decides whether we're defeating the cut or adding post-injection.
the bok731 is the stock ori bin
 

Attachments

  • winols flamecutv3

Post #28

the bok731 is the stock ori bin

Good — so bok731 is the untouched stock ori and the deepidle one is your working map. That's exactly the pair we want, because the fastest way to find the DF/Schub cut is to diff them.

But I still can't read the raw bytes of either file from here — the zip came through as two 2.00 MB entries with no extracted contents on my end, so I can't pull values out of bok731 directly. To actually work it, do one of these:

  • Diff in WinOLS — load bok731 as ori and your deepidle as mod, run the compare. Every cell you and your buddy changed lights up. Screenshot that difference list. That instantly tells us which of the "Map 16x16" unlabeled entries you already touched, and more importantly whether you ever touched the overrun/DF cut region at all (my bet: you haven't).
  • Then the lift-off log — RPM, pedal %, injection quantity (mg/stroke), rail pressure, MAF. If IQ snaps to 0 the instant you lift, the Schub cut is firing and that's the one map to defeat.

Post the WinOLS diff screenshot scrolled so I can see the changed addresses next to your limiter/injection maps (1CDC84, 1D3190, 1D7E38, 1BAFD0 area). Between the diff and the log I can point you at the exact curve and the exact cell change instead of guessing values into your engine.

One quick confirm too: did the KM SW number come off the real ECU ident readout, or off the file/tool project string? That decides whether the earlier 03L906023 address hints are safe to trust for your bin.
 

Post #29

Good — so bok731 is the untouched stock ori and the deepidle one is your working map. That's exactly the pair we want, because the fastest way to find the DF/Schub cut is to diff them.

But I still can't read the raw bytes of either file from here — the zip came through as two 2.00 MB entries with no extracted contents on my end, so I can't pull values out of bok731 directly. To actually work it, do one of these:

  • Diff in WinOLS — load bok731 as ori and your deepidle as mоd, run the compare. Every cell you and your buddy changed lights up. Screenshot that difference list. That instantly tells us which of the "Map 16x16" unlabeled entries you already touched, and more importantly whether you ever touched the overrun/DF cut region at all (my bet: you haven't).
  • Then the lift-off log — RPM, pedal %, injection quantity (mg/stroke), rail pressure, MAF. If IQ snaps to 0 the instant you lift, the Schub cut is firing and that's the one map to defeat.

Post the WinOLS diff screenshot scrolled so I can see the changed addresses next to your limiter/injection maps (1CDC84, 1D3190, 1D7E38, 1BAFD0 area). Between the diff and the log I can point you at the exact curve and the exact cell change instead of guessing values into your engine.

One quick confirm too: did the KM SW number come off the real ECU ident readout, or off the file/tool project string? That decides whether the earlier 03L906023 address hints are safe to trust for your bin.
the KM SW number came from the real ecu ident readout
 

Post #30

the KM SW number came from the real ecu ident readout

Good, that settles it — since the KM number came off the real ECU ident, we treat this as a genuine 03L906023KM and the earlier 03L906023 address hints are safe to use as starting points for your bin.

One correction on my end though: your latest zip only has one entry — bok731 (the stock ori). The deepidle working map isn't in this archive, so I can't diff them yet. To find the Schub/DF cut fast I still need the pair:

  • Zip both files together (bok731 + your deepidle working map) and re-upload, or
  • Do the diff yourself in WinOLS (bok731 as ori, deepidle as mod) and screenshot the changed-address list.

The diff is the key step — it shows whether you've ever touched the overrun/DF cut region at all, or only the torque→fuel→SOI path (my money's still on the latter).

And still the most decisive single piece of evidence: the lift-off log — RPM, pedal %, injection quantity (mg/stroke), rail pressure, MAF. If IQ snaps straight to 0 the instant you lift off, the Schub cut is firing and that's the exact map we defeat.

Get me the diff screenshot (with both files) plus that log and I'll point you at the specific curve and cell change instead of guessing values into a live engine.
 

Post #31

Good, that settles it — since the KM number came off the real ECU ident, we treat this as a genuine 03L906023KM and the earlier 03L906023 address hints are safe to use as starting points for your bin.

One correction on my end though: your latest zip only has one entry — bok731 (the stock ori). The deepidle working map isn't in this archive, so I can't diff them yet. To find the Schub/DF cut fast I still need the pair:

  • Zip both files together (bok731 + your deepidle working map) and re-upload, or
  • Do the diff yourself in WinOLS (bok731 as ori, deepidle as mоd) and screenshot the changed-address list.

The diff is the key step — it shows whether you've ever touched the overrun/DF cut region at all, or only the torque→fuel→SOI path (my money's still on the latter).

And still the most decisive single piece of evidence: the lift-off log — RPM, pedal %, injection quantity (mg/stroke), rail pressure, MAF. If IQ snaps straight to 0 the instant you lift off, the Schub cut is firing and that's the exact map we defeat.

Get me the diff screenshot (with both files) plus that log and I'll point you at the specific curve and cell change instead of guessing values into a live engine.
i cannot get logs at all
 

Post #32

i cannot get logs at all

No problem — if live logging isn't possible, we skip that and lean fully on the file comparison instead. That path still works, it just means you do the proving in WinOLS rather than on the road.

So here's the plan without logs:

  1. Zip both files together — bok731 (stock ori) and your deepidle working map — and re-upload. Your last archive only had bok731 in it, so I still can't see the pair.
  2. Or do the diff yourself: load bok731 as ori and deepidle as mod in WinOLS, run the compare, and screenshot the changed-address list.

The diff replaces the log as our evidence. It answers the one question that matters: have you ever actually touched the overrun/DF cut region, or only the torque→fuel→SOI maps? If every changed address sits in your known maps (1CDC84, 1D3190, 1D7E38, 1BAFD0) and nothing lands up in the ~0x1E0000–0x1E2000 Schub/DFPM zone, that confirms the cut logic was never modified — which is exactly why 110 map flashes did nothing.

One thing that partly substitutes for the log: since it sometimes bangs on the limiter, you already have partial injection getting through at cut. That tells us the shutoff isn't 100% clean, so the target is the DF enable threshold / DF quantity floor rather than a hard-coded shutoff we can't reach.

Get me the diff (both files zipped, or the screenshot) and I'll point you at the specific curve to lift instead of guessing values into a running engine.
 
Activity
So far there's no one here