RomRaider

I made another update to the original explanation. I added some details about rough and fine correction that I omitted before because I thought it would be hard to explain or would be confusing to users. Let me know if it makes sense or if I can clarify anything.

The new stuff looks good, makes sense to me.

One question.... let me know if I have this right. The ECU will not change the IAM unless the ignition advance map calls for a value > 3.9 ??

That is one of the requirements.

Ok, just trying to confirm what implications it may have on the knock control strategy by modifying the advance map. Using a completely normalized table with no zeros on it at all could possibly drop the IAM at light load due to the tip in false knock, but not anywhere else due to the bounds of RPM and load. But if the advance table had areas or even if the whole thing was less than 3.9, then the IAM system would be more or less nullified and the only corrections would be current feedback and fine without the possibility to drop IAM. Thats probably not a good situation. Just doing a little thinking out loud and trying to get deeper into possible complications..

Remember, though, that a number of conditions must be met to move out of fine correction mode into rough correction mode, including a relatively large (absolute) value in the fine learning table. If it is in fine correction mode, no IAM changes will be made regardless until it switches to rough correction mode.

The primary reason for the setting the advance map to the same value across the board (as far as I know) is to easily see where negative correction is being applied to KC in your logs. With the next logger update, all ecus will be able to log the individual elements of KC (timing adv, current applied fine correction, current feedback correction) and therefore eliminate the need to do this.

I'm curious about what happens when IAM is driven down to zero by knocking and the knocking continues. Is knock feedback allowed to subtract up to 9 degrees from base map timing? Are negative fine correction table values possible when IAM is zero? Perhaps merchgod could walk us through what happens in this situation.

Also, I'm still a little confused about what the KC value returned to the SSM actually represents. I have the impression that if knock feedback is non-zero (i.e. negative) then that alone is reported as KC, and if it's zero then coarse+fine correction (always non-negative) is reported.

Yes, both feedback correction and fine correction learning are still active when IAM = 0 due to knock. And will correct to their respective limits. The only difference is that when the IAM is 0 or 1 and then after switching to fine correction mode, it will not enter rough correction mode unless the current fine correction(applied) value is positive (along with the normal requirements for switching modes). There are situations were feedback correction and fine correction table changes are disabled due to a group of triggered DTCs, but I have not been able to trace these to specific codes.


KC = feedback correction + current fine correction learning + (timing advance (max) map value * iam/16). It is the actual advance that added to base timing. Meaning, that it is not just some calculation for the benefit of logging. Think of KC as one of about 10 or so compensations to base timing. KC is negative if feedback correction + fine correction + timing advance * IAM/16 is less than zero. Simple as that. So, negative KC would indicate either severe knock or the current timing advance might be zero (low loads/rpm) and feedback + fine correction is negative.

please help me to understand the case more..

For example, on 4000-4500 rpm range, I am getting fine knock correction of -0.7 to -1.05 deg and Feeback correction =0

Does this mean that real knock really happen or potentially knock will happen.

This means that you had knock in the past somewhere within the specific load/rpm range that met the requirements for making changes to the fine correction table in ram. Think of feedback correction as based on current knock and fine correction as learned correction.

thank alot for the answer. The reading was collected just after reflash + ECU reset..,perhaps the unit pick it up at the 2nd spin..(learnt from 1st WOT run).

Need further finetuning to get rid of the -VE fine timing correction.

Is there a way to dump the fine correction RAM map, so that the ROM advance map can be adjusted to incorporate the engine specific issues?

You can't see the whole table currently with RomRaider's logger, although with the latest logger definitions you can log the current fine correction that is being applied.

UPDATE:
I've recently had an opportunity to examine the knock control logic in the 32bit ecus. It is remarkably similar to what is described for the 16bit ecus in this thread. I have enough information to update the 32bit ecu definitions in the future to allow for many of the same knock related tables that were recently added for the 16bit ecus (ex. feedback/fine correction step values, limits, delays, etc).

Some issues specific to the 32bit ecus:
1. The currently defined 'Feedback Correction Range (RPM)' is not correct in the roms I've checked so far. I will be adding the correct range in the next update. The currently defined table is a wider rpm range which is involved in incrementing or clearing knock counters for the purpose of enabling or disabling failsafe feedback correction and failsafe fine learning applied correction depending on the knock signal. The activation of these failsafes is under very specific conditions and would allow feedback correction outside the normal rpm range and also limit fine learning applied correction to primarily negative correction. So far, it appears that only the STi has these failsafes active, but I will need to check more roms to be sure.

2. 'Feedback Correction Minimum Load' and 'Advance Multiplier Learning Delay (Increasing)' tables long available for the 16bit ecus are also present in the 32bit roms I've checked so far and will be added as well.

3. A few other minor tables specific to the 32bit ecus that might be useful will be added.

4. Relevant to both ecus and not clearly explained in my thread is that adjustments to the fine learning table are not allowed when feedback correction is active. Because feedback correction and fine learning correction rely on the same knock signal and are executed sequentially, it would seem that a adjustment to the fine learning table would never occur. However, there are very specific conditions which all must be met where feedback correction could be temporarily disabled, allowing for a fine correction table adjustment. I have not researched this in as much detail, but will update this thread when I have more concrete information about this.

Really good info.

Hopefully, this will enable us to write a reliable pseudo-KC counter for the 32 bit ecu's.

Not sure if it will help or not given the data is the same. Note that the disabling of feedback correction will allow for the potential adjustment of the fine learning table, however this does not impact the application of the fine correction which, outside of idle, is always applied, for the most part.

Anyway, I have enough information now to start to working on the next ecu def update, so I'll probably revisit this at a later date.