RomRaider

Open Source ECU Tools
 FAQ •  Register •  Login 

RomRaider

Documentation

Community

Developers

It is currently Mon Jul 28, 2014 8:33 pm

All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 138 posts ]  Go to page 1, 2, 3, 4, 5 ... 10  Next
Author Message
 Post subject: Subaru's knock control strategy explained
PostPosted: Sat May 19, 2007 5:46 pm 
Offline
Administrator
User avatar

Joined: Wed Mar 29, 2006 10:38 pm
Posts: 5340
Please do not copy and post this information elsewhere. Instead, provide a link to this post.

Introduction

This post will attempt to explain, in detail, how the knock control strategy works for the 16-bit ECUs. The example values given are based on a USDM 02 WRX and the use of RomRaider/Ecuflash with the latest definitions.

Timing Basics
Ignition Timing is determined by the ECU as follows:

Total Timing = Base Timing + Knock Correction Advance + Other timing compensations

Other timing compensations = other compensations including those for IAT, ECT, per cylinder, among others.

Knock Correction Advance = (Timing Advance Maximum * (IAM/16)) + feedback knock correction + fine learning knock correction

Note: The IAM (ignition advance multiplier) used in the formula above is the raw value (ranging from 0-16) for the 16-bit ECU. For the 32-bit ECU, the IAM will range from 0 to 1 (substitute "IAM" for "IAM/16").

From the formula above, you can see that Knock Correction Advance (KC) consists of three elements. How these values are determined and how they interact with one another will be discussed below.

Although exactly how the ECU determines knock (based on input from the knock sensor) is not fully understood, the result is quite simple. The knock signal is either set or clear. That it, as far as the ECU is concerned, there either is knock or there isn't. There's no level of severity that is stored or used for knock control.

Feedback Knock Correction (FBKC)

Feedback knock correction (FBKC), as applied, is always either zero or negative. It is active when engine speed and load are within the ranges specified by the 'Feedback Correction Range' tables (although it can be disabled temporarily as described below). If enabled, the ECU looks at the knock signal. If set (i.e. knock), the FBKC value is decreased by about 2 degrees("Feedback Correction Retard Value"). Each time this portion of the code is executed, 2 additional degrees will be pulled if the knock signal is still set, up to a limit of about -11 degrees("Feedback Correction Retard Limit"). However, if FBKC is negative and the knock signal then becomes clear (i.e. no knock), FBKC does not immediately reset to zero. Instead, there is a delay("Feedback Correction Negative Advance Delay") in which the current correction remains until the knock signal is clear over the delay period. If so, feedback correction is increased by ~1 degree("Feedback Correction Negative Advance Value") and the feedback delay counter is reset. If not, and the knock signal is set over the
delay period, the counter is reset and 2 degrees will be pulled. This process continues and FBKC will eventually reach zero as long as the delay period is satisfied enough times to increment the correction back to zero. Of course, "delay" is in the terms of the ecu, so this all happens very rapidly.

As noted above, FBKC can be disabled even when load and RPM are within the ranges specified by the "Feedback Correction Range" tables. In fact, this is necessary as the two other elements of knock control (changes to the IAM and changes to fine learning knock correction, described below) cannot be active unless FBKC is disabled. ALL of the following conditions must be met in order for FBKC to be disabled. If any of the following are not met, FBKC is enabled within its load/rpm ranges:
  • Coolant temp is greater than 140F
  • A/C was not just turned on (an extremely brief window of time after the A/C is switched on)
  • If in rough correction mode (described below), load and RPM are within the "Rough Correction Ranges".
  • If in fine correction mode (described below), load and RPM are within the "Fine Correction Ranges"
  • Immediate change in load is less than about +/- .05 g/rev.
  • ECU is not in test mode
  • ECU is not in limp-home mode due to the triggering of specific groups of CELs.
  • An unknown timing compensation based on throttle change is not active (i.e. no compensaton).

Rough Correction (IAM)

