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

 ___   
(  _`\ 
| ( (_)
| |  _ 
| (_( )
(____/'
       
       

  ____  
 |  _ \ 
 | | | |
 | |_| |
 |____/ 
        

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

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

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:
'''Developer page for AlphaN''' In the 2004.Nov.firmware (without the patch below applied) the base fueling algorithm options are * pw = MAP * VE(MAP, RPM) (speed density) (config13 bit2=0) * pw = VE(TPS, RPM) (alphaN, without MAP) (config13 bit2=1) are supported, configurable in one bit. (The only reason for having it this way in one bit was compatibility with MegaManual and MegaTune protocol) A patch applied at some point enables these new modes: * pw = MAP * VE(TPS, RPM) (alphaN, with MAP multiplication; actually multiplication with load, see the difference below) * pw = VE(MAP, RPM) (probably useless) Note that if both MAP and TPS sensors are wired and configured correctly, either mode will work, but all will result in different VE (j) table and some will be harder to tune. The patch works like this: '''Load''' can be TPS / TPS .. MAP / MAP * below ''hybrid_rpm_a'' use TPS to index the VE (and ign and lambdatarget) table(s) that is VE(TPS, RPM) * above ''hybrid_rpm_m'' use speed density mode VE(MAP, RPM) (m for MAP or max) * load is a "blending of MAP and TPS signal" between hybrid_rpm_a and hybrid_rpm_m (as RPM goes up, it changes from fully TPS to fully MAP) '''multuplication with load''' * config13 bit2 chooses only if multiplication with load is applied or not ** config.config13 bit2=0 (multiplication with load is applied). With low hybrid_rpm_a=hybrid_rpm_m=00 this is the pure speed-density setup (TPS is used below RPM<0 that is never; MAP is used above RPM>0 that is always ). Multiplication with load makes sense for turbo engines, so the MAP also does matter above certain RPM, not only TPS. ** config.config13 bit2=1 (multiplication with load is NOT applied, useful for turbo). With high hybrid_rpm_a=hybrid_rpm_m=FF this is the pure alpha-n setup (MAP is not used, ever, since 25500 RPM is not reached at all). New tests here. MembersPage/SamuelLindkvist/AlphaN When OK, update AlphaN and GenBoard/Manual. ---- '''More details''' From fuelcalc.c the code is simpler than the blabla explanation: <code> if (!(config.config13 & _BV(CONTROL_STRATEGY))){ // speed-density uint16_t kpa_or_tps; if( engine_rpm8() >= config.hybrid_rpm_m ){ // normally, the MAP is used: kpa_or_tps = engine.kpa250; } else { // TODO: constant multiplier when RPM <= config.hybrid_rpm_a // for AlphaN, the MAP is not fully trusted kpa_or_tps = engine.kpa_tps_blend << 2 ; } res = mult_div596( kpa_or_tps, res ); } else { res = mult16_8(res, 172) >> 8; } </code> remember tps_or_kpa is the TPS / MAP blend as determined by hybrid_rpm_a and hybrid_rpm_m '''Thumb rule''' * always adjust hybrid_rpm_a and hybrid_rpm_m to determine the RPM for TPS / TPS-MAP / MAP * The alpha-n naming is very confusing, really. config13 bit2 should be called "disable multiplication with load", because that's what it does when bit2=1 . ---- Emils notes: Checked how another system works, will try to write down some info here.. * VE table runs fully alpha-n, ends at 100% TPS-load * lambda and spark table uses MAP instead * fuel amount on boost is calculated from the TPS based VE entry, multiplied with MAP and lambda-table. * This system doesnt need any MAP multiplication table, but in a possible VEMS implementation, it could be wise to have a MAP vs fuel multiplication table with a few cells. for example 200 kPa = 200% fuel, 250kPa = 250% fuel, this is likely the correct settings, but might be handy to test different settings, especially with bad injector control (not flat VE table) '''VEMS implementation proposition:''' * Added functionality to choose alpha-n or MAP based table lookup for each of VE, spark and lambda table. ** Step two here is to blend in TPS on low load(0-100 = tps, 100 -> MAP based (with option) for ignition and lambda target (configurable) * Make sure to split MAP from load realtime variable ** rt vars needed for this: ** This way we can get the dot in megatune tuning screen and table mode move properly *** MAP *** TPS *** Load.VE *** Load.ADV *** Load.LAMBDA * two sets of the table we now call k[], to fit the alpha-n table in one and map (s/d) table in one. default behaviour is to use the old table, It would make a big mess to mix both s/d and alpha-n in different tables. //Emil ---- '''Dave and Jorgen's proposal''' - for a system whith the '''MAP hose connected before''' the throttle butterfly Note that it's not literally a MAP sensor (not manifold pressure, closer to a boost sensor, or baro for an NA), but pressure sensor. Nonetheless we refer to it as MAP. * As the MAP sensor reads the (clean) pressure before the throttle, we '''use MAP-multiplication for the whole RPM and pressure sensor range''': ** 100..400kPa => charged induction range (multiplier >1.0) ** 80..100 clogged air-filter (or other restriction). Multiplier < 1.0 ** under 80kPa something is seriously wrong '''VE table''' - effectively 2 tables (with different meaning) merged in one * bins from load=0..100 are (always, regardless of MAP) looked up according to TPS 0..100%. Note that traditionally bins are used as 0..255 (for TPS 0..100%; but 0..100 resolution is perfect). * bins above 100kPa are VE correction values (only used above 100kPa) ** this can be just 2 bins, like 101 and 255, leaving many (10, or more) for the AlphaN VE-map ** If the engine does not lose flow at higher boost, this table will be filled in with 100 (or 200?) all over. To lean out a bit at 250kPa we could write 90 in that cell. '''target lambda table''' - split to 2 parts; but at any given time, only one part is looked into: the MAP determines if lower or upper part. Result is always lambdatarget * bins 0-100 are TPS * bins >100 load cells for lookup according to pressure. The switchover between using TPS or pressure should be somewhere between 104 and 110kPa (closer to 110?). Since the lambda at 110 is just slightly lower (richer) than the lambda at 100% TPS, this needs not be configurable. '''Ignition table''' - same way as the lambdatarget. * bins 0-100 are TPS * bins >100 load cells for lookup according to pressure Above 110kPa or so, start running the ignition specified in the >110kPa cells. Why not at 101..109 kPa ? This would probably offer good drivability. The only cases where the ignition would be all wrong is when the engine is fairly throttled (why? ignition is exactly as the tuner specifies in the table! Let him not specify it wrong). And that the car is not running at MBT (??) then is not a problem.-Jörgen ''The above functions are also useful for giving ram air, filter clogging and baro correction for normally aspirated alpha-N cars. -Jörgen'' ---- '''See also''' * AlphaN * GenBoard/Manual/Config/ManifoldAbsolutePressure * [http://not2fast.wryday.com/efi/blendingMAPnTPS.shtml theories/algorithms to blend alpha-n and speed density]
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.