RomRaider

Even though it's a wideband, the high pressure in the UP apparently makes it inaccurate away from stoich.

If you move it downstream of the turbo you end up slowing down the feedback loop and thereby making it less accurate.

Also, when the ECU is in closed loop, doesn't it target 14.7 (plus whatever compensation) rather than the cells in the fuel map? I thought I read that somewhere but I can't find it so maybe not...

Closed loop, in the case of the ECU, is targeting 1.0 lambda regardless. While it is possible to modify that single target, you cannot create a map based target in CL (say off of the fuel map) by modifying any tables.

sadly, this is borne out in my experience as well.

what's closed loop actually? Correct me if I'm wrong somewhere: it's the sort of algorythm (PID?), when ECU makes correction to current amount of fuel injected; correction based on input from O2, all the time ... It's like watching event of past and making decision what to do next... Good on cruising, but with rapidly changing engine load, AFR would be out of predicted values all the time. in OL, with fueling based on MAF input, distance between MAF and trottle plate causes some delay on reading changed amount of air when trottle angle changed (i.e. Tip-In) That's why Tip-In enricment table exists.

P.S. As far as I always read lean AFR's (15.5-15.7) shortly after pushing the accelerator pedal during CL, I assumed that Tip In enrichment table ignored in CL. But, if merchgod says "not", it isn't

It's all an algorithm. You make a guess, then you correct it based on negative feedback, it's very simple.

Error should go down with more flow and wider throttle opening.

Zero out your tip in boost error table and try again.

Thanks for all the good info Merch, now please let me know if I understand it right.

I think I understand what each of the tables in the CL/OL Fueling Transition folder mean. I would like no delay from CL to OL, and I also want to know exactly when the car will go into OL(ie throttle position, RPM, load, vehicle speed etc.) If I zero the delay table, then it will switch to OL as soon as I exceed one of these table values(ie maximum throttle position, RPM, load, vehicle speed etc)?

I am curently running CL AFR of 14.9, my "minimum active primary OL enrichment is 14.41, so does this means that when my OL table wants something richer than 14.41 it will switch to OL fueling? If I understand it correctly, could I zero my delays, max out my "maximum values"(effectivly removing them fromt he equation) and expect my car to switch to OL whenever I want to run richer than the 14.41(minimum active primary OL enrichment) based on my OL fuel map?

Thanks
Wheeler

No. If you zero the delays, CL->OL transition is determined solely by the fuel maps.


Correct, other than you don't need to do anything to the max value tables. As soon as you zero the delay, it switches solely off the fueling table.

No, If the CL delays are zero, the other tables are irrelevant. It will always skip to the last step in the process in that case - which is to check the fuel map against teh "minimum active primary ol enrichment". Re-read the first post - this is all explained there.


The fuel map checked against the minimum active enrich threshold is always the last step in the process, regardless of whether the delay is zero or not. If you zero the delay, it will always skip to this last step as explained above to determine CL to OL and OL to CL transition.

Yes it is essentially PID. Short term correction is the proportional component. Long term trim (A,B,C,D) are the integral factors.

You do not need a wideband to do closed loop. Many cars use narrowband systems. The difference is you can only know you are either rich or lean and have to more heavily rely on the integral. The proportional cannot really be proportional. I wonder if those systems even use what could be called a "proportional" component. I bet it is more like a fast integral (forgotten) and learned (categorized and stored, like ours) integral. Since you are either just "rich" or "lean" you have to watch how long the narrowband holds either side and slowly add correction. If it pops back and forth between rich and learn fast enough you don't want to make corrections.

FWIW, there are tons of PID controls in the ECU. AVCS oil valve control, DBW throttle system, boost control, etc. None of them are straight "book" PID, but modified and enhanced to handle the needs of the system.

Does anyone know why my 16 bit 2002 wrx switches to open loop before it is called for in the fueling table with zeroed CL/OL delays?

If I go WOT at a very low RPM my car will switch into OL before the engine speed or load go high enough to call for more enrichment based on my fuel table. I have attached a log and a screenshot of my fuel table.

Thanks

that looks like the transition with the factory fuel map. Are you sure the fuel map shown is actually flashed to the ECU?

Absolutely. I have been using that fuel map for over a month and flashed it to the car multiple times.

If you want me to be 110% certain, I can pull the current map from the ECU. If It varied that would be an indication something was wrong with my EcuFlash.

can you post the rom?

Here you go:

I think the issue here could be that the car is not fully warmed up and some warm-up enrichment factor is coming into play. The primary fuel map does not solely or even directly make the final determination to go from cl to ol. Although I have not messed with it much, the actual determination is based on input from the front o2 (that is, say, some threshold richer than stoich - although not that straightforward). However, in practice, the open loop fuel map is usually the key (along with the minimum active threshold) because a level of enrichment (or no enrichment) below the active threshold would be no enrichment, resulting (generally) cl operation, whereas above the threshold would be some level of enrichment sufficient to trigger the transition to OL based on front o2 input.

If this is not due to warm-up enrichment, it could be due to the tune or some mechanical issue in which you are running richer than normal causing the early trigger even though there maybe no calculated enrichment. Try logging A/F Sensor #1 AFR in your next set of logs if you can recreate it again.