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

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

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

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

 _______ 
(  ____ \
| (    \/
| (_____ 
(_____  )
      ) |
/\____) |
\_______)
         

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:
'''This page explains the injector opening related calculation implementation details for developers''' Read GenBoard/Manual/Config/InjectorOpening first, this is impossible to understand otherwise. Even though the injector current rampup can be modelled relatively easily (knowing voltage and injector resistance and inductance), measuring the mechanical parameters that contribute greatly to overall effects are most often out of the question for a tuner. ---- '''Research''' Searching the web one will find that there is some interesting (but not too useful) info burried in mailing list archives (among 99% of useless or outdated text with similar keywords): * measuring mechanical opening with scope (same effect as VR) * measuring mechanicel opening with accelerometer, knock-microphone or phono pickup. * measuring the fuel flowrate with 50usec precision is out of the question * measuring rough opening time is relatively easy by applying double injection rate (if possible; but not possible where it would matter the most !!!) There are no opensource implementations that get it right. There are not even many published formulas that could be used off the shelf. However some manufacturers are known to get this right (eg. Autronic). Never mind, it's not that complex: a car manufacturer would probably only fire about a dozen patents on something like this, which can be solved in effectively 20 lines of code. But these kind of (algorithmic) patents are not valid in Europe, and are easily invalidated in US too, since they are trivial to implement for any expert in the field, not involving real innovative thought. ---- '''Implementation details''' Integrate the GenBoard/Manual/Config/InjectorOpening curve to get full injected amount vs. pulsewidth. Do a reverse-lookup (known variable is required fuel amount) to get command pulsewidth. That's all. notes: * the integrated rampup will be a 2nd .. 3d order polynom, which continues smoothly (no breaking!) in a straight line (for full injector flowrate determined by req_fuel). * the average injected fuel flowrate during the rampup does not depend on the VBatt (but it happens longer for lower VBatt). Implementation choices: * successive approximation (reverse-lookup with an analytic formula). Ruled out. * '''flashlookup''' (any curve can be programmed). We do this, because it is very flexible and powerful. We rotate the integrated curve 90 degrees to get closer to the actual implementation: x axis is fuel and y is pulsewidth. '''Actually we subtract the pulsewidth that is implied anyway when multiplying calculated fuel quantity with config.req_fuel constant. Effectively we calculate the required pulsewidth extension''' ** injopencurve (stored in flash) stands as a multiplier for a user-specified scale. Looks roughly like pwext(fuel)=sqrt(fuel)-fuel: highest multiplier value is 1.0 (in practice 255). The height / width of the table is appr. 1..2 * req_fuel (during the rampup the average flowrate is half .. 1/3 of req_fuel - remember that req_fuel is proportional to diffpw / difffuel, just the reciprocal of flowrate). ** the scaling is brilliant - but it costs a division ** injopen(VBatt) must be added (after above calc) as it's always been. Before the flowrate rampup, when there is no fuel-flow, the calculation is trivial. ---- '''injocfuel unit - cheating''' Internally, injocfuel the maximum extension of the pulsewidth due to the rampup. For example if the rampup is 500 usec, and the average flow during the rampup is 0.4* of full flowrate (which is a good approximation, it is somewhere between 0.33 .. 0.5 ) injocfuel value = 500usec*0.6 = 300usec is desired (during the 500 usec rampup average 500usec * 0.4 is actually flown, so the pulsewidth must be extended with the remaining 500usec * 0.6). To avoid this long explanation, we say to the users that injocfuel is the time of the rampup, but with [24 usec] units. ---- '''Old thoughts for curve scaling''' - actually solved in a tricky and neat way ** injopencurve_vbatt = we scale down the injopencurve proportionally in both directions according to VBatt (higher VBatt scales it down more). This is consistent with the diagram and the above note "the average injected fuel flowrate during the rampup does not depend on the VBatt" ** injopencurve_vbatt_reqf = we multiply the injopencurve_vbatt with req_fuel. This is required since the curve must smoothly continue in a straight line with slope = req_fuel. ** naturally, if the fuel is more than the width of injopencurve_vbatt_reqf (== width of injopencurve_vbatt) we are only interested in the top-right corner (include the height as time, and subtract the width from fuel, and calculate with req_fuel) ---- Go back to OnlineCourse
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.