RomRaider

The owner of the 2012 STi put his stock airbox back on and with only making tuning changes for the different intake, his FBKC that was showing up is gone. His IATs no longer rise over the pull like they did with the Cobb SRI. The weather conditions here today are the same as yesterday.

It sounds like there is a link to IAT which makes sense from what I'm seeing. It seems like a rapid increase in IAT is definitely a trigger for this preemptive knock correction.

Patrick has this -5 condition!

For AZ1G101N (Thanks Td-d)

Min rpm activation is 1700 rpm, max rpm 3800
Min load at 1,2, max 2.8
Primary open loop activation at 1 lambda, min coolant threshold at 78 celsius.

For those with bigger turbos or just stage 1 and 2, tuner can increase range for rpm and el so preemptive fbkc can cover what tuned map reaches. Similar to what we do for flkc and Iam range.

I did some logging today and 0xFFFF6524 is throttle plate opening and 0xFFFF66E8 is the throttle plate opening delta. So the table result is the PEKC min throttle opening threshold.

There's some per gear logic/tables in sub_33A92 that also effect PEKC

There are two sets of per gear tables, in the green ellipse all tables gear 1 to 5 all values are set to 19.922 and in the red ellipse all tables gear 1 to 5 are set to 26.953.

I'm unsure what dictates the switch between the tables in the green ellipse to the ones in the red but my car seems to only use the red ones. The result from these tables is compared to 3 param's even after logging these i'm still unsure what they are. The result off the comparison between these param's and the per gear table results determins if switch value at 0xFF76CD is set or cleared. For PEKC to be active 0xFF76CD needs to be zero.

It's based off whether FFFF67D0 is set to 1 or 0 - trying to track down what sets that.

how did you get FFFF67D0? All i get is this

Further up the routine:



If you explore sub_22BAE


true / false bit is then passed on to r0, which is pass on to the stack:



this value is passed back from the stack to r0 later on:



and on the basis of this, either the 'red' branch is followed (false) or the green branch is followed (true).

Oh yeah i see it now!

any theories on what param's dword_FFFF6854, dword_FFFF9084 and dword_FFFF9088 are?

Have you linked this into the IAM re-evaluation or the evaluation for multiplier value of high det / low det fueling tables? The 32 bit ECUs do this at random for no reason at all sometimes (no knock sum logged) which on the 07 STI will cause an IAM re-evaluation and a fast learn. My hypothesis is if you can trigger the Vishnu reset (fast LTFT learn) it also includes a fast IAM re-evaluation where FBKC (and not FLKC) can show up and every once in awhile you may catch part of the IAM flopping, but I have only caught this logging at a very high sample rate. Of course if your initial IAM is 1, it is very hard to catch. Set initial IAM to 0.5 and you could catch your switching logic. It looks like the IAM re-evaluation if, then code.

I performed about 6K miles of logging on the stock 07 STI tune. I would see the still to be fully explained logic such as this often when filling up with gas on a long trip and letting cruise control do my driving on a hilly highway.

In my 06 WRX, I always had timing pulled (this was way before knock sum was available) where FBKC on a powershift down the 1/4 mile would pull up to 5* but then rapidly (faster than defined) jump to base+KC between shifts. The rapidness was rpm dependent and not time dependent as each gear would hold the pulled timing longer down a logged 1/4 mile run.

All of these situations are similar and if I were developing (thinking as an engineer and tuner) a pre knock condition function, I would have one function with different behavior control variables input into one "fast_learn" function.

Anybody here has some feedback about disabling this preemptive knock correction ? Any negative effects ?

I just did that today on my car - I put 0 instead of the -1.4 value found at 0x00010 past the normal FBKC.
The main reason for me was that my CEL was flashing (merpmod cel flash on knock) on FBKC but more than 90% of it was preemptive knock and the whole CEL flash thing was not very helpful until I did that.

Hey guys,

I am a couple miles behind you on reverse engineering the logic but I am trying to catch up. I have a question which hopefully can be answered relatively easily :

Is there more than 1 function that increment or decrement feedback correction value (I have found one separate function that sets it to zero but nothing else) ? Reason I ask is that the function I have been looking at seem to decrement it only based on a ram variable documented as E_knock_on_cyl4 which I can't seem to see triggering in my logs when I get FBCK. (it does from time to time go to 1 and I see the knock sum increasing but not when I get FBCK)

I too am getting -1.4 degree of timing correction while I modified the main retard value to -1.52. I'd like to understand what is driving the ECU to do this. Slight edit : I realized last night that I am logging the 8 bit FBKC value which doesn't have enough resolution to display the extra -0.12. I'll have to log the float or increase my retard value. Regardless though, my question on E_knock_on_cyl4 still stand

Thanks !

Hi guys,

Wondering if anybody has the ECUFlash defs for AZ1G202G available ?

Cheers,

Adrian

I'm using this

<table name="Feedback Correction Retard Value ALTERNATE" address="ce0f0">
</table>

for AZ1G202G ....

Thanks Andea!

anyone have the tables for A8DH202X?