now simulating front O2 signal using WB signal
I think I was interpreting it backwards this morning after I had just got woken up by work!
Thread Starter
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
At WOT you have sufficient exhaust flow to go closed loop. I run the MAFT closed loop at WOT in my DSM, works fine. However its a moot point, totally different subject at this point even though they *seem* related.
Tried out one modification this morning that I was hoping would tighten up the swings in AFR, but it had no significant effect. First graph below is a log from the latest version. The second graph is one where the stock NBO2 system is controlling closed loop. The swings are tighter and the rate of oscillation is at least twice as fast. I'm sure its due to the placement of the WBO2 sensor at the end of the DP.
Overall though, its working great. The slower, wider swings don't seem to be having any noticeable impact on drivability. However, I'm still going to considering moving the WBO2 sensor further up the DP because I'm already thinking about how to implement a high performance closed loop fuel system.
At any rate, I'll post the patch instructions for 88590015 soon, maybe today.
Overall though, its working great. The slower, wider swings don't seem to be having any noticeable impact on drivability. However, I'm still going to considering moving the WBO2 sensor further up the DP because I'm already thinking about how to implement a high performance closed loop fuel system.
At any rate, I'll post the patch instructions for 88590015 soon, maybe today.
As was said though, it doesn't seem to affect drivability at all. And just for what it's worth, this log is from 80mph freeway driving with a strong headwind and the A/C on, and it netted me just over 27mpg.
Also, for those with slightly larger cams, my HKS 272's idle fine at 15.5:1. It's pretty lopey, but I haven't had stalling issues or anything.
Awesome work MrFred! I was wondering when this concept would take flight. Starting with the cruising closed loop simulation is step one, then move on to full WOT closed loop operation.
Manufacturers PREFER using 100% closed loop WB control but until recently it wasn't cost effective. Thats the only reason why the companies stuck with the NBO2 setup, even on their hugh end vehicles. VW's new GTi uses 100% closed loop tuning with a bosch WB sensor from the factory, as do a few other cars out this year.
Keep up the awesome work man.
Manufacturers PREFER using 100% closed loop WB control but until recently it wasn't cost effective. Thats the only reason why the companies stuck with the NBO2 setup, even on their hugh end vehicles. VW's new GTi uses 100% closed loop tuning with a bosch WB sensor from the factory, as do a few other cars out this year.
Keep up the awesome work man.
Last edited by Jack_of_Trades; Jul 27, 2008 at 07:32 PM.
Thread Starter
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
Yeah, it might work, but it would definitely work better if the closed loop control was PI(D) rather than simple switching.
During closed loop cruise in an unmodified ECU, the ECU sets a base fuel injector pulse width for 14.7 AFR. The closed loop system can then trim this base pulse width value. The ECU reads the front NBO2 sensor to determine whether its above or below the target 14.7 AFR. If its above, then it adds fuel, and if its below it pulls fuel out.
My patch does not take control of the base pulse width, so that base pulse width does not change when my patch is operating. What the patch does is send a simulated front O2 sensor reading to the ECU. The simulated signal is modified so that the desired AFR (say 15.5:1) appears to the ECU as if its actually 14.7 AFR. The ECU will then modify the trims (in this example pull fuel out) to stabilize on this simulated signal. Its the exact same concept as used by Innovate and Zeitronix, but by creating the simulated front O2 signal in the ECU, I can make the patch follow the values in the fuel map rather than be stuck at a single simulated value (what you get when the simulation is done in the WBO2 sensor controller).
At any rate, after running some errands this morning, I can say that this is a far better solution than controlling to a single value of say 15.5:1. Driveability is much better.
My patch does not take control of the base pulse width, so that base pulse width does not change when my patch is operating. What the patch does is send a simulated front O2 sensor reading to the ECU. The simulated signal is modified so that the desired AFR (say 15.5:1) appears to the ECU as if its actually 14.7 AFR. The ECU will then modify the trims (in this example pull fuel out) to stabilize on this simulated signal. Its the exact same concept as used by Innovate and Zeitronix, but by creating the simulated front O2 signal in the ECU, I can make the patch follow the values in the fuel map rather than be stuck at a single simulated value (what you get when the simulation is done in the WBO2 sensor controller).
At any rate, after running some errands this morning, I can say that this is a far better solution than controlling to a single value of say 15.5:1. Driveability is much better.
This answered my question, but brings up another. Isn't the base pulse width dependent on what is in the fuel table? i.e. the ECU uses a multiplier on the pulse width value used to get 14.7:1 to attempt to achieve the value in the load cell it is operating at?
By the nature of the narrow band closed loop feedback (0.5v = 14.7:1) I believe you will always get 14.7:1 under the operating conditions defined for closed loop, but on a stock rom if you change the value in the table from 14.7:1 to 15.5:1 I would expect the base pulsewidth (i.e. the pulse width before closed loop trims are factored in) to change.
Thread Starter
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
This answered my question, but brings up another. Isn't the base pulse width dependent on what is in the fuel table? i.e. the ECU uses a multiplier on the pulse width value used to get 14.7:1 to attempt to achieve the value in the load cell it is operating at?
By the nature of the narrow band closed loop feedback (0.5v = 14.7:1) I believe you will always get 14.7:1 under the operating conditions defined for closed loop, but on a stock rom if you change the value in the table from 14.7:1 to 15.5:1 I would expect the base pulsewidth (i.e. the pulse width before closed loop trims are factored in) to change.
By the nature of the narrow band closed loop feedback (0.5v = 14.7:1) I believe you will always get 14.7:1 under the operating conditions defined for closed loop, but on a stock rom if you change the value in the table from 14.7:1 to 15.5:1 I would expect the base pulsewidth (i.e. the pulse width before closed loop trims are factored in) to change.
When the ECU is running in closed loop, it ignores the values in the fuel table when calculating the base fuel pulse width. This can be verified by changing cells in the closed loop area and logging AFRMAP. I've looked at the subroutine where this is done. I plan, perhaps in the next week or so, to look at modifying this subroutine so that the ECU starts using the fuel map to calculate the base pulse width during closed loop.
Thread Starter
EvoM Guru
iTrader: (50)
Joined: Mar 2006
Posts: 9,675
Likes: 132
From: Tri-Cities, WA // Portland, OR
Thread
Thread Starter
Forum
Replies
Last Post
mrfred
ECU Flash
496
Sep 14, 2022 07:08 PM
stokEd
Evo X Engine Management / Tuning Forums
51
Oct 14, 2015 06:44 PM
