Google
 
Web NASIOC.com

View Full Version : Conditions for Re-Entering Rough Correction Mode?


williaty
12-27-2007, 11:31 PM
OK, what are the conditions for re-entering Rough Correction Mode (IAM evaluation) after you've been in "normal" (FBKC and FLKC) modes?

I know the load and RPM have to be within the ranges specified in the ROM, and the value for the current cell in the Max Advance map has to be above the specified threshold, but what else? I know from logging that those RPM, load, and advance alone are not enough to drop back into Rough Correction mode. What else has to happen?

Tea cups
12-28-2007, 08:07 PM
Primarily extremes of current fine correction learning (ex. < -3.8 or > 3.8 degrees of correction). However, there are additional conditions that come into play that vary by ECU and pieces of the puzzle (primarily for the 32-bit ECU) that I haven't had time to work out. And even some variations between N/A, STi, non-STi, later models, etc. (not necessarily rough correction but elements of knock control).

williaty
12-28-2007, 08:09 PM
Is one cell in the FKLC table going >|3.8| all it takes, or do multiple cells have to do it?

(presuming the other pieces of the puzzle are satisfied)

Tea cups
12-28-2007, 08:32 PM
It would be the current cell when the condition is being evaluated. This is extremely oversimplified, though.

mickeyd2005
12-29-2007, 12:02 AM
It's pretty rare for me to see IAM drop. The only two times I have seen it happen, the FLKC was zero. As Tea cups stated, the FLKC condition is just one of many logic statements.

I really don't understand the algorithm. My guess is that there might be another logic statement that has something to do with the signal waveform that the ecu receives from the knock sensor. Just a guess.

BTW, do you remember pnwrx on enginuity? His IAM dropping wasn't random. It was always at 2000-2100 rpm at 0.9 g/sec load. It only appeared to be random because that is an unusual area of the table to drive in. So, whenever he hit that area, his IAM would drop. It would drop even though FLKC was zero. Then after driving around some more, it would go back up and then drop whenever he hit that one location. I believe he dropped timing 2 degrees in that area and smoothed it out from there to fix it. This was his bone stock timing map too.

Wheeler Bement
12-29-2007, 12:31 AM
FYI, and this was a first for me. I was sittign in the driveway, just reflashed, started the car and my IAM was 16. I put it in gear, pulled out, and by the time I made it 50ft down the road, it dropped to 14, then raised itself back up to 15. my drivway is downhill, I was backed in, so I just pulled out. I probably didn't rev past 2500, and I didn't see any knock(but must have missed it).

I know what I did though, I had been tunning with 15.0 AFR, decided to go back to 14.7, and forgot to remove timing...it was not happy with me.

Tea cups
12-29-2007, 09:03 AM
It's pretty rare for me to see IAM drop. The only two times I have seen it happen, the FLKC was zero. As Tea cups stated, the FLKC condition is just one of many logic statements.
There are a set of conditions to enter rough correction mode (extreme FLKC is one). That does not mean the IAM will change at that point. Another set of conditions would have to be met and even then the IAM re-evaluation does not necessarily have to be continuous after the mode switch.

I really don't understand the algorithm. My guess is that there might be another logic statement that has something to do with the signal waveform that the ecu receives from the knock sensor. Just a guess.
As far as rough/fine/feedback correction is concerned, it is strictly based on the same knock signal bit (either on or off, so either there's knock or there's not). The logic makes sense to me (extreme FLKC should be one of the factors to switch to rough correction mode). Again, I can't explain it in a paragraph. You can read the "subaru knock control explained" sticky that I wrote for the 16-bit ECU, although I need to create a separate document for the 32-bit ECU but the generalities are the same.

mickeyd2005
12-29-2007, 01:12 PM
As far as rough/fine/feedback correction is concerned, it is strictly based on the same knock signal bit (either on or off, so either there's knock or there's not). The logic makes sense to me (extreme FLKC should be one of the factors to switch to rough correction mode). Again, I can't explain it in a paragraph. You can read the "subaru knock control explained" sticky that I wrote for the 16-bit ECU, although I need to create a separate document for the 32-bit ECU but the generalities are the same.

The one thing that I don't understand is how the ecu decides between rough/fine/feedback correction if the only thing it has to go by is the knock signal bit.

I get FLKC right away after a ecu reset even wheen feedback correction is zero. It then clears. It seems like after an ecu reset, the FLKC is very sensitive and then it becomes less sensitive and clears itself. Just a guess from my logs.

Tea cups
12-29-2007, 01:58 PM
The one thing that I don't understand is how the ecu decides between rough/fine/feedback correction if the only thing it has to go by is the knock signal bit.
the knock signal isn't used to determine which knock control strategy is used. The other conditions determine which is active and only one is active at any given time. The knock signal bit is only involved in the decision process when a change is going to made, regardless of mode (change in IAM, change in FLKC, change in FBKC).

Wheeler Bement
12-29-2007, 10:29 PM
the knock signal isn't used to determine which knock control strategy is used. The other conditions determine which is active and only one is active at any given time. The knock signal bit is only involved in the decision process when a change is going to made, regardless of mode (change in IAM, change in FLKC, change in FBKC).

so if I have a log with both FBKC and FLKC for three consective lines, is this is an issue with the logging???

Tea cups
12-29-2007, 10:34 PM
so if I have a log with both FBKC and FLKC for three consective lines, is this is an issue with the logging???
No, it is the change in FLKC that is the active component, not the application of FLKC. It is always being applied outside of idle.