The issue for implemented this is here: http://issues.freeems.org/view.php?id=164

The input variables we have to work with are:

• Delta TPS in % per time unit
• Delta MAP in kPa per time unit
• Delta RPM in RPM per time unit

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.

Next post, possible starting point.

Fred.

I'm going to use DTPS as an example, but the others should be identical in their setup and adjustment.

Settings and variables:

• Period over which DTPS is calculated: <some range of practical values>
• A minimum threshold to stop noise destabilising pulsewidths when it shouldn't
• A last-activated-on-value variable
• A last-activated-on-timestamp variable
• A 2D curve for decay of last-activated-on-value over time OR over output event counts
• A 2D curve for multiplying the DTPS value to determine the change in fueling over time OR over output event counts
• A single value to scale the previous curve for negative transients to limit or reduce the scope of fuel reductions using the same basic curve - review to own curve later?
• A configuration for each curve to decide which value is used for lookup, ie, time or output event count
• A configuration for each instance to decide whether it uses a linear delta or a percentage delta
• For time based curves we may need an RPM scale curve too, however this is likely nullified by using output event counts instead.

This is a very alpha first cut of the design. Constructive criticism is welcome especially from those with extensive industry experience.

Fred.

Bump for ideas/comments/abuse/well-meaning-offtopic, etc :-)

(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

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

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.)

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.

At first blush I feel time-based would be fine.

Thanks Ben!!! :-)

Re the calculated shape vs. curve, the curve is the easy option, and more flexible, so likely that'll be the first cut.

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.

So a small 3D curve? Or a pair of 2D curves that combine?

pair of 2d curves that combine
RPM
% total of enrichement

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)
• Calculate the DTPS value
• Perform the steps in the first list, above.

3:11am, time for a brief sleep and then more work.

Fred.