ECUTek Think Tank

[Kodename47]

After reading some other threads, is there a parameter to log whether the ECU is in open or closed loop operation? I've usually just worked it out from the fuel trims but an actual parameter would be useful. I've scoured the list but there's nothing obviously named.

[nelsmar]

Originally Posted by Kodename47

After reading some other threads, is there a parameter to log whether the ECU is in open or closed loop operation? I've usually just worked it out from the fuel trims but an actual parameter would be useful. I've scoured the list but there's nothing obviously named.

Fuel system status.

[jamesm]

Originally Posted by Kodename47

After reading some other threads, is there a parameter to log whether the ECU is in open or closed loop operation? I've usually just worked it out from the fuel trims but an actual parameter would be useful. I've scoured the list but there's nothing obviously named.

yep.. fuel system status. 1 is closed loop, 2 is open loop. not to be confused with the similarly important 'injection mode', where 1 is port, 2 is direct, and 3 is combined.

[Kodename47]

Cheers guys, I did wonder if that was the one. Is injection mode really worth watching? I just monitor PI and DI volumes, not that I'm really at a point when I need to though.

[nelsmar]

Originally Posted by Kodename47

Cheers guys, I did wonder if that was the one. Is injection mode really worth watching? I just monitor PI and DI volumes, not that I'm really at a point when I need to though.

I typically log what i specifically need to get the highest resolution. There are times I have done injection mode but typically i go with PI/DI volume instead. For generic logging I don't use it so much and just do PI/DI volume.

[jamesm]

Injection mode is necessary for tuning larger injectors. Can't get good data when you can't tell where the error is coming from.

[banane63]

I think we need an access to the Fine Learning Correction Table to monitor knock events.

RomRaider Learning View does it, but you need an extra cable...

[Kodename47]

Originally Posted by banane63

I think we need an access to the Fine Learning Correction Table to monitor knock events.

RomRaider Learning View does it, but you need an extra cable...

You can log it, it's just not in a tabular view.

[banane63]

You just have the advance correction, not the moment the knock occurs... It is hardly usable...
You see the Advance Multiplier moving down, with no understandable link with the knock correction...

[jamesm]

Originally Posted by banane63

You just have the advance correction, not the moment the knock occurs... It is hardly usable...
You see the Advance Multiplier moving down, with no understandable link with the knock correction...

You can log ignition correction fine and see when it first shows up, but it's a learned value so it will continue to be applied in that rpm/load bucket afterwards. So you do actually have the moment the knock occurred (or more precisely, the moment flkc can written), you just have to find it in the log. With a table view you have no idea what caused flkc to be written.

Eliminating all fine learning correction is huge, since you can't have repeatable, consistent performance with it present, even if it's only a -1.

[banane63]

That's why such a table could be useful : you see at what load/RPM knocking occurs, and modify your advance table in consequence.

[jamesm]

Originally Posted by banane63

That's why such a table could be useful : you see at what load/RPM knocking occurs, and modify your advance table in consequence.

but it's applied in buckets. so the table only tells you generally where it is... i.e. between 0.6 and 0.9 load and between 4 and 6k rpm. by watching the actual log of the value being applied you can see exactly when it was written into the correction table and make more refined adjustments. you wouldnt want to go slashing timing out of an entire load/rpm range when really you only needed to pull from a single cell to solve the problem.

[350matt]

its when the advance multiplier switches
so if you modify the load site at the moment the multiplier switches from 1.0 to 0.7 for example

[jamesm]

Originally Posted by 350matt

its when the advance multiplier switches
so if you modify the load site at the moment the multiplier switches from 1.0 to 0.7 for example

but flkc doesn't always cause the advance multiplier to drop, only when the written in value is really bad. like -3.1 or worse, and a number of other conditions are met. the correlation between the 3 knock control modes is far too complex to say 'when x happens, y will always happen as a result'. you have to log it in real time and watch it take place. for instance logging kclv. if you only could log kclv you'd have no idea what timing was being pulled from flkc and what was being pulled from coarse correction, it'd just be a guess. you may be able to infer based on the incrementation, but that's not a good way to go about it. you could easily be misled into pulling timing across the board (if you didn't know better) when in reality it was just one small load/rpm cell that needed a bit of timing pulled. same thing goes for flkc. once it's there, if you just look at where it's being applied you don't know where to pull the timing from with any degree of certainty.