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:\nÿ1ÿ
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 .
Emil's proposal:
Checked how another system works, some notes:
- VE table runs fully TPS-based (alpha-n), ends at 100% TPS-load
- lambda and spark table uses MAP
- fuel amount on boost is calculated from the TPS based VE entry, multiplied with MAP and lambda-table
- No MAP-multiplication if MAP < 104kPa
- at high boost, as engine loses flow, the applied MAP multiplication might be too high. Below, proposals suggest a configurable MAP-dependent "correction factor" that can do *MAP*1.0 at around 105kPa and *MAP*0.95 at high boost.
- 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
- might be handy to test different settings. Slow injector closing (non-flat VE table) should not effect high-boost too much (while effecting low-load significantly)
VEMS implementation proposal:
- table lookup strategy independent for VE, spark and lambda table (though spark and lambda almost always use the same)
- MAP-based (default)
- TPS-based (0..255 is 0..100%) - AlphaN
- 0..100 part of the table is looked up by TPS, 101..255 part of the table looked up by MAP (usually just a very few lines, often 2)
- 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)
- split MAP from load realtime variable to get the dot in megatune (tuning screen and table mode) move properly. rt vars needed for this:
- MAP
- TPS
- Load.VE
- Load.ADV
- Load.LAMBDA
- two (well, 3 right?) sets of k[] - for each "table-lookup strategy"
- MAP-based, (k[], for backward compatibility, most people uses s/d now)
- tps based (kt[] ?)
- tps on low-load, MAP on boost
Use cases
- Pure S / D
- VE table: MAP based
- Spark table: MAP based
- Lambda table: MAP based
- Pure Alpha-N
- VE table: TPS based
- Spark table: TPS based
- Lambda table: TPS based
- Alpha-N with baro correction
- VE table: TPS based with MAP multiplication
- important: with map sensor connected in free air or before throttle bodies
- Spark table: TPS based
- Lambda table: TPS based
- VE table: TPS based with MAP multiplication
- Alpha-N with boost compensation, map based spark+lambda all the time
- VE table: TPS based with MAP multiplication
- Spark table: MAP based
- Lambda table: MAP based
- Alpha-N with boost compensation, tps based spark+lambda before boost arrives
- VE table: TPS based with MAP multiplication
- Spark table: TPS based when MAP<=barometric pressure, MAP based above
- Lambda table: TPS based when MAP<=barometric pressure, MAP based above
Different engines want different schemes here, especially for the last 2 use cases.
//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