View unanswered posts | View active topics It is currently Sat May 30, 2020 6:41 am

Reply to topic  [ 3 posts ] 
Wall Wetting, XTau and other methods. 
Author Message
1N4001 - Signed up

Joined: Thu May 29, 2008 1:23 am
Posts: 307
Location: Long Beach CA
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

Wed Jul 02, 2008 9:15 am
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15361
Location: Home sweet home!
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.


_________________ - where Open Source means Open Source, and Free means Freedom - 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!

Wed Jul 02, 2008 9:30 am
Profile WWW
LQFP112 - Up with the play
User avatar

Joined: Tue Jan 15, 2008 5:14 pm
Posts: 215
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)


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.

Wed Jul 02, 2008 5:59 pm
Display posts from previous:  Sort by  
Reply to topic   [ 3 posts ] 

Who is online

Users browsing this forum: No registered users and 2 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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.