Rough correction involves manipulating the IAM (ignition advance multiplier) due to knock. This has the result of correcting timing advance across the board (timing advance maximum * IAM/16). The IAM can range between 0-16 for the 16-bit ECU.

The ECU has two modes of operation - rough correction or fine correction. That is, the ECU is either poised to possibly make corrections to the IAM (rough correction) or to possibly make changes to the fine learning knock correction table (described later), but not both at the same time. But, just because the ECU is in either of these modes, does not mean changes to the IAM or the fine learning knock correction (FLKC) table will be made. Therefore, there are two sets of thresholds for each mode. One set determines when to switch between modes (different depending on the current mode) and another set to determine whether changes to the IAM or FLKC table will be made in their respective modes. NOTE: After an ECU reset, the ECU defaults to the rough correction mode.

To exit from fine correction mode to rough correction mode, ALL of the following requirements must be met:
  • Engine speed and load must be within the ranges specified by the 'Rough Correction Range' tables.
  • Timing advance (maximum) map value is greater than 4.9 degrees.
  • Some FLKC value change (positive or negative) occured last execution.
  • The last FLKC applied value (|x|) is greater than 3.9 degrees (that is, the absolute correction -> ex. -4 = 4)
  • The last FLKC raw difference (|y| * 2.84) is greater than last timing advance (maximum) map value.
  • (IAM > 1) or (IAM <= 1 and last applied FLKC was positive).
Once in rough correction mode, the following requirements must be met each time in order to make any change to the IAM. That is, even though the ECU is in rough correction mode, it will not always be adjusting the IAM:
  • Current timing advance (maximum) map value > 3.9 degrees ("Rough Correction Minimum Timing Advance Map Value").
  • Limp-home mode not active (IAM would already be 0 in this case)
  • FBKC is disabled.
  • IAM step value > 1 (explained below)
If these are met, the following will occur, however, only after switching between the fine correction mode to the rough correction mode. That is, these will only be executed once each time the switch to the rough correction mode from fine correction mode occurs and right before a change to the IAM is going to occur:
  • IAM is set to the 'Advance Multiplier (Initial)' value
  • IAM step value is set to 4 ("Advance Multiplier Step Value", described below)
  • IAM learning delay counter set to 0 (explained below)
  • The entire FLKC table in ram is cleared.
The knock signal is checked. If clear (i.e. no knock):
  • The IAM learning delay counter is checked. If the current value is less than the delay target specified by the 'Rough Correction Learning Delay (Increasing)' table then the counter is incremented (similar to the delay for FBKC). When the current value is greater than the delay target, then the IAM is increased. On the first run through, IAM is always advanced by 4 ("Advance Multiplier Step Value"). It remains 4 as long as it is keeps increasing the IAM (up to 16). However, if during the last execution the IAM was decreased, the IAM step value is reduced by 1/2. This occurs each time the IAM flip-flops. When the IAM step value is less than or equal to 1, the rough correction mode ends (after applying one last change to the IAM) and the ECU switches to fine correction mode. Basically, this is the way the ECU determines that the IAM has settled.
If the knock signal is set (i.e. knock):
  • There is no delay for decreasing the IAM. However the counter value is cleared because knock was detected.
  • Other than no delay, the rest of the logic is basically the same as when the IAM is increasing except that the IAM is decreased.
In addition, when the IAM is 0 or 16, after a slight delay of remaining at these extremes, the ECU will switch to fine correction mode regardless of the current IAM step value. This would be necessary if there was not enough "settling" before reaching these extremes to exit the rough correction mode.

Note, that when the IAM has finally "settled", the ECU will switch from rough correction mode to fine correction mode. Fine correction mode will continue until the mode switch conditions listed at the beginning of this section are met again.

Fine Learning Knock Correction

