RomRaider Logo

RomRaider

Open Source ECU Tools
 FAQ •  Register •  Login 

RomRaider

Documentation

Community

Developers

It is currently Thu Dec 25, 2025 1:12 am

All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: Why are "open loop" table values expressed in terms of AFR?
PostPosted: Fri Oct 07, 2016 11:49 pm 
Offline
Newbie

Joined: Sat Nov 14, 2015 7:57 am
Posts: 2
I have an 08 Legacy GT and am just dipping my toe in the water here with tuning so bear with me if this appears like a "did you even search?!?" type question...

I feel fairly confident in my grasp on open loop vs. closed loop fueling principles but I keep getting hung up on why the Primary Open Loop Table values are expressed in terms of AFR when Open Loop logic is not designed to target AFR values.
I understand that it is the ECU logic that really defines what those values ultimately mean in terms of fueling and Subaru could've potentially used arbitrary values instead of AFR numbers but it feels to me like we're missing some tables that define how the supposed AFR values correlate to "real" values in fuel maps like Injector PW.

I guess this leaves me with these questions;
1. Is my thinking on this flawed - is there some concept or logic to these tables that I'm not grasping?
2. If my thinking is valid, am I overlooking some tables that define how AFR values correlate with Injector PW (or timing) or is it simply that they haven't been defined for my ROM?

I'd really appreciate some knowledgeable folk chiming in on this to either set me straight or validate my thinking here because it's something that I find bloody frustrating at the moment!

Thanks,
Windza


Top
 Profile  
 
 Post subject: Re: Why are "open loop" table values expressed in terms of A
PostPosted: Sat Oct 08, 2016 8:42 am 
Offline
RomRaider Developer

Joined: Wed May 20, 2009 9:49 pm
Posts: 7314
Location: Canada eh!
The table description describes how the values are used.
The ECU deals with fuelling with reference to lambda (AFR is used since we are dealing with gasoline). Injector scaling defines lambda = stoich@1g/rev.
If you wish to see the table in the ECU processed lambda offset values just switch the table scaling from Default to Raw Value. Convert the raw values by multiplying by 0.0078125 to get the lambda offset.
Or add this scaling entry to the 32BITBASE def in the Primary Open Loop Fueling table definition under the existing scaling entry.
Code:
   <scaling  name="natural" units="lambda offset" expression="x*.0078125" to_byte="x/.0078125" format="0.000" fineincrement=".001" coarseincrement=".1" />


Top
 Profile  
 
 Post subject: Re: Why are "open loop" table values expressed in terms of A
PostPosted: Sat Oct 08, 2016 5:06 pm 
Offline
Experienced

Joined: Sun Jul 13, 2014 6:12 pm
Posts: 111
The way I see it is that the average person understands the AFR values in the tables so it's a simple way of displaying the map. I guess to some extent that they are target values, however it is easy enough to view them as enrichment/base fueling values and adjust to suit. 14.7 (stoich) is the base value and any values richer than than that add the right amount of fuel based on the load being correct, hence you can use MAF scaling to correct the load to match up commanded AFR to output or just add/subtract a % to the AFR values to hit the AFRs that you would like to.


Top
 Profile  
 
 Post subject: Re: Why are "open loop" table values expressed in terms of A
PostPosted: Sun Oct 09, 2016 10:08 am 
Offline
Senior Member

Joined: Thu Aug 03, 2006 10:40 am
Posts: 1934
Windza wrote:
but it feels to me like we're missing some tables that define how the supposed AFR values correlate to "real" values in fuel maps like Injector PW.


well, what you're talking about isn't a table, it's the background fueling algorithm that takes charge air mass and target lambda to arrive at a requisite fuel mass. ipw is then calculated via a host of compensation factors (like long term fuel trims, fuel density, injector scale/latency/trims, etc).


Top
 Profile  
 
 Post subject: Re: Why are "open loop" table values expressed in terms of A
PostPosted: Mon Oct 10, 2016 9:02 pm 
Offline
Newbie

Joined: Sat Nov 14, 2015 7:57 am
Posts: 2
dschultz wrote:
The table description describes how the values are used.
The ECU deals with fuelling with reference to lambda (AFR is used since we are dealing with gasoline). Injector scaling defines lambda = stoich@1g/rev.
If you wish to see the table in the ECU processed lambda offset values just switch the table scaling from Default to Raw Value. Convert the raw values by multiplying by 0.0078125 to get the lambda offset.
Or add this scaling entry to the 32BITBASE def in the Primary Open Loop Fueling table definition under the existing scaling entry.
Code:
   <scaling  name="natural" units="lambda offset" expression="x*.0078125" to_byte="x/.0078125" format="0.000" fineincrement=".001" coarseincrement=".1" />

Awesome information... not sure why I didn't think to check the raw values. Just took the table at face value and assumed the ECU was processing actual AFR values - not that it changes the end result but something I'll keep in mind when reviewing other tables and journey deeper down this rabbit hole ;-)

Kodename47 wrote:
The way I see it is that the average person understands the AFR values in the tables so it's a simple way of displaying the map. I guess to some extent that they are target values, however it is easy enough to view them as enrichment/base fueling values and adjust to suit. 14.7 (stoich) is the base value and any values richer than than that add the right amount of fuel based on the load being correct, hence you can use MAF scaling to correct the load to match up commanded AFR to output or just add/subtract a % to the AFR values to hit the AFRs that you would like to.

Makes sense... AFR's mean something to me where as I'm not quite calibrated on Lambda values yet though I'm sure that's going to change fairly quickly!

ride5000 wrote:
well, what you're talking about isn't a table, it's the background fueling algorithm that takes charge air mass and target lambda to arrive at a requisite fuel mass. ipw is then calculated via a host of compensation factors (like long term fuel trims, fuel density, injector scale/latency/trims, etc).

And I think you've put your finger on what I've been trying to wrap my head around - my traditional impression of "Open Loop" fueling had me thinking the values in the "Primary Open Loop Fueling" table would be IPW or something more directly related to fueling than AFR/Lambda.

With the information you guys have provided, I now understand the logic behind them. I'm not quite sure I fully understand why Subaru would use AFR/Lambda values in place of something like IPW when you consider the ECU has no way of knowing if it actually achieved those targets while in OL.
The table description in ECUFlash touches on this a little in the statement "Because there is no feedback in open loop, the actual AFR may differ from the values presented in this table.".
For me this begs the question, then why use AFR when IPW would be something more tangible?

If I had to guess, I imagine the answer to this might lie in how Subaru develops their factory tunes during the development phase... no doubt they're using far more sophisticated combustion gas analysers than what is fitted to production engines so perhaps the AFR/Lambda values *are* actually relevant when the engine runs in their test cell environment and they're using them to tune for a production ROM accordingly?

Either way, just these few short posts have been very informative for me - I genuinely do appreciate you guys taking the time to reply - thanks!


Top
 Profile  
 
 Post subject: Re: Why are "open loop" table values expressed in terms of A
PostPosted: Tue Oct 11, 2016 7:32 pm 
Offline
RomRaider Developer

Joined: Wed May 20, 2009 9:49 pm
Posts: 7314
Location: Canada eh!
IPW is injector hardware dependent, so it will change if you change your injectors larger/smaller. By changing just one value, the injector scaler you don't have to touch any table that is based on lambda.
If you change fuel type, again just change the scaler. These are a couple of reasons I can think of for doing it this way.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Style based on FI Subsilver by phpBBservice.nl