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

_________
\__   __/
   ) (   
   | |   
   | |   
   | |   
   | |   
   )_(   
         

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

   _____ 
  / ____|
 | |  __ 
 | | |_ |
 | |__| |
  \_____|
         
         

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

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:
'''Acceleration enrichment table implementation''' This page is meant for a discussion about the new and more versatile acceleration enrichment application. Rob has offered to visualize it by making tuning screens for it. There is a few important changes that will address a few shortcommings in the current implementation. Some of them could be considered to be redundant but ease of setup is a primary concern and when we need to make a setup using large tables I don't think that one or two extra 2d tables would hurt much. I will not go into our current model but will only describe a possible future implentation. ---- '''TPS linearization''' First of all we will have something that linearize the TPS signal a bit. Something that will make the TPS rate of change represent a throttle area rate of change. This may be hidden from the user or can be a simple 2d table with TPS% on one axis and TPS area% on the other. Slide throttles and dual butterfly throttles like the one on my Audi comes to mind. ''My TPS on the 50mm blades shaft, when at 70% opening of the 50mm blade the large 75mm blade starts to open. Both reach full open at the same time.'' '''Transient fuel base table (2D)''' The rate of change figure is in area%/s and 8positions is probably more then enough. Each position has one amount and one decay entry. Similar to what we have today but with the addition of the decay entry. The decay entry is probably best specified in decay/engine revolution. The decay/rev number is practical but could cause some confusion when tuning. I don't know if we should care about this. It's a RTFM problem. ''A third curve is probably best stored here as well, the idle tip-in transient fuel curve. See further down.'' <code> TPS rate of change Enrich amount Enrich decay Special idle acc enrich %of req_fuel % per rev % of req_fuel 0 0 100 0 1 0 100 5 3 10 10 10 8 20 10 20 15 20 10 20 30 40 10 30 60 40 10 40 100 40 10 40 </code> '''Load compensation''' As the engine needs different amount of acc enrich depending on the initial load site a load compensation curve is probably a good idea. This should probably reuse the loadsites on the normal MAP load axis. Having this separate from the main 3d table should simplify setup. I suspect that the 3d table can be left flat for most applications if this curve is implemented. <code> Load Enrich amount scaler% 300 0 260 0 230 0 200 0 170 0 140 10 110 10 90 40 70 60 50 100 30 100 20 100 </code> '''Acc enrich amount scaler Load/RPM 3D table''' This table should probably have 8X8 loadsites which are shared with the acc enrich decay table. The amounts from the base table is multiplied with the load compensation table and is then multiplied with this table. '''Acc enrich decay scaler Load/RPM 3D table''' The decay from the base table is multiplied with this table. It is a bit of a problem that a higher value in this table cause a faster decay, for logical reasons we probably want a higher value to result in more acc enrichment fuel. ---- '''Target lambda at trigg site''' The actual lambda at the site where tip-in occurs make a very big difference for the amount needed transient fuel. We would ideally use the actual lambda but we must never rely on the lambda sensor for a value like this. It lags behind a bit and it will cause problems. We are better off trying to estimate the lambda based on the target lambda of the loadsite where the tip-in occur, we also need to consider any fuel cut consition. ---- '''Special tip-in from idle fuel''' This is a single value for tip in from idle. This condition is nice to be able to tune without affecting the other transient fuel settings. It is only trigged when tipping in from 0% throttle at idle rpms. Probably defined as >1500rpm. It is a special condition that probably need all injectors to add an extra squirt of transient fuel! When the condition is met the injectors are instantly opened to inject a single pulse of transient fuel. The length of this pulse is compensated for with req_fuel and it's the third column in the transient fuel base table. We want the transient fuel to be immediate as the fuel is normally injected on a closed valve. By injecting at once we allow the cylinders to get it's transient fuel up to two full revolutions earlier (0.16s at 750rpm). We also prevent the intake walls from being robbed of their fuel coating which can reduce lag even more. This kind of transient fuel is fairly common. '''Extra pulse for transient fuel whenever possible?''' Is this worth it? With a small injector it should be fairly easy to get this to work as we can afford an extra pulse in between the normal pulses. With larger injectors the transient fuel demand would have to be very large for this to work. Replacing the normal pulse with the extra transient pulse comes to mind, but for cam timing various reasons this is very very tricky.
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.