Search RomRaider

RomRaider

Documentation

Community

Developers



  • View Page
  • Page History/Versions
  • Print Page

IAMDA and KC

Reproduced here with permission of Vaus, the author.

Originally posted at http://forums.nasioc.com/forums/showpost.php?p=16930449&postcount=60 Note that the original thread has a lot of interesting discussion on this topic.

There seems to be a lot of misunderstanding. Here is my take on it:

You guys zero’d out the dynamic advance tables for some reason. First of all, this does not disable the ecu’s knock *detection* system. The ECU can still detect knock and pull timing in the event of knock using the fine correction table. Since the dynamic advance map is zeroe’d out, such activity would appear as a negative knock correction during logging. This negative would also be just as persistant as a lowered knock correction in a regular approach.

What this approach does do, however, is disable the ECU’s ability to make over-all corrections via the advance multiplier. This is the case because the overall correction mechanism works by adding and removing multiples of the dynamic advance table using the advance multiplier. So while as you said, the advance multiplier is still active, it will have no effect on anything unless it crosses the programmed threshold to send the ECU into high det mode, which, depending on the programming, could disable boost and switch to the high det fuel map.

Now there is a problem here. The ECU code is designed to work with both of these systems (coarse and fine ignition corrections). So lets look at hypothetical situation where for some reason the knock threshold of the setup is dropped significantly (bad gas, meth injection malfunction, extremely hot weather, excessive boost etc). In such a case where the tune would be effected in a majority of load/rpm cells, the ECU would start by pulling timing where it senses knock first. This would show up as negative entries in the fine corretion table. As this table fills up with enough negative corrections, the ECU will decide that an over-all correction is now appropriate. Now its course of action is to drop the advance multiplier and clear the fine correction map. Then the ECU would proceed to make fine corrections again with the new given overall correction. This would be fine assuming that the drop in the advance multiplier resulted in an overall drop in ignition advance, but since the dynamic advance map has been zeroe’d out, the drop in the AM did nothing and the subsequent clearing of the fine correction table actually brought timing back up to the original tuned levels. Now the engine will experience more severe knock untill the ECU goes through a couple of these cycles and may eventually drop the AM bellow the high det threashold to switch to the high det fuel map and pull boost. Note, however, that this would take a couple cycles of this activity to occure and in the meantime the enngine is experiencing severe knock as the ecu is clearing the fine correction table and incrementally dropping the AM.

Now, this is an example of a fairly severe reduction in the knock threshold or octane level, so its not necessarily likely to happen. But cases like that are the reason this ECU has these features built into it. No good tuner tunes these cars expecting to rely on the ECU to do this in normal conditions. Its a failsafe plain and simple and you have in fact disabled this aspect of it.

That being said, I have no idea what issues you were having with keeping some timing in the dynamic advance table. This should in no way limit your ability to run the total timing you’re running in your current approach and there is no reason you should have been “fighting the ecu”. I realize it may be easier to visualize the total timing without having to think about the dynamic advance map, but this is not a good excuse IMO.




Forum

RomRaider Forums

Join our forums, the best place to find help and answers!





Donate


RomRaider is developed and supported by volunteers working on their own time. To support their efforts please consider making a donation.





Page last modified on May 15, 2007, at 10:22 PM
Powered by PmWiki