Fine learning knock correction (FLKC) allows for positive or negative correction to KC based on knock. These values are stored in RAM and are stored and applied across specific load and RPM ranges. The ECU determines these ranges based on the 'Fine Correction Rows (RPM)' and 'Fine Correction Columns (Load)' tables. Although these tables consist of 7 values each, the ranges make up an 8x8 3d table. For example:

If your 'Fine Correction Rows (RPM)' table is: 1400,1800,2600,3400,4200,5000,6000 - the ranges would be as follows:
  • Range 1: less than 1400
  • Range 2: 1400 to less than 1800
  • Range 3: 1800 to less than 2600
  • Range 4: 2600 to less than 3400
  • Range 5: 3400 to less than 4200
  • Range 6: 4200 to less than 5000
  • Range 7: 5000 to less than 6000
  • Range 8: 6000 +
Fine correction is designed to make "finer" adjustments to timing after the IAM has roughly corrected timing advance where there is no knock. Fine
corrections are stored in RAM and are applied to KC all the time (except for certain conditions like idle). Although the FLKC table values in RAM are always being applied to KC, adjustments to the table itself can only occur when certain conditions are met:
  • Currently in fine correction mode. The switch from rough correction mode to fine correction mode occurs when the IAM step value <= 1 or IAM is 0 or 16 after a slight delay.
  • FBKC is disabled.
  • Engine speed and load are within the ranges specified by the 'Fine Correction Range' tables.
  • Limp-home mode is not active.
Then, if the knock signal is clear, other conditions must be met to add positive correction to the current fine correction cell in ram:
  • (FBKC and/or negative FLKC was NOT applied during the last execution)
  • If #1 is true, then the previous FLKC load/RPM range also has to be the same as the last range before this execution.
  • The current FLKC table load/rpm range is the same as the last range.
Like the other corrections, there is a delay before which an FLKC table value can be increased ('Fine Correction Advance Delay'). This is based on a counter (similar to the FBKC counter), which is incremented when there is no knock and is cleared when FLKC table adjustments are made or the knock signal is set.

If the above are met, then the FLKC value for the current load/RPM cell is increased. However, it cannot be increased if current timing advance + FLKC is greater than the current value in the "Timing Advance (Maximum)" table. This also means that if the IAM is 16, only negative FLKC is allowed. Each increment of FLKC is .35 degrees ('Fine Correction Advance Value'). Maximum allowable correction is 8 degrees("Fine Correction Advance Limit").

If the knock signal is set:
  • Fine correction in the current FLKC cell is decreased by about 1 degree ("Fine Correction Retard Value") with a limit of about 12 degrees("Fine Correction Retard Limit").
NOTE: After switching from fine correction mode to rough correction mode and right before the first change to the IAM after switching to that mode, the entire FLKC table is cleared and no corrections to the table are made until the ECU switches to the fine correction mode (although the current FLKC table is applied regardless except at idle and certain sensor failures).

FAQ

Q: Do the 32-bit ECUs use the same logic?
A: The 32-bit ECUs generally follow the outline as described above. Some of thresholds may be different and some conditions may not apply or there may be additional conditions not listed. There are also other elements to knock control with the 32-bit ECU which have not been fully analyzed. But the description for the 16-bit ECU is sufficient to tune for the 32-bit ECU.

Q: Whenever the IAM is re-evaluated, you said that the IAM is set to the value in the 'Advance Multiplier (Initial)' table, even without an ECU reset. I've never seen this in my logs. Can you explain why?
A: When the IAM re-evaluation starts, IAM is always set to this initial value, however this would be almost impossible to catch on a log because the next chunk of code is involved in decreasing/increasing the IAM (with an intial IAM step value of 4). This happens pretty much instantly as far as logging is concerned and it would be very unlikely that you would capture it.

Q: How can I log feedback knock correction, fine learning knock correction or the IAM?
A: If your ECU is supported for extended parameters with RomRaider's logger (be sure to update to the latest logger definitions), then you can log the following which relate to knock control:
  • IAM (Ignition Advance Multiplier)* - current IAM
  • Fine Learning Knock Correction* - current applied FLKC
  • Feedback Knock Correction - current FBKC
  • Fine Learning Table Offset - current applied FLKC cell. If this value remains the same while logged FLKC changes, then the ECU made an adjustment to the FLKC in the current cell (barring any sync issues normal to logging).
