DIYEFI.org Forum

EDIT : Moved/split from AFR table size thread.

Good question, Fred. How much [AFR table resolution/size] is too much?

There's sort of 5 'load zones', excluding startup and idle.

decel a lot - decel a little - steady state - accel a little - accel a lot

The thing to understand though, is that Xtau (wall wetting and vaporization) is fully interleaved with any AFR scheme.

If for example the driver moves the go pedal from 'accel a lot' to 'decel a little', and the ECU hopes to track the AFR during and immediately after the transition, then the various Xtau accumulators must accommodate on the fly. That is a lot of math, right now.

The lift-throttle condition alone is sometimes enough computational work to overrun the processor with managing even a single AFR.

It may not be practical for the processor capacity to include even a modest amount of additional degrees of exactness.

- Jim

Well, the AFR/Lambda will be a single figure looked up from the table based on current conditions just like VE will be. Hence there will only be one value going into any such calculations if/when they are implemented. What you are trying to say though (if I understand correctly) is that the algorithm will be needing to track past AFR/Lambda numbers in relation to present and past/previous loads etc.

What I don't see is why AFR matters to xtau at all. It is only concerned with how much fuel is commanded and how much is removed from the walls and how much is deposited there. Why does it need to know AFR to do this? It seems to me that it doesn't unless you are somehow going to relate rates of evaporation to saturation of fuel in the air or some such thing.

Anyway, this is off topic for this thread IMO. I'll split it into it's own thread so it can enjoy the attention and focus that it deserves.

Fred.

Hi Jim

Very curious info

Do you have some good references so i can get up to speed on that? (not the X-tau in general, which is easy to find, but rather intricacies of applying it for the scenarios you describe)

Also please elaborate more on "interleaved with AFR scheme"

By tracking AFR, i suppose you mean keeping track of it within the computational model (X-tau, etc) as opposed to feedback through WBO2 and such.

unrelated to freeems:
What kind of computational capacity complications/challenges do you expect in implementing this optimally?
What microcontroller architectural advantages do you think would be beneficial for these computations? (32bit, hw divide, single cycle multiply, hw bitfields, faster branches, etc)

Thanks
Alex