Log target AFR?

NSFW · **Joined:** Wed Nov 22, 2006 10:23 pm **Posts:** 397

dynamix wrote:

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.

The stock sensor is only accurate near stoich, and the ECU only uses it (by definition) in closed-loop operation. That makes it good enough for MAF adjustments based on data gathered in closed-loop.

The stock sensor isn't even used during open loop, because it's not accurate. That's where widebands come in. It would be nice to show, in the log, what the AFR was supposed to be at any given time, and that's the point of my original post. I want to know how close the actual AFR is to the AFR indicated in the table.

One could use this information to revise the MAF scaling, but that is not what I'm interested in, at least not initially. I just want to know how much I can trust the target AFRs as displayed in the fuel map. If they're way off, it might merit an adjustment to the MAF scale, but perhaps not. That would depend on how accurate the MAF scaling is in closed-loop, and on how confident I am that the injector parameters are correct, and so on.

merchgod · **Joined:** Wed Mar 29, 2006 10:38 pm **Posts:** 4224

NSFW wrote:

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.

Well, it would be interesting if this new obdii parameter was calculated in open loop. Although "target" would be misleading in open loop, I think, but that is just semantics.

The min/max thresholds are used for the OL offset not the final IPW calculation (although there may be other IPW threshold I'm not aware of - there are some cases were the IPW is a constant). The thresholds are more than just single set of min/max, some are applied before other compensations are applied and some after (these thresholds can also be variable - for example, a minimum offset based on ECT which calls for a higher minimum as ECT decreases). I really haven't messed with fueling as much as I'd like, but there is compensation based on IAT, there's also compensation based on throttle (near WOT) that I need to add for the 16-bit ECU (already added for the 32-bit ECU).

LGT-3-6 · **Joined:** Wed May 24, 2006 8:11 pm **Posts:** 187

On further thought, there is no point to logging this from the ECU. Romraider should be able to interpolate these values from the loaded map on the fly. I want immediate feedback for tuning. My experience with datalogs and the mathematical approach is that it's not very fun and introduces all sort of questions about what was actually going on. This would address the OP's request, I assume. Also one less logged value, which is better for logging in general.

LGT-3-6 · **Joined:** Wed May 24, 2006 8:11 pm **Posts:** 187

I'll attempt to code this (first real venture with java) if someone tells me how to get sync'ed with svn

NSFW · **Joined:** Wed Nov 22, 2006 10:23 pm **Posts:** 397

LGT-3-6 wrote:

On further thought, there is no point to logging this from the ECU. Romraider should be able to interpolate these values from the loaded map on the fly. I want immediate feedback for tuning. My experience with datalogs and the mathematical approach is that it's not very fun and introduces all sort of questions about what was actually going on. This would address the OP's request, I assume. Also one less logged value, which is better for logging in general.

I hadn't thought of that, but you're right. I'd be just as happy with doing this through SSM though. I mostly just want to know how close the actual AFR is to the AFR in the table so this wouldn't be part of every log I take, just an occasional sanity check with this, rpm, load, and WBO2 for a sanity check.

Thinking out loud here... it would be pretty interesting to (also) be able to log the desired AFR before and after the corrections are applied. It would be interesting to see how much impact those corrections have.

Merchgod, can we agree to call it desired AFR?

As in, what the tuner desired when they set up the fuel table.

RomRaider

Log target AFR?

Who is online