NefMoto

So far, people have been disabling evap through CDTES and CDLDP, but I don't think that is the right approach; ESKONF is...

Does anybody know exactly which ESKONF bytes/bits (in M-box) must be twiddled to disable evap (assuming ALL of the evap hardware has been removed)?

setting bits in ESKONF does not disable emission functions or emission equip diag functions. It only disables the solenoid/relay open circuit diag.

i.e. setting ESKONF to not test evap valve does not stop evap functions from running and testing for evap functionality. Only disables test of whether or not evap valve is electrically connected. The results of which can cause the evap diag functions to throw an error if ESKONF is set to test valve and valve is disconnected.

Just wanted to make that clear. ESKONF = solenoid/relay testing only which is a small part of emission diag testing.

elRey: what would you recommend for a real RS4 with no evap running m-box (and dont say dont' run m-box, it is too late for that)?

RS4 on M-Box?

/facepalm

Sorry, I know I am not helping.

Nyet - Slightly on-topic.  Is there any way to see what the current EVAP g/s is?  Is there a variable to say how much i going into/out-of the EVAP system?

Translate my mbox .kp in to asap2 or .kp and you can bitch all you want at me :)

Not my fault you use proprietary software :P

If you want, you can try to write an ASAP2 writer in Java, and after that it's easy mode.
I am too busy with other things right now, sorry.

Need more info on ESKONF map... I mean DECON is the most confusing FR function...

So, how is ESKONF created? We have possible bits 0 1 2 3 4 5 6 7 which can translate upto 255 in decimal. At least in my file original ESKONF is 48 (dec) or b4 & b5 set to 1. To disable postcat o2 heater check I need to set additional bits b6 and b7. Now can someone tell me what other bits means (0 1 2 3 & 4 5)?

Bump for an old thread but does anyone have the info on this?
I usually just plug in the solenoid once I get things dialed in but the CEL that I get before that annoys me lol.

What do you want to know? Each byte is the sum of 4 bits.

ESKONF is 13 bytes starting at 10C75 in the M-box. In order to disable something you must set the accompanying bit to 11.

For instance, If you were to look at ESKONF in the 1.8 018CH:

AA FF 00 30 FF F8 30

Each byte represents 4 components.

30 hex= 00 11 00 00 in binary. The bits in that byte are LSHHK EFLA LDR TEV. So if you want to disable LSHHK, the new bits would be 11 11 00 00 in binary, or F0 in hex. To disable it, you'd make your new ESKONF:

 AA FF 00 F0 FF F8 30

You need to determine the bit pairs of the M-box, and modify ESKONF accordingly. I'd be willing to help, but most of my time has been going towards my own 5 bar transition

(yeah, that was a dig, LOL)

It just occurred to me that you may already understand the above. If that's the case all you want are locations? I have some of the M box mapped out, but not all of it yet. That information has been gleamed from observing the configuration from other flashes with known different hardware configurations. I haven't completely mapped it out yet, maybe someone else can chime in.

Haha sorry I've been sick and haven't even been on my laptop until today, I'll send you that info today for sure :-)

And I just need to disable the checking of the N80 plug to prevent the P1426 code.
I already have the ESKONF bytes defined in my xdf just as described above. Just need to figure out which bits are for the EVAP plug I guess.

You got mail my friend  ;)

:)

I'll send you over the bit pairs I've confirmed in the M-box ESKONF, but it's going to be underwhelming. I'm renewing my efforts as we speak.

Sweet.

Please post so I can add it to the s4wiki

or... add them for me :)

Still very slow going, I know which bytes a lot of the functions are contained in, just not the bit pairs yet. It would be great if I could find a complete list of which components were installed options in each flash. Right now it's just trial and error. I'd prefer to get confirmation prior to posting, as people tend to take the printed word as gospel :)

I got it figured out.

Changing the second byte to 255 disables the N80 checking.
If you also need it changing the sixth byte to 255 disables the N249 checking.

Cheers

But what else are you disabling by turning everything in the 6th byte off? The 2nd byte isn't a big deal as the N80 is the only configured component, but the 6th byte has all 4 bits configured (the first bit is bank 2 rear 02's, don't know what the rest are yet).

I already had the other bits of the 6th byte turned off anyway lol.
If I recall they are just the rear 02 sensors being plugged in or not.

Here's what I have for bytes 6 and 7:

Byte 6 LSHHK2 X X X

Byte 7 X BKV LSHHK1 X

X's are as of yet unknown.

I'm fairly certain byte 7 contains LSHHK1, meaning only one of the rear o2's is configured in byte 6.

