RomRaider

This is really a logger definition feature request... Is there a memory address that could be used to log the target AFR while in open loop? It would be interesting to compare the target AFR to the real AFR from a wideband sensor, to get an idea of how close they are (or aren't) without having to look up the target-AFR cells in the fueling table after-the-fact.

Actually it would be nice for romraider to automatically apply the difference back to the MAF scale, no jumping to excel and vbscript, etc.

It will (and does) in the test release. there is a MAF scaling tool in there which is excellent. It gathers data whilst you are driving along from the short and long term fuel trims and you can apply it to the MAF scaling in one click.

there's no target AFR in open loop, hence the term "open loop". The underlying value in the fuel map is just an enrichment offset applied to base stoich fueling. But I understand what you are getting at. You would like to log the final enrichment offset after all compensations are applied and converted to an estimated AFR. Problem is, it gets hard to follow after a certain point. I don't if there is a single variable that would represent this, short of just the fuel map result with only the ECT compensation applied.

Subaru disagrees. CARB has a regulation which applies to all 2005+ cars that implement ISO 15765-4 (OBD-II via CAN) which requires them to report "commanded equivalence ratio." As you can see in the list of OBD PIDs supported by the 2007 Legacy GT, Subaru uses PID $44 - A/F target lambda - to satisfy that CARB requirement. Perhaps, when a Subaru CAN ECU ROM image is published, it will be possible to track down how the ECU determines A/F target lambda for reporting purposes.

I've been using this for a while. It's useful, but not that useful.

1. It doesn't use wideband data (hence this thread about open loop)
2. It doesn't do well when you have contiguous points which are vastly different, ends up as distorting other points due to the polynomial fit. After the first sweep I would use the graph it made visually and adjust manually.

Relating to emissions, that would seem to me to be only the target in closed loop, unless you have information otherwise.

is your wideband that different to the std sensor - mine isnt.

To be honest though, it is irrelavant as the ECU targets the std sensor reading - I thought that was the point of the question.

PID $44 A/F target lambda is reported regardless of whether PID $03 fuel status indicates OPEN or CLOSED. It is also saved as part of the Freeze Frame data whenever a trouble code is stored.

So would PID $06, it would just be reported as 0.

That's because STFT actually is zero during open loop. A/F target lambda will never be zero.

How are you going to have a "target" in open loop? So, that parameter reading zero in open loop would make sense. What is the ECU going to do with target lambda in open loop? What is the average mechanic going to do with that information? I'm not trying to argue with you, it just doesn't make sense that anything would be reported in open loop unless the parameter was just poorly named.

Target lambda in open loop means the lambda the ECU is trying to achieve. The fact that the ECU doesn't know for sure in open loop whether it's actually hitting its target is irrelevant.

In open loop, target lambda is determined by first obtaining a value from the fuel table, interpolated for RPM and load. Then ECT compensation is applied. Then it is added to 1.0 to obtain target F/A equivalence ratio. Divide that into 1.0 and you have target lambda. Note that LTFT and STFT are NOT part of target lambda.

That really wouldn't be the final "target" as there are many other factors involved than just compensation based on ECT (including min/max thresholds and many other compensations). The farther you go down the chain towards the ultimate calculation of IPW, the harder it becomes to follow (for me anyway). So, yes, it would be possible to add a "target" OL estimated AFR with just ECT/throttle compensation applied, but much beyond that, no, at least at this point.

Are you saying that your description of target lambda as it applied to this new obdii parameter is from documentation of this specific parameter or are you guessing that this is its function?

That's how I see it as well. The target AFR just happens to be encoded as an offset from stoich but there's still a target AFR for any given conditions. (And RPM and load are very significant conditions.)

I confess to being a little curious about the corrections that get factored in after the initial lookup in the fuel table, though. My barely-educated guess is that they probably mostly fall into two buckets:

1) Corrections to bring the actual AFR closer to the target, based on information not available when the enrichment table was created. How many of those inputs come from real-time sensor information?

2) Corrections to keep the final IPW within a sane range, for example if a sensor goes bad or if different sensors are in wild disagreement.