Q: So, there is no fine or feedback correction to KC above their respective rpm/load ranges?
A: Not necessarily. Fine correction is applied in ranges. Looking at the RPM example above for 'Fine Correction Rows (RPM)', the stored FLKC value in RAM is applied at any rpm 6000+ (and its corresponding load cell). However, a change to the FLKC table in RAM can only occur within the ranges as specified by the 'Fine Correction Range' tables. If this table has a max value of say, 6200 rpm, then adjustments to the RAM table will only be made between 6000-6200 (assuming the same corresponding load), however they will be applied from 6000+ rpm (also assuming the same load). Also, for FBKC, if it is negative at the same time you are leaving the maximum load or rpm thresholds, the ecu will keep the current feedback correction in play.

Q: I've logged a large negative value in FBKC, but the IAM and FLKC did not change? Why didn't the ECU change the IAM based on this severe knock?

It is better to think of following as three distinct means of knock control:

1. Negative FBKC

2. Changes to the current IAM.

3. Changes to the current FLKC cell (note this is different than applied FLKC).

That is, only one is active at any given time based on what would be appropriate for the given conditions. So, in order for the IAM to change, the "severe" knock would have to occur when the ECU is in rough correction mode, FBKC is disabled, and the conditions to make a change to the IAM are met. So, basically, the corrective action that is taken is dependent on which knock control method is active at the time and whether certain conditions were met (although some values, such as FLKC, may partially impact mode selection as described earlier).


Last edited by merchgod on Tue Jul 31, 2007 7:37 pm, edited 6 times in total.

Top
 Profile  
 
 Post subject:
PostPosted: Sat May 19, 2007 8:37 pm 
Offline
RomRaider Donator

Joined: Fri Apr 20, 2007 6:46 pm
Posts: 11
Thanks a lot, your educational posts are great for somebody new to tuning like myself. Much appreciated.


Top
 Profile  
 
 Post subject:
PostPosted: Sun May 20, 2007 12:17 am 
Offline
Moderator

Joined: Wed Nov 22, 2006 10:23 pm
Posts: 2306
Nice work.

EDIT:

I needed to summarize this during a conversation I had in PMs with a guy at IWSTI. While not as detailed, I think it's a more 'accessible' version of the knock control story, so I put my rendition onto the wiki:

http://www.romraider.com/RomRaider/HowT ... ockControl


Last edited by NSFW on Thu Jun 03, 2010 4:55 am, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Sun May 20, 2007 12:54 am 
Offline
Experienced
User avatar

Joined: Mon Jun 05, 2006 2:01 pm
Posts: 280
Location: minnesota
Nice thread, Bill.

Your descriptions of how the timing system works is a nice confirmation to what I've been seeing in logs over the years (and recent weeks with the new 32-bit logger defs).

I guess it's nice to have some "official" closure on a few assumptions I'd formed over time. :D

_________________
- Tom
- '06 wagon on corn booze


Top
 Profile  
 
 Post subject:
PostPosted: Sun May 20, 2007 2:58 am 
Offline
Newbie

Joined: Thu Dec 14, 2006 9:06 pm
Posts: 67
Location: Singapore
Very informative post. Thanks.


Top
 Profile  
 
 Post subject:
PostPosted: Sun May 20, 2007 9:10 am 
Offline
Administrator
User avatar

Joined: Wed Mar 29, 2006 10:38 pm
Posts: 5340
thanks guys.

I'm focusing on a big ecu def update for the 16bit ecus right now with lots of new tables and fixes. Also, the next logger def update will include a lot of the new parameters added for 16bit ecus (similar to what was added for the 32bit last time) plus some new ones for both ecus. Once I'm done with these updates, I'll take a closer look at the 32bit knock control, outline any differences here and add the tables to the defs as well.


