##  ##  
 ##  ##  
 ##  ##  
  ####   
   ##    
         

 _   _ 
( ) ( )
| | | |
| | | |
| (_) |
(_____)
       
       

   ____  
  / __ \ 
 | |  | |
 | |  | |
 | |__| |
  \___\_\
         
         

 _   __
| | / /
| |/ / 
|    \ 
| |\  \
\_| \_/
       
       

 _       
( (    /|
|  \  ( |
|   \ | |
| (\ \) |
| | \   |
| )  \  |
|/    )_)
         

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
'''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 * fuelcut_min_kpa Currently <code> if( RPM > overrun_fuelcut && (TPS < iac_tps_threshold)) || ( kpa < fuelcut_min_kpa){ then cut fuel; } </code> This works very well normally, but does not work well for broken IAC (which is not uncommon in racing). The following is a proposed candidate, under evaluation: <code> if( RPM > overrun_fuelcut && (TPS < iac_tps_threshold || kpa < fuelcut_min_kpa){ then cut fuel; } </code> In the latter case, overrun_fuelcut would be set much lower for a normal setup (IAC operational). No difference in normal operation, but it would make limp-home harder with a broken TPS sensor. 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))|| ||else if the sequential gearbox switch just activated in the last 300msec|| ...= appr 1200 RPM || ....=appr. 1000 RPM || ||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. We have launch control implemented on a Peugeot NA racecar (that is actually at '''position 1 in the Hungarian rallycross series''', though budget is only 1/4 of several competitors) using overrun fuelcut. TPS is fed from TPS5V (the main point is the 270 Ohm limiting resistor) and the "launch activation" button grounds TPS signal so the GenBoard applies overrun fuelcut (set at appr. 4000 RPM) though the TPS is mechanically pressed (butterfly opened). Plans are to change this a bit, because operating button on dash and handbrake simultaneously is hard (moving button to handbrake would work, but there is a better way, read on): * 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 spark must be cut off while the shifter is moving. Needs a gearshifter motion-sensor input. We must implement this immediately. We need to '''apply igncut for 250..300 msec (configurable) after the sequential gearbox activates an input (mcp3208channel6 or mcp3208channel7 used as digital input; the gearbox only activates this input at upshift, eg 3 => 4, not at downshift. The length of pulse seems a bit uncertain, so the activation start-point must be used). We must implement this in stable1_0 2005-10-18. Take care that early_dwellstart might activate the coil timed from previous igndeact. In this case, we don't want fried coils, do we ? We can easily drop ign-activating from the early_dwellstart branch, but we can only drop ign_trigger_here() call if early_dwellstart was not activated. * '''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) * higher internal TPS resolution would help somewhat (the MAP is processed internally with an extremely good resolution; the TPS is processed with normal resolution). might belong elsewhere: A new variable for '''VE-learning''' (maybe dropping an old, unused variable): '''target ego-correction'''. Only those will tune to egoc=+0% (the current target for VE-learning) who will race without WBO2 (for whatever reason). Anyone using WBO2 all the time want to tune VE a little richer, so ego-correction is normally -5 .. -10%
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.