RomRaider

Hey guys - going to be a little quiet over the next two weeks, I'm travelling with only a dinky toy little netbook - not the easiest thing to disassemble and analyse with!

Managed to have a further look on the plane - two of the switches identified above relate to the FBKC RPM range - i.e. the low and high ranges. Haven't analysed it fully yet, but I guess it would check whether the engine speed falls within the range.

Hmm... so it used the alternate retard value, but the normal advance value - if I recall correctly, the routine branches off to the alternate retard value, but still uses the 'normal' advance value - hence the scenario above.

Found it in a few ROM's now, 0x00010 past the normal FBKC

Now I know what it is, I have been trying to induce it and I can get it from getting a MAF g/sec peak then dropping airflow within 0.25 seconds triggers it. Can also do the same thing on feathering the throttle to get airflow peak and then airflow stall etc

I've seen it use .35* to advance at other times even though I've set it to advance .50*. There is certainly some interesting logic around this and it sounds like there might be references back to load and MAF. I still suspect there could be a learning based component involved since I've seen nearly identical conditions induce this type of FBKC correction and then not induce it the following time.

Have since found the alternate 'pre-emptive FBKC' in every 32bit ROM I have tuned.

06/07 ECU's, the -1.4 is in the cell address just after FBKC

03-05 XT/LGT is usually within 0x00020

There are also references back to closed loop fueling - can you do me a favour and log closed loop fueling target and CL/OL state for me, and try and recreate the conditions for me? If you look at the logs, actual AFR also drops significantly each time this knock occurs.

Another one of the switches checks whether the Engine Load is above / below the feedback minimum engine load activation threshold.

I have closed loop deactivated - so just running constant open loop

Also, I have always seen it above the minimum FBKC threshold.

Interesting. Then again, this is the mother of all routines, loads of variables being loaded in, so maybe just a detour. From what I'm gathering, FBKC ranges, engine load, and what I assume is airflow are the main ingredients to this section of the code.

I will need to actually trace the entire routine right from the top to make sure...

Still getting this time to time. I'm curious as to whether you have made any progress on it. I'm mainly concerned regarding if the car actually picked up a detonation event or not.

Appreciate the time you've put into the effort. Thanks.

Link Knock Microphone on, no knock at all. It is pre-emptive to stop a condition the ECU thinks could become knock. This PEKC appears to be under boost error conditions as well

Haven't had the time to dig back - I'll definitely get to it though, and post up findings.

Any updates on this ?

I too had suspected something like this. I had never changed my FBKC retard value, but had noticed two very different behaviors in the way the pulled timing is re-advanced.

My suspicion was that the pre-emptive timings gets re-applied really fast (maybe the advance value is the same as the retard size), however "real" knock seemed to get wound back on in the familiar "advancing by 0.35" method.

Doing a "race-change" from 1st to 2nd on a stock tuned MY11 WRX (ADM) would induce up to -4.2 of this (suspected pre-emptive correction) almost every time I tried it (on multi cars).

I've not had the time to really dig through this, but I suspect given feedback (excuse the pun) above, that it is the same as this value referenced by COBB:

Feedback Knock Retard Decrement Alternate (Max. CL Target Rich)
-> This value is the step value for each negative change to feedback knock correction when the maximum closed loop fueling target lambda (which changes based on various conditions) is at the "rich" maximum.

So I expect that if I had to follow the logic of the various switches checked prior to branching off to this alternate value, they would relate to CL fueling lambda.

Not convinced that it's preemptive in that case...

Interestingly now that you mention COBB, it reminds me of a COBB response to a forum post I read (maybe 12m ago), in reply to people complaining about seeing heaps of FBKC on their OTS tunes, and the COBB guy at the time stated that FBKC was not always trigger by knock..