Top
 Profile  
 
 Post subject:
PostPosted: Sun May 20, 2007 11:24 am 
Offline
Experienced
User avatar

Joined: Wed Mar 01, 2006 10:51 pm
Posts: 336
Nice job merch. These types of posts will be a great help to a lot of people (myself included).

A new one to start on would be for reading hex images, and disassembly in general. I've been looking for something like that on the openecu forums to no avail. Reverse engineering really interests me.

Justin


Top
 Profile  
 
 Post subject:
PostPosted: Sun May 20, 2007 12:09 pm 
Offline
RomRaider Developer
User avatar

Joined: Tue Jan 23, 2007 5:11 pm
Posts: 964
Location: Austin, Texas
Justin 05 STi wrote:
Nice job merch. These types of posts will be a great help to a lot of people (myself included).

A new one to start on would be for reading hex images, and disassembly in general. I've been looking for something like that on the openecu forums to no avail. Reverse engineering really interests me.

Justin


IDAPro, and it helps to know assembler. ;)

BTW, nice explanation Merchgod.


Top
 Profile  
 
 Post subject: Re: Subaru's knock control strategy explained
PostPosted: Sun May 20, 2007 4:24 pm 
Offline
Experienced

Joined: Wed Jul 26, 2006 3:19 pm
Posts: 650
Location: Connecticut, USA
merchgod wrote:
...

FEEDBACK CORRECTION

...

However, if feedback correction is negative and the knock signal is then clear (i.e. no knock), feedback correction does not immediately become zero. Instead, there is a delay(*) in which the current correction remains until the knock signal is clear and no IAM/fine corrections (either positive or negative) are made over the delay period. If so, feedback correction is increased by ~1 degree(*) and the delay counter is reset. This process continues and the feedback correction will eventually become zero as long as the delay period is satisfied enough times to increment the correction back to zero. Of course, "delay" is in the terms of the ecu, so this all happens very rapidly.

...
This has me a little confused, especially the "no IAM/fine corrections ... are made over the delay period." Are you saying that timing suddenly becomes just base - feedback during the delay? Or are you saying that only feedback is reported as KC via SSM during the delay?


Top
 Profile  
 
 Post subject: Re: Subaru's knock control strategy explained
PostPosted: Sun May 20, 2007 5:37 pm 
Offline
Administrator
User avatar

Joined: Wed Mar 29, 2006 10:38 pm
Posts: 5340
Jon [in CT] wrote:
This has me a little confused, especially the "no IAM/fine corrections ... are made over the delay period." Are you saying that timing suddenly becomes just base - feedback during the delay? Or are you saying that only feedback is reported as KC via SSM during the delay?


Not that it suspends corrections (although it does suspend changes to the fine correction ram values for this brief time period), instead a correction resets the counter. The counter is incremented each execution where the knock signal is clear. There is a mistake in this paragraph (I went ahead and edited it), there are actually 3 separate counters (fine, feedback and rough correction). So, in this case, the "no-knock" counter is incremented each execution where there is no knock and it is reset if the knock signal is set or there was a negative feedback correction in the last execution (normally one in the same, however the counter sub is not executed in this block of code). It is the same for fine correction, except that its counter is cleared when there was a negative fine correction or the knock signal is set.

Here's an example for feedback correction:
1. knock signal is set. Feedback and Fine correction "no-knock" counters are cleared.
2. Negative feedback correction due to knock: -2
3. Next execution: knock signal is still set - more correction: -4, "no-knock" counters cleared.
4. Knock signal is now clear. "no-knock" counters are incremented by 1.
5. Feedback "no-knock" counter is compared against the feedback advance delay value. If it the counter is less than the delay, feedback correction remains at -4.
6. When the counter is incremented enough and exceeds the delay value (due to no knock), feedback correction is advanced by 1 degree (-3). "no-knock" feedback correction counter is reset.
7. The counter is incremented again as long as there is no knock or negative feedback correction. feedback correction is advanced by 1 degree (-2).
8. This continues until feedback correction is zero (assuming no knock and the delay periods are satisfied enough to bring it back to zero).

