Acceleration Enrichment can be derived from two tables.
- RPM Acceleration Enrichment, RPM vs Enrichment PW vs Decay Time.
- TPSaccel Enrichment Scalar, TPSaccel (dv/dt) vs Scalar%
Transient fuel is the output of the RPM Acceleration Enrichment table * TPSaccel Enrichment Scalar.
Pulse width enrichment time
RPM Acceleration Enrichment
| RPM | Enrichment PW | Decay Start |
| RPM3 | et3 ms | ds3 ms |
| RPM2 | et2 ms | ds2 ms |
| RPM1 | et1 ms | ds1 ms |
| RPM0 | et0 ms | ds0 ms |
TPSaccel Enrichment Scalar
| TPSaccel | Scaling |
| dv/dt2 | as2 % |
| dv/dt1 | as1 % |
| dv/dt0 | as0 % |
So with With the following entry:
| RPM | Enrichment Time | Decay Start |
| 5500 | 4.4 | 0.8 |
| 4000 | 4.1 | 0.8 |
| TPSaccel | Scaling |
| 50 | 100% |
| 25 | 65% |
Accelleration from 4500rpm with a TPSaccel of 35 would give:
RPM Enrichment of 4.2mS decay start 0.8ms
Scaled Enrichment 4.2mS * 0.79 = 3.318ms decay start 0.8ms * 0.79 = 0.632ms
This is a few things that Dave and I spent some time discussing on the tour. -Jörgen
Req_fuel based
The acc enrichment must be based on req_fuel, we don't want to mess with acc enrichment on each and every system and it's not needed if it's done right.
The current v/s bins and the acc enrich amount values can possibly be fixed. In any case it should be changed from v/s to %/second and the enrichment amount should be set in % of req_fuel. If these tables are uneditable and the values well choosen the acc enrich can be set with the tables mentioned below. If we have 3-5 editable tables affecting the result it's a nightmare to support and debug.
Decay rate
decision:
- fixed decay rate
- decay_rate( RPM )
- faster at higer rpm
- decay_rate( load, RPM )
- may or may not be redundant. But a 4X4 table for this is a small cost and it may be made uneditable later if we find that we can get away with it.
Many systems let the accel enrich decay every cycle to make the decay time shorter at higher rpms. I don't know if that is the right way to do it.
Also, while we already have much info to calculate the enrichment amount, the decay parameters need extra information (fortunately good rule-of-thumbs will be possible).
Sustained acc enrich
It is also important that the acc enrich is timed from the last occurrance of the acc enrich trigger. With a medium fast throttle application, maybe 1.5s from 0 to 100% throttle the acc enrich must stay on for the entire 1.5s.
Throttle opening vs RPM and angle.
The unlinear response of a throttle butterfly and the fairly linear function between the throttle opening and intake pressure is likely to force us to use a max TPS value that is allowed to trigger an acc enrich. A 3X3 TPSXRPM table with multiplier values will allow us lots of freedom in this regard. (This may however be redundant as the load based acc enrich will give similar results)
- At low rpm even a small throttle opening will let the intake pressure reach almost atmosphere pressure. At higher rpm a larger throttle opening is needed to saturate the plenum.
- A stab from 20-40% throttle at 2k is unlikely to require any acc enrich as the main load variable and the engines fueling requirements are not changed.
- The same stab from 20-40% at 5k is however likely to cause a very large change in intake pressure and fuel requirements.
- If the throttle angle is proportional to the TPS the free flow area will not be very different from 50-100% throttle and little or no acc enrich is needed regardless of rpm in this region. This is also covered with the mentioned 3X3 table.
Acc enrich vs load and rpm
We also need an acc enrichment table with load and rpm. In this table we have a multiplier for the amount of acc enrich needed for this load. Considering the tricks sometimes needed from idle and the sometimes bad vaccum of some engines I think that a 4X4 table is best for this. If it weren't for the sharp increase in vaccum from idle to a few hundred rpm over idle on some engines and some engines high fuel requirement when they are expected to come off a low and lean idle quickly.
"Throttle opening vs RPM and angle" and "Acc enrich vs load and rpm" using the info we already have to make configuration much simpler and more precise
This information is already there in the VE table.. The TPS is converted to load, than the delta-VE can be looked up from the VE-table useing the delta-load (and the appropriate extra pulsewidth applied). Because of various effects, a multiplier is needed so 1.1 .. 3x higher delta-pw is applied than what comes from the looked up delta-VE.
This TPS => simple in case of AlphaN, and a bit more complex in speed-density: (but still rather simple), caracterized by 0..1 extra value:
- throttle relative size (the RPM at which the response gets more linear moves up as this increases; easy to set this from 1..2 low-RPM TPS->load values (proposal: TPS% at which the load reaches 50% of the max value at appr 2000 RPM, usually 4..40%, where obviously 4% means huge throttle, 40% means tiny throttle)
- or even possible to learn (or find out from the log) or (in case of AlphaN) the shape of a low-RPM "VE-column"
- Note that the oval-ness of the throttle linkage does not play in the equation, it only effects the needed gas-pedal linear motion. But the TPS measures the angle after this oval-linkage took its effect.
Load difference before - after transient
The load difference before and after the transient is important for knowing the amount of acc enrich needed. But as we need to apply acc enrich without delay after noticing a transient we have a problem. One solution is that we can allow the before-after conditions determine the speed of the decay. This will also let us decay very quickly if the throttle is returned to the original condition immediately after the stab. This is possilby the most important (and simplest to get right) use of the before-after sensing.
Overrun fuelcut
The overrun fuelcut can often cause a dangerous transient condition as it is now. I haven't noticed as few people I know release the throttle entierly during shifts while accelerating hard. I noticed that the last car I tuned detonated easily right after shifts, it was very obvious what happened when watching the logs.
- why is there air with a released throttle ? why do they use overrun fuelcut than ?
- A small delay between the overrun_fuelcut trigger and the actual fuel cut will likely NOT prevent this.
- to prevent it, we need to predict that the throttle WILL be pressed and apply fuel (stop the fuel-cut condition) before the TPS actually moves up - impossible without a InTake/DriveByWireThrottle
- It's true that it will not solve the problem, but the fuelcut depleat the intake of stored fuel. It ventilates it until the walls are dry. This cause the walls to 'eat' some of the first fuel you send into the engine and the acc enrich will have to be very large. Compare turning acc enrich off on a fairly big engine and set it to idle at lambda =1 but set all other load sites to lambda=0.9. Now stab the throttle. Now set the idle lambda to 0.9 as well and stab the throttle.
Also see: GenBoard/UnderDevelopment/AccelerationEnrichmentTable