Power regulation related subpage of GenBoard/UnderDevelopment/FirmWare
A proposed power-target sublayer that consolidates
- idle-control
- fuelcut
- redline
- overrun
- ALS
- launch-control
- traction control
- cruisecontrol
all are some way of controlling power, with a combination of
- ignadv
- BoostControl
- EGR
- fuelcut
- ignitioncut
- event-skipping
- direct air-valve control
- (small) idle stepper or solenoid
- (big) InTake/DriveByWireThrottle
Unified fuelcut - minimalistic
- we have rev_limit fuelcut
- overrun fuelcut and fuelresume
overrun can be used to help race-start: Setting overrun fuelcut and fuelresume RPM to 3700 / 3400 RPM and applying a switchbutton that grounds the TPS signal. This way during race-start the rev is ideal for fast starting. (otherwise it is almost impossible to manually maintain the desired RPM with throttle and no load: the throttle is usually very touchy). The idle-air valve will close but who cares the throttle is opened anyway. Don't let the idle controller retard the ignition too much (a few degrees are OK).
After starting, switchbutton released, TPS signal back to normal, so rev-limit is raised to redline.
It would make sense to use a separate digital input channel (GenBoard/UnderDevelopment/DigitalInputs) instead of grounding the TPS signal: so 3 rev limits are possible.
| Condition | fuelcut RPM | fuelresume RPM |
| if TPS < tps_thresh | overrun_fuelcut | overrun_fuelresume |
| else if the racestart switch is ON | racestart_fuelcut | racestart_fuelcut - (overrun_fuelcut - overrun_fuelresume)) |
| in any case, if they are higher, they lowered to | rev_limit | rev_limit - (overrun_fuelcut - overrun_fuelresume) |
- So if someone forgets to configure racestart_fuelcut the revline will save his engine.
- Better name for racestart_fuelcut?
- overrun_fuelcut - overrun_fuelresume should be 100..400 RPM (we can administratively maximize it to 800 RPM) and I see no reason to have different rangesize for the 3 cases
- EGT Based enrichment Powerful engines may need this, as they keep getting hotter with time. This would be a EGT vs enrichment % table, 3..8 cells, a unplugged/broken sensor should render full enrichment
- Simple implementation done: ALS - AntiLagSystem. Needs an external switch (to control its on/off state), IAC control, EGT sensor, and a strong exhaust system. It's under development, using a simpler approach, without IAC and EGT.
- Launch Control Light - Almost the same as the standard launch control, but not as advanced. By adding a revlimit to the current ALS function, the user can choose between only a revlimiter (no/low boost off the line), or building up boost by changing ign.advance and adding more fuel. To enable, the clutchswitch has to be activated, and the launchcontrol is enabled with a second pushbutton, So that it doesn't activate the next time clutch-switch is activated. A separate boost-target could be set while this is activated as well.
- button with GenBoard/UnderDevelopment/DigitalInputs activates lowered (configurable) redline
- driver presses TPS but not to 100% (TPS=10% is enough in most cases to rev engine to 4000RPM without load; but TPS anywhere between 10..95% is perfect)
- at launch-time, (besides coupling the clutch) driver presses TPS fully 100% (this is very natural and efficient) deactivating launch control so (configured) revlimit is max again.
- Full Power Shift Cut - If the driver shifts, without using the clutch, at full throttle, the MS should cut the spark while the shifter is moving. Needs a gearshifter motion-sensor input.
- Launch Control - Widely used feature to help the good start. On the startline, the driver needs to pull out the clutch, and press a button on the steering wheel. Then give a full throttle. The ECM must rev-limit (with ign+inj cutting) the engine on the configured limit, while the clutch is being pulled. Needs two input lines and 2 switches. (Note by hackish:) This can be accomplished without any extra hardware if you have VSS enabled. Check the vehicle speed sensor and if you're going less than X km/h enable the launch rev limit.
Idle control
- iac_step_seq : config variable dropped, only 1 bit left in iac_conf (for 0xC8 / 0xD9) since that should be enough for everyone (2 directions possible)
- iac_period: new variable, upper 4 bits are reserved (use 0); lower 4 bits are the period ( 1..16 msec ?)
- iac_conf : the 4 bits for iac period moved (see above).
- "iac step direction" bit added
- bit added for twin-PWM-solenoid type
Note that number of bytes (2) and position in config remain.
Some iac stepper valve that drifts very heavily (only seen with a unipolar Mitsubishi IAC, where wiring has to be checked actually: min 20V flyback required for the unipolar channels as low voltage flyback will prevent correct operation, just think about how the coils relate) might benefit from a MAP-target iac implementation, where the ECM watches MAP while stepping IAC.
faster control for solenoid and twin-PWM-solenoid type
When the iac movement is significant (position changes a lot: this can happen eg. when the air conditioner clutch engages and RPM drops) it would be faster to apply full power ON/OFF (in the direction of the change) for time=configurable_constant * amplitude_of_iac_position_change
before the PWM duty is applied to hold the solenoid in position.
Separate AlphaN table
Currently RPM < hybrid_rpm_a of the j[] is TPS-indexed data; RPM > hybrid_rpm_m is MAP-indexed, and it's mixed (blended) in between those RPM-s.
- separate table would allow changing hybrid_rpm_a and hybrid_rpm_m thresholds without touching the VE (j[]) table.
- also, limp-home by TPS would be possible, should the MAP be lost
- Separate AlphaN table would allow superior precision TPS acceleration enrichment. With the traditional practice, the TPS acceleration enrichment is very RPM and TPS dependent. (TPS is highly nonlinear at low RPM)