When feedback correction is not zero, fine correction is disabled to obviously avoid these corrections interferring with one another. IAM can still be re-evaluated even when there is negative feedback correction.


Last edited by merchgod on Sun May 20, 2007 8:19 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Sun May 20, 2007 7:13 pm 
Offline
Experienced
User avatar

Joined: Thu Oct 19, 2006 11:34 am
Posts: 838
Location: Putnam, CT
Awesome explanation as usual Bill

_________________
93 Mustang LX 32 valve swap
95 Mustang GTS 347 kenne bell
04 Ram twin turbo 6 speed
94 Grand Cherokee locked and lifted
99 Civic HX sweet commuter car


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 25, 2007 9:30 am 
Offline
Senior Member

Joined: Fri Feb 10, 2006 7:04 pm
Posts: 1282
Location: Pittsburgh, PA
Is there any way to increase the resolution of the fine correction learnt map? Right now it's an 8x8 matrix. Having a 10x10 or even a 12x12 matrix would make tuning so much eaier. Then to tune timing all you have to do is increase timing across the board and read the fine correction table after several pulls and drive cycles. Then simply subtract the learnt knock from your base table and voila!

This will bascially be an auto-tuned timing map. I apply the above strategy now but I'm have to break up my map into 4 quadrants.
1. high load/high rpm
2. high load/low rpm
3. low load/high rpm
4. low load/low rpm

Increasing the resolution of the fine correction table will reduce my tuning cycles by a factor of 4.


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 25, 2007 9:53 am 
Offline
Administrator
User avatar

Joined: Wed Mar 29, 2006 10:38 pm
Posts: 5340
mrf582 wrote:
Is there any way to increase the resolution of the fine correction learnt map? Right now it's an 8x8 matrix. Having a 10x10 or even a 12x12 matrix would make tuning so much eaier. Then to tune timing all you have to do is increase timing across the board and read the fine correction table after several pulls and drive cycles. Then simply subtract the learnt knock from your base table and voila!

I discussed this in another thread, but haven't yet messed with it. Ram space is limited so this wouldn't work with RamTune but there would be two options to implement it:

1. Have the ecu actually run off a larger learning table. The table could be any size you want. The problem with a larger table is, that the correction will be applied over smaller ranges. So, if you have a decent knock over a wider range, the requirements for fine correction and the load/rpm ranges would need to be hit each time and the knock experienced in order to apply the correction across multiple cells. This would reduce the safety factor of this element of knock control depending on how it was set up.

2. Duplicate the ecu's logic for fine correction and store them in a larger table while keeping the current learning the process the same. That is, the table would have no effect on KC, it would be merely reporting correction as if the larger table was active but is not. The problem with this method is that changes to the normal fine learning table will skew the new larger table, so you would need to look at both. Safer, but less accurate information.


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2007 12:23 am 
Offline
Experienced

Joined: Fri Feb 10, 2006 4:41 pm
Posts: 483
Location: toggle switch envy, PA
this stuff has to be a goldmine to Bosch, Siemens, Ford and GM engineers :eek:


Top
 Profile  
 
 Post subject:
PostPosted: Sat May 26, 2007 6:47 am 
Offline
Senior Member

Joined: Thu Aug 03, 2006 10:40 am
Posts: 1364
05GarnetLGT wrote:
this stuff has to be a goldmine to Bosch, Siemens, Ford and GM engineers :eek:


i am about 99% sure they're already well on the way to complete disassembly of each and every one of their competitor's products--denso of course doing the same thing in turn. :)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 138 posts ]  Go to page 1, 2, 3, 4, 5 ... 10  Next

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Style based on FI Subsilver by phpBBservice.nl