RomRaider

Please try logging AF correction #3 when you see this oscillation, that would confirm whether the oscillation is by design or if it's due to too much gain in a feedback loop.

I just re-read a few posts in that thread and there's a pretty good chance that the table in question isn't what I though it was. I came close to finding the tables that govern my car's AFC#3 oscillation a long time ago, but didn't quite finish it up. If you are seeing AFC#3 oscillations, I can try to pick up where I left off.

It didn't make a difference. At all. I actually turned it back on just for +10% because of a shared low engine load cruise issue I was having.

Just pushed the work I have done to git: https://github.com/Merp/SubaruDefs/comm ... a42d90d473

To download the entire test definition set: https://github.com/Merp/SubaruDefs/zipb ... F1C_Tables
Then point ECUFlash to /ECUFlash/subaru standard/
And RomRaider to /RomRaider/Logger/logger_STD_EN_v82_Test

Proportional gain is quite complex. The relationship from the determination table to the constant is described in the table description. The lookup is currently unknown, so a bit of test logging (lookup param is defined) will need to be done to determine what it is and what it relates to before coming up with a tuning strategy.

I cannot find any logic that sets the Derivative gain. Added a logger parameter to determine if it is always zero or if there is some tricky referencing going on.

There are two sets of limits to AFC1. One set is hard coded and is defined in the ECUFlash def. The other set is variable and is included in the logger def for testing.

Would be very interested in playing around with these when I finally get my car back.

Something interesting that I found whilst looking around for the various AF3 correction, learning and rear O2 comps was another set of limits set at -50% and 50% - but these impacted on AF#1 learning (setting to zero whilst MFB was testing for me basically disabled AF#1 learning completely). I'll see if I can find the addresses again, have you come across these?

I haven't gone into the learning stuff yet, but there is a TON of stuff going on in this area. Opening one of these routines in graph mode shows a bunch of other subroutines. Seems like an issue with IDA defining individual subs, but all of them are related to fueling and fueling corrections.

I assume these limits are in addition to the +/- 25% AF1 learning limits that are defined. Perhaps they are further down the chain, after all the correction/learning gets added together.

I have a lot of work for monday so i cant test it out then but tuesday i will probably spend most of the morning testing and recording my findings for you guys. Ill post them here and let me know who wants a pm with before and after.... Thanks btw... the car is miserable unless your in the throttle...

What didn't make a difference?
Do you mean that the AF Correction #3 parameter continued oscillating in your log?

It didnt make a difference because in my case it was actually helping with the fueling from initial stop to moving, and the almost no throttle cruise in the .4 -.7 load that was using the same maf lookup values as Idle.... It may help for sure in other applications but i found that it helped the lean spot that was created in my car....

Its really a double edged sword with my setup... Its a rotated 40r running a stock ECU that is used to seeing feedback much quicker then it is... on a smaller stock location turbo you may not see these issues.... maybe the mix of unequal length headers would help me too but as it stands its a 2 inch header that is equal length right to the turbo... then the twinscroll has the output that feeds the o2 sensor.... So when i want the front 02 sensor to do less i ment this new proportianal gain that MERP has just discovered and not that i dont want corrections from the Oxygen sensor system.. I think the rear 02 in my case will actually help as the Wideband is located right next to it and the correction it adds isnt as significant as say a front O2 correction. I will post any findings and if you want me to log that AF3 let me know and ill add it to my list of things for tuesday

Yes, please. I think it's very likely that AF3 is the only issue here.

I am changing my Feedback. I changed the whole maf smoothing table to 98% and turned off the AF#3 values and ill tell you what. I was wrong and this seems to work after quite a bit of tuning but boy it took forever to get it right.

Do you know the address of the "AF #1 correction limits" table for AZ1E400U or A8DK100P? Or search algorithm?
Thanks.