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

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

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

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

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

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''' I understand the concept of acceleration enrichment (sorting out transient lean spots when you stand on the accelerator), but I'm unsure how this translates into setting the parameters. Right now it's pretty good, but I'm only guessing at them and I know it's not quite right. VEMS measures delta TPS (ie speed of accelerator position change): * tpsdotrate=FF (decimal 255, 100%) means 5V/100msec (extremely quick) * Accel is also proportional to RPM in later firmwares I can only tune by looking at logs (the added amount shows which bin the TPS-delta was in). The delay in WBO2 reading makes it a bit hard: but when you know which bin to tweak, you feel when it's right. Thanks Marcell - just what I needed to know. BTW - I have got a good idea of the "transit time" for my engine, and I have a short bit of code that works out the "transit time" and time aligns the WBO2 readings in a datalog for me. Q. is it in your perl code, or firmware code ? A. In the Perl code let me guess... whenever the throttle "tpsdot" transient is triggered, the change in WBO2 is collected into some statistics (to show if it leans out and how much). Than transit_time can slowly be changed, so it converges to a sane value. But there are more variables here. Why not keep transit_time manually adjustable, and adjust the added amount(s) instead ? That is different for the dv/dt (we have 4 bins) Also, behaviour is different depending on which loadsites we are, which part of the map. Almost right. Transit time is found by looking for instances of zero injector pulsewidth. It seems to be mostly proportional to RPM to the point of being able to neglect anything else with relative safety. It's only used to produce a time-corrected Lambda reading, which is then used - along with the other log data - for working out statistics for the RPM and tpsDOT acceleration bins. The added amount and times can be derived from this, but it's not a straight forward algorithm because there are more unknowns than equations... ---- Back to MembersPage/DavidBlades
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.