I've been "flipping switches" all day in ESKONF and recording the results, should be close to finished (for the major components anyway) this weekend.

Yeah byte 7 was also set to 255 to code out rear o2 plug dtc as well.

That too (changing byte 7 to 255) is fine, as the only configured bit in byte 7 (for the M-box anyway) is the bank 1 rear o2. There is no issue FF'ing those as nothing else is being affected. My question is what else are you turning off by setting the bits in byte 6? I guess if you noticed nothing changing going forward then fine, but those bits are configured the same in all the flashes that I've looked at, so they have to be doing something.

You likely won't "notice" anything from FF'ing unnecessary bit pairs until you have an undiagnosed open circuit. Some of the diagnosis' have alot going on and could have other effects, but most of them are pretty basic.

If you have the byte identified, it won't take much more to narrow it down to the correct crumb.

ok call me crazy but wouldn't you be better off doing this via disassembly?

Not really sure. Phila conceded earlier that trial and error was probably the faster way to do it, and has offered to lend a hand with the condition bits to speed things up.

That, and I'm a novice with disassembly. If someone had the v6/v8 FR, I'd gladly throw down to buy it. Unfortunately, the easiest ways aren't always possible :)

If anyone reading this cares to contribute, LMK. I can always use people willing to unplug hardware and flash a file.

Not that easy to do this via assembly. Much quicker using an emulator.

Any time saving tips? I figured the last 3 bytes have to be comprised of ZUE and EV (doesn't make sense any other way) and comparing the rs4 ESKONF has shed a bit of light on bytes 2, 3 and 7 (cam sensor, intake setup, I have to be missing another one) but there are still quite a few holes to be filled.

Other than what I listed, what does the rs4 have that the s4 doesn't (from an electronics standpoint)? These questions aren't limited to PRJ, anyone with experience is welcome to chime in.

Nye,

This is slightly different than the S4 wiki as only combinations 11, 10, and 00 are defined... not 01.

Not really sure why someone would want to use 01, but you never know ;)

Pair of Bits:
1. Bit 2. Bit
0 0 Diagnos´ıs active with OBDII-malfunction storage with test of healing
0 1 Diagnosis active without OBDII-malfunction storage with test of healing
1 0 Diagnosis active without OBDII-Fehlerspeicherung without test of healing (-> EKP)
1 1 Diagnosis not active

Bringing this one back from the dead.

Has anyone correctly figured out the bit pairs for the M-box ESKONF?

Did I read correctly that setting Byte 7 (10C7B) to 255, is only disabling the diagnosis of the bank 1 rear O2?  The XDF that I have been using has two parameters identified for ESKONF. It says set 10C7B to 255 to disable rear O2s (this represents bit 7 and from what I'm reading in this thread should be verified as safe). However, it also identifies 10C7A as another parameter stating "Change to C0 (hex) or 192 (dec) to disable rear o2's".  A stock M-box BIN has this byte as 00, and without  knowing what bit pairs are involved in byte 6 I am a bit hesitant changing that byte.

I am ultimately  looking to remove Evap, and N249 as well.  Any help would be greatly appreciated

You're reading my xdf it appears, and it's correct. Just do what it says, that leaves all the other bit pairs as they were.

Has anyone identified what adjustments are necessary to remove the N80 and N249 valves?  I ignorantly removed the N80 valve (and subsequently disposed of it) and it appears my fuel trims are dead in the water without it being accounted for. 

Can anyone explain just what the purpose of the OEM killing fuel trims when ESKONF picks up a non-existent valve that should be there otherwise?  I haven't wrapped my head around why this is the response in the system, I just accept it as true.

Unlike the 1.8, there is no plausibility diagnosis on the N249, so just ESKONF is sufficient. As for the N80, you need CDTES, CDLDP, and ESKONF.

As for the logic, I have no idea. I assume it's to prevent a bad component from severely impacting fueling.

Thank you for the reply.

What about CLATEVE and CLALDPE?  I have set all of these parameters to 0 from the start, so I have not received any DTC's since day one, but I am curious why you say only CDLDP and CDTES are necessary (this is more of a teach a man to fish type question). 

Am I incorrect in that the STFT's remain active with an incorrect ESKONF, but LTFT's are disabled? 

When properly coded out via ESKONF, error classes aren't needed.

Bytes 11 through 13 which should refer to locations 10C7F-10C81 all show as 55 (hex) when I look them up on my stock M-box bin file.  55 translates to bit pairs: 01010101

What the heck is 01?