Firstly the way each of these is calculated needs to be configurable to keep them from reacting inappropriately to natural fluctuations. That can be achieved with a time period over which it is calculated.

Additionally, each could be handled as a percentage change rather than absolute, this could be configurable or drive a whole separate enrichment instance.

Then comes the amount of fuel correction to add given a certain delta in a certain input. Each should have its own configuration totally independent of the others. Each will be calculated separately and added to the final value such that changing one does not affect another (as it would if they were multiplied together).

Whatever enrichment (or enleanment) is determined will need to last longer than the calculation frame of reference. Therefore it will need to be initially calculated and then have some form of decay applied.

We will need to handle the case where a transient occurs and then another transient occurs before the last has faded completely away. Will one nullify the previous or wil they add together, and if so, how frequently can they be calculated fresh while maintaining a valid history. If one nullifies the last, then under what conditions should that occur, IE, if the new delta is smaller than the last, just ignore it as it's just the trailing edge of the same signal for which we already calculated what to do? If so, this threshold either needs a timeout or a decay too.

How fine do we need the control over decay to be? Should it be a tabular curve? Should it be a calculated curve? If so, which shape? Should it be based on time? Or on output event count? Or configurable to either? Or multiple instances and both?

We're going to need something that scales for load, something that scales for RPM and something that scales for the delta itself. Some of these might be taken care of naturally in the calculation's non-linearity, others may need a curve or set of curves.

(01:13:46) johntramp: FreeAir: posts like this viewtopic.php?f=8&t=1448 may be nice to have a quick overview of what they are for(01:17:30) FreeAir: urr, what do you mean "what they are for" ?(01:18:05) johntramp: ie what Simple Transient Enrichment is (01:18:19) johntramp: what is the problem it is solving(01:19:46) FreeAir: johntramp: do you know what it is?(01:20:30) johntramp: i know what it is but not why it is needed(01:22:01) johntramp: and what is Simple Transient opposed to Advanced Transient(01:23:29) FreeAir: simple means carby pump style(01:23:38) FreeAir: not cumulative history wall wetting style(01:23:39) johntramp: ah(01:23:59) FreeAir: needed: if you don't have it, and you stab the gas suddenly, you'll go a little lean for a split second(01:24:04) FreeAir: and the car will stumble(01:24:10) FreeAir: on a good setup it's barely noticeable(01:24:14) FreeAir: on a shit setup it's horrible(01:24:39) johntramp: yes, i know that but i don't know what it is physically compensating for(01:24:57) johntramp: i mean, why does it need more fuel than is given by the VE table?(01:24:58) FreeAir: fuel evaporating and condensing on the ports(01:25:08) FreeAir: and delays between reality and sensors and math and outputs(01:25:35) johntramp: because that is what you will need to model, right?(01:25:51) FreeAir: model?(01:26:10) johntramp: well, you need to know how much fuel to add based on something(01:26:19) FreeAir: [01:22] <@johntramp> Advanced Transient(01:26:28) FreeAir: modeling = wall wetting = advanced(01:26:50) FreeAir: simple = sense a change, dump more fuel in asap for a while

We will need to handle the case where a transient occurs and then another transient occurs before the last has faded completely away. Will one nullify the previous or wil they add together, and if so, how frequently can they be calculated fresh while maintaining a valid history. If one nullifies the last, then under what conditions should that occur,

New transient nullifies the last. If not I see run-away conditions hard to avoid.

Fred wrote:

IE, if the new delta is smaller than the last, just ignore it as it's just the trailing edge of the same signal for which we already calculated what to do?

I'm thinking if the new transient is less enrichment (even negative enrichment) than the current decayed value of the past enrichment then it gets ignored. If it is more enrichment, it nullifies the last transient enrichment.

(I know this favors rich conditions.)

Fred wrote:

How fine do we need the control over decay to be? Should it be a tabular curve? Should it be a calculated curve? If so, which shape?

I think a calculated shape would be better than what most EMS solutions have and IMO would be plenty good. A tunable curve could be done but seems overkill to me. Although, I'm sure someone would want it tunable.

Fred wrote:

Should it be based on time? Or on output event count? Or configurable to either? Or multiple instances and both?

I went over it slowly and didn't really notice it, I may go over it again, but I would also say a curve for decreasing the amount of enrichment as the engine is at different rpms. Higher revs are unlikely to need enrichment compared to lower revs.

MrOnion and I have been thinking (and talking) about this a fair bit in the last 2 days!

The logic needs to be something like this:

Decay existing enrichment

Look up the candidate new enrichment

New enrichment positive and greater than old, replace

New enrichment negative and greater (in magnitude) than old, replace

New enrichment positive and old negative, or vice versa, replace

Otherwise use existing enrichment

Decay likely needs to come from a 2D table looked up by RPM as it will be relevant for a very short time at high rpm, and longer at low RPM.

Any additional feature later might be to zero out an enrichment after N time periods rather than just decaying it to nothing eventually.

Enrichment depends on all of:

RPM

TPS

DTPS

How to do a 4D table lookup of some sort? X 3D combined? X 2D combined?

For TPS, should it be previous, mean, or recent? IE, where in the movement do we consider it to be for lookup purposes?

Initial cut can be lookup by DTPS vs enrichment in a 2D table axis values from negative max to positive max. Thus a zero region can exist in the middle (to prevent false positives), and neg/pos can easily be asymmetric. This table will be signed 16 bit for both axis and value. This may be sufficient combined with RPM based decay.

In terms of sampling we need to:

Prepopulate the stored ADC lookup value at boot to prevent a large initial action. The alternative is a set-once flag checked every time. Better at boot.

Take a new sample every time-delta and store it in the new one, after moving the last new one into the old one.

Set a flag for the info to be processed elsewhere

In terms of processing we need to:

Operate only when flag set

Clear the flag

Calculate previous and current TPS values (this might be independent of the one in the log so the log one can be updated constantly for better data)

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum