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

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

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

 _   _ 
| | | |
| | | |
| | | |
| |_| |
 \___/ 
       
       

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

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 ** PartialFuelcut * 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 ---- MembersPage/GaborRacz: '''Improved AntiLagSystem implementation''' waiting for review and commit to stable branch. Needs an external switch (to control its on/off state). Patch created 11-17-2005: [http://www.vems.hu/files/Firmware/patches/patch_als_softrpm_against_v1.0.23.zip This patch release] contains all items included in old (mostly bugfix) patch mentioned below, and a '''completely rewritten ALS code, new launch control, new spark-cut based revlimiters (idle and redline)'''. Spark cut can be fine adjusted in 15 levels. ALS timer and EGT limiter is also implemented. Megatune part also ready for v027. LCD part is not ready, status: untested. '''More info with screenshots and figures can be found here: MembersPage/GaborRacz/NewAlsLaunchAndOthers.''' '''Please REVIEW and COMMIT this patch, if you found the implementation useful''' ---- MembersPage/GaborRacz: Patch created 07-13-2005 (re-generated for the current branch 10-31-2005): These modifications (diff-ed to v1.0.23 release) allow AntiLagSystem to set spark ATDC and bug fix to GenBoard/UnderDevelopment/StagedInjectors [http://www.vems.hu/files/Firmware/patches/als_patch_against_v023.diff Firmware patch] [http://www.vems.hu/files/Firmware/patches/vemsv3_als_patch_against_v023.diff vemsv3.ini patch] '''Changes''' * ifdef ALS => max ignadv changes from 63.75 degree to 43.75 * max ATDC spark angle configurable in my_make with IGN_BALANCE=xx (1/4 degrees, default=80). * vemsv3.ini patch assumes ALS=20 degrees offset (update if changing IGN_BALANCE !) * A config.inj_stage2_rate changed, so starts at 0% of primary pw (instead of original behavior = 100%). Therefore adjusts from 0..100% (not 100-200%) as it should ** we should merge variables, eg. NBO2 consumes several variables unnecessarily (when dummy NBO2 is used instead of the superior WBO2, the WBO2 variable positions should be reused!) ---- MembersPage/Gabor wrote: NOTE: diff for launch control and ALS. [http://www.vems.hu/files/Gabor/ALS_launch_diff.txt]. I don't want to commit it yet, because have problem with my board and can't through test it. ---- * '''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. MembersPage/GoranJurkovic wrote: Check my proposal for Launch Traction Control Algorithm MembersPage/GoranJurkovic/DaewooLaNOS/VemsTCMalg ---- '''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% ---- '''Advanced launch RPM limiter idea:''' Here is very simple and good usable launch RPM limiter method. I think this could be implemented into VEMS. During the RPM limit button is pushed, the RPM is limited by the softrpm limiter. We can define an RPM change rate, for example 1000 RPM/ sec. When we release the RPM limiter button, than the softRPM limit will raise until the overrun RPM limit by the given change rate. In our example rpm limit will raise by 1000 RPM/sec.
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.