Wall Wetting, XTau and other methods.

Official FreeEMS vanilla firmware development, the heart and soul of the system!
Post Reply
MotoFab
1N4001 - Signed up
Posts: 307
Joined: Thu May 29, 2008 1:23 am
Location: Long Beach CA

Wall Wetting, XTau and other methods.

Post by MotoFab »

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
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Wall Wetting, XTau, and other methods.

Post by Fred »

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.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
ababkin
LQFP112 - Up with the play
Posts: 215
Joined: Tue Jan 15, 2008 5:14 pm

Re: Wall Wetting, XTau and other methods.

Post by ababkin »

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
Legal disclaimer for all my posts: I'm not responsible for anything, you are responsible for everything. This is an open and free world with no strings attached.
Post Reply