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

         
         
 #    #  
  #  #   
   ##    
  #  #   
 #    #  
         

  ____  
 / ___| 
 \___ \ 
  ___) |
 |____/ 
        

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

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

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:
Eventually VEMS will release new and more advanced hardware, hardware I think the current VEMSTune implementation wouldn´t be able to handle properly. See linked PDF for my notes on organizing complex ECUs into more easily manageable user experience and user interface. http://www.vems.hu/files/VemsTune/VEMS%20Advanced.pdf I don´t think everything in that document needs to be exactly as it is there, but by following similar construct a more advanced VEMS can make itself more user friendly and more easily supported. If you want any information on anything in Pectel ECUs let me know. I can provide screenshots of anything requested. ------ Consideratiosn about input and outputs for future VEMS I think for maximum versatility and future proofing the base of the VEMS ECU should be so that each input or output selectable should be detached from a physical input pin, this allows for instance CAN channels(or other protocols) to act as analog/digital inputs, as would outputs be (apart from ignition/injection outputs unless the receiver has live crank angle measurements at its disposal). This could be described as base software and application software layers in where the application software layer only deals in the mathematics and logics while the base software only deals in converting physical pin values and stream protocol values into engineering values to be put into the two layers interface. Example Fuel injection pulswewidth direct to pin *'''AppSw''' : **Cylinder in question = 1 **VE calculations = 105 **Required injector constant = 6ms@100kpa **Total pulsewidth after all considerations = 105/100 * 6 = 6.3 Application software sends the value to the base software as Cyl1_Pw additionally the injection angle is also sent seperately as Cyl1_Angle *'''BaseSw''' : **Inputs are Cyl1_Pw = 6.3ms **Cyl_Angle = 360° Other inputs are **Cyl 1 Injector = Pin 8 - In Base Software side BaseSw takes care of WHEN to start pulling the injector circuit down and when to stop given that it knows the crank angle etc. '''Boost control 2 methods''' '''Method 1 & 2''' * App_Sw : ** Duty cycle calculated as 40% ** Boost_Pct >> Base Sw '''Method 1''' Base Sw : Boost output is set as a physical pin, BaseSw calculates timing and actions the pin accordingly '''Method 2''' Base Sw : Boost output is set as CAN out - CAN Id = 0x45, 16Bit size, Byte 0-1, gain 0.01%/bit , offset = 0 Can message byte 0-1 is sent as 4000 >> 0000 1111 1010 0000 Whoever is the receiver will handle the rest from there. '''Inputs''' In the App Sw the values are just a engineering value and so the software is written entirely on engineering values and boolean logic The App Sw wouldn´t need to care where the value comes from. Base software acts as the source of all the analog channels to the app software. * Analog input ** Physical pin on this device, local ADC curve applies * CAN-BUS input value ** Physical pin on some other device where analog >> engineering values is done * CAN-BUS input voltage ** Physical pin on some other device where analog >> engineering value is not done , local ADC curve applies * Serial protocol input value ** Physical pin on some other device where analog >> engineering values is done * Serial protocol input voltage ** Physical pin on some other device where analog >> engineering value is not done , local ADC curve applies * Virtual mathematical channel from AppSw ** In this case the value can be AppSw modelled based on other available App Sw values, value goes back out of the App Sw and comes in as a pre-defined engineering value, for instance if absolute fuel pressure is known and manifold pressure is known, then gauge fuel pressure across the injectors can be calculated(for inj pw adjustments) and returned as a engineering value (this engineering value could have come from anywhere though, not just from inside the ECU, so could have been an analog pin etc) I believe this methododoloy also allows faster updates to control strategies in the App Sw as the interface between the AppSw and BaseSw is already in place and might not need updating everytime there is an App Sw update. This also allows a big interface to be constructed between the two before some channels are even being used like, i.e. fuel injector gauge pressure doesn´t need to be used, but the "fuel injector gauge SENSOR" is constructed from the start and will therefor always be available. ---- ----- V4 FW requirements based on review of current V3 1.2.43 FW - Gunni ---- '''Time to put the V in versatile engine management to work!''' ---- *Basics **Get rid of current MAP A and MAP B configuration. ***Rather multiple VE , ignition , boost, dbw target etc tables that can be selected via a multiposition calibration pot or user virtual channel ---- *Alpha-N / Speed density Blend **All the options here should be drop down lists for quick setup ***Alpha-N only ***Alpha-N * Pre throttle pressure ***Alpha-N * Post throttle pressure ***Post throttle pressure only ***However the Y axis on any fuel / ignition / lambda table should be user selectable (MAP, TPS, LOAD, whatever the user wants) ----- *Primary trigger settings **Allow a non dividable multitooth trigger wheel ( eg 114triggers for a 4cyl or 116 for a 6cyl ) + reference trigger ( cam speed based or crank speed based) ------ *Secondary trigger settings **Ideal additional setting is a simple 0-720? range where the underlying cam sync is actually happening. ***A range should be used to account for variable cam timing. ***This removes any requirements for cycling injector outputs or ignition outputs or trigger reference tooth table angles and injector outputs and ignition outputs can be assigned to exact cylinder numbers and used inside the ECU for fuel, ignition, knock trims based on cylinder numbering and not output numbering. *Example : single trigger per cycle and missing tooth primary trigger **Minimum cycle angle - 300 **Maximum cycle angle - 450 **This means that as soon as the ECU has primary trigger sync and establishes secondary trigger it knows where in the 720 cycle it is and will be able to fire the next cylinder. ***Extremely easy for the user to setup and allows the camsync to cross between revolutions (through the missing tooth section) ***Same still works for multitooth triggers or multitooth with additional trigger with include / exclude / ignore setups to isolate a single repeating pattern on a per cycle to cycle bases after the pattern recognition spits out a valid cam sync trigger. ----- *Injector settings (Fuel settings will need adding) **Deadtime 3d table ***Battery voltage vs delta fuel pressure (delta fuel pressure can be an assumed fixed number if no sensor is fitted), Z is milliseconds ***Get rid of Traditional entirely. **Fuel density table required ***3d table with ethanol content vs fuel temperature, Z is grams per liter **Fuel stoichometric curve required ***2d table with ethanol content as the X axis. Z is AFR **If the vehicle runs on non petrol or ethanol based fuel something like methanol or a proportion of methanol coming out of the main injectors, the appropriate stoichometric value should still be put into the stoich curve and fuel density put into the fuel density table. ***In essence convert the fuel model to mass based. ****Air mass being - Air volume (VE * RPM ) * Air density (Air intake temp/Charge temp) ****Fuel mass being - Fuel volume (( Inj opening time ) * Fuel pressure delta(MAP vs Fuel system pressure) ) * Fuel density (Fuel temp) **Cylinder fuel trim ***3d table for each injector cylinder output (only enabled if injector output is being used as an injector output), Z is % multiplier ***Y axis - TPS, MAP, LOAD or whatever the user wants) ***X axis - RPM usually or whatever the user wants ***This means additive trim is not needed **Injector angle curve ***3d table 1 ****Y axis - TPS, MAP, LOAD or whatever the user wants) ****X axis - RPM usually or whatever the user wants ****This is because transport time is related to air velocity and so the same angle for every load for a single rpm point is not accurate. ***3d table 2 - can be used for angle trim based on whatever the users wants vs whatever the user wants (coolant temp, air temp, etc) **Angle table 1 + Angle table 2 = Z = final end of injection angle in BTDC ----- **Injector staging ***Complete copy of normal injector settings Deadtimes, Injector trims, Injector angle curve, injector output visual secondary, fuel density, fuel stoichometric curve etc ***3d table with usually MAP x RPM or whatever the user wants, Z is the value of total injection amount of the primary injectors in %. **Example : ***Main fuel table requires 1000cc/min per injector flow at Y load and X RPM, but the main injectors would require 150% open time(they are 666cc/min). ****This table can allow the secondary injectors to flow anywhere between 0-100%. ****If the secondary injectors are for instance also 666cc/min then 50% in the table would open each injector 50% of the required total fuel flow ****This would be 150*0.5=75% per injector in this example. ****At 60% in the table would make the secondary injectors open for 90% and the primary injectors 60% (60+90=150%) ****This is of course changes with differently sized injectors or the different type of fuel coming from the secondary injectors. ***When the fuel and fuel injectors settings are correct for both primary and secondary then any % change in the 3d table should yield the same lambda. ***The reasons to lean more on the seconary injectors can be to lean more on the secondary fuel type ( water methanol injection, methanol injection, ethanol, gas injection etc) ----- *Ignition settings **Dwell settings ***3d table where usually it?s Y is load and X is battery voltage, Z is milliseconds ----- **Cyl seperated spark delay ***3d table for each cylinder of usually Y is TPS, MAP or LOAD and X is rpm , Z is ignition advance delta ----- *Soft ignition cut **Control range and maximum rpm removed and replaced with a 3d table, usually Y is TPS, MAP or LOAD and X is RPM, Z is % cut ***This allows the user to manage the required aggressiveness of the cutting ------ *Overboost fuel cut **3d table , usually TPS vs RPM, either should be whatever the user wants (Y for boost target for instance, maybe air charge temp) **It?s completely normal to have different maximum boost targets across the rpm range or TPS range and thus overboost should be relatable to the current situation and not a one size fits all value, Z is KPA ------ *Overrun fuel cut **3d table , usually TPS vs RPM , Z is 0 for no cut and 1 for cut , Y could b MAP or TPS ----- *Decreased boost target above MAT, EGT, CLT **3x 3d tables , X axis MAT / EGT / CLT, Y axis is whatever the user wants. Usually TPS, Z?s are KPA shown as a negative value ***Also 3x 3d tables for duty cycle reduction so you aren?t leaning on the closed loop to do all the work (same axis as the target change table). Z?s are DC% negative values ------ *Increased fuel above EGT **3d table , Y axis can be TPS, MAP, LOAD or whatever the user wants. X axis is EGT, Z is % multipler fuel enrichment ----- *EGO closed loop control settings **Lean and Rich limits, Engine cycles before changing correction are 3d tables with ***Y as TPS, MAP or whatever the user wants, X axis usually RPM, Z for lean and rich are % of total enrichment or enleanment, Z for engine cycle count is number of cycles since end of closed loop lambda stopping function **Step size can be removed **Speed limit (PID ) ***3d table for each term ***P table usually Y is TPS, MAP or whatever the user wants and X is Lambda error, Z is % of instant fuel change ***I Table usually Y is TPS, MAP or whatever the user wants and X is Lambda error, Z is the % of change to add to the current I term ***D Table usually Y is Rate of lambda error and X is lambda error. Z is the % of instance fuel change **I terms needs maximum and minimum allowed limits like idle control in 3d tables , Y as TPS, MAP or LOAD or whatever the users wants, X is RPM, Z for maximum limit represented as a positive value in it?s table, Z for minimum limit represented as a negative value in it?s table **No need for dynamic speed or assymetric speed with the above changes. ----- *DBW - ETC **Vbatt compensation is a curve and not a single factor, X axis is VBAT, Z is % multiplier to the strategy normal output **PID settings ***Tables for each term, like lambda control above. straight linear PID terms are not enough for best possible control. ***P table ideally is Y is current TPS position , X is DBW target error ***Inputs can be removed and internalized based on sensor setup menu , no need to double up selection points. ***Safety output also internalized as it?s now inside the ECU vs V3 ***Other safety features required are thresholds for determining one of the TPS or PPS inputs has failed and DBW H-bridge must be shut down. ----- *MAT / TPS fuel enrichment **Y should be user selectable , usually TPS or MAP, but can also be from a charge temp model, Z is % fuel multiplier ------ *Acceleration enrichment **Let start easy, nothing advanced (no RPM rate) - **TPS based AND MAP at the same time, as boost can rise without TPS change during periods of turbo spooling for instance. **MAP when TPS is being used would only have low numbers ***3d table for fadeout time Y as TPS, MAP or user selected, X axis is coolant temp, Z is cycles ***3d table for Acc cold mult factor, Y as TPS, MAP or user selected, X axis is coolant temp, Z is % fuel multiplier ***3d table for Cold accel added amount, Y as TPS, MAP or user selected, X axis is coolant temp, Z is % fuel multiplier ***3d table for ign retard Y can be TPS, MAP or user selected, usually related to the amount of Accel enrichment, Z is % fuel multiplier ***3d table for d/TPS vs RPM , negative d/TPS available ***3d table for d/MAP vs RPM , negative d/MAP available ----- *Priming , Cranking , Afterstart **3d table for Priming TPS vs CLT usually, Z is % fuel multiplier ----- *Afterstart settings **3d table Y is TPS, MAP or load, X is cycles, z is % fuel multiplier ------ *Warmup scaling **3d table , Y is TPS or MAP vs RPM, Z is the % fuel multiplier ***No need for the warmup curve ----- *Cranking enrichment **3d table , Y as TPS vs CLT, Z is % fuel multiplier ***no need for the afterstart curve ----- *Idle control general **3d table for idle target rpm , Y is run time/cycles, X is CLT, Z is RPM **2d curve for MAT addition, X is MAT, Z is RPM **3d table for IAC base duty cycle, Y is run time/cycles or something else, X is CLT , Z is IAC DC% TRIM **3d table for IAC added duty cycle, Y is TPS, MAP or something else, X is RPM - this covers IAC forced minmap and forced close duty also, Z is AC DC% TRIM (-100 to +100) *Idle Alpha-N position compensation **3d table Y is IAC DC%, X is RPM, Z is TPS TRIM into VE table. It?s either this or produce a IAC DC% x RPM based airflow increase TRIM that is added to the VE table output seperately (that would really need another 3d table) *Idle control PID **Much like lambda closed loop, each term should have it?s own table **P table usually Y is TPS, MAP or whatever the user wants and X is Idle error, Z is % of IAC DC% TRIM **I Table usually Y is TPS, MAP or whatever the user wants and X is Idle error, Z is the % of change to add to the current I term **D Table usually Y is Rate of idle error and X is idle error. **Integral limits need 3d tables, Y is run time/cycle since start or whatever the user wants, X is RPM, Z is IAC% MIN or MAX currently allowed *Idle AC Control **Idle up Control settings ***AC Request added refdc , 3d table Y is time since request seen, X is idle error, Z is IAC DC% TRIM ****Essientially a time based P term *Idle ignition advance **Advance change max and min and rate of change, these can all be put together into a single 3d table Y is Idle error,X is RPM, Z is degrees of advance *Spark cut idle **3d table for idle target vs idle error, z is the % cuts ----- *Boost control PID settings **3d table for PWM max duty , Y is Boost target, X is RPM , Z is maximum BOOST DC% **3d table for PWM min duty , Y is Boost target, X is RPM ,Z is minimum BOOST DC% ***Above in effect manages PID output limits, these need to change based on changing boost target **PID settings ***Same as everything else so far ****P table usually Y is TPS, MAP or whatever the user wants and X is Target error, Z is % BOOST DC% TRIM ****I Table usually Y is TPS, MAP or whatever the user wants and X is Target error, Z is the % of change to add to the current I term, I term is % BOOST DC% TRIM ****D Table usually Y is Rate of Target error and X is target error. Z is % BOOST DC% TRIM ****These tables take over the PD control, PI Control, PID overlap range and the PID factors. *Boost Targets **1x 3d table per gear available each gear table Y is TPS vs RPM, Z is KPA *Boost base duty cycle **1x 3d table per gear each gear table for main base duty cycle, TPS, X is RPM or whatever the user wants ------ *Secondary PWM - moved to AnyControl 3d with PID *Misc 1 - moved to AnyControl 3d with PID *Misc 2 -moved to AnyControl 3d with PID *WOT Actuator - moved to AnyControl 3d with PID *RPM Actuator - moved to AnyControl 3d with PID *Many gauges - moved to AnyControl 3d with PID ------ *Fuel pump output **PWM output 3d table Y is TPS, MAP , LOAD or whatever the user wants, X is RPM ***LOAD or Injection mass flow makes most sense ----- *AIM Stream **AIM Inputs - Actual sensor values from the Analog sensor configurations ----- *Tach **2d curve - X is RPM, Z is the output frequency - usually linear but not always - ***drop down menu option for most common usage ( linear Xcyl for Xcyl tacho, 6cyl engine with 4cyl tacho , 8cyl engine with 4cyl tacho etc) ****Test output needs to allow user to override output tacho RPM value and verify all curve points in extreme cases. ----- *Warning light settings **ADC Channel, needs to be able to be set to disabled. **Big rebuild of internal failure modes for sensors, conditions etc needed. ----- *ALS control **3d tables for enrichment, retard, cuts, usually Y is TPS, X is RPM, Z is % MULT or TRIM based on what the table is ----- *N20 Control settings **Ignition retard , 3d table , Y usually NO2 solenoid PWM, X is RPM, Z is IGN TRIM **3d table for fuel enrichment, Y usually N2O solenoid PWM, X is RPM, Z is % fuel change **3d table for base N2O PWM solenoid control, Y usually TPS or MAP , X is RPM, Z is ----- *Launch control **3d tables for enrichment, cuts, retard, boost target override or adjustment, Y usually TPS or MAP, X is RPM, Z is % MULT or TRIM based on what the table is ------ *Traction control **3d table for target slip for each gear, usually TPS or MAP or LOAD vs RPM, Z is % TC TRIM% **3d table for target slip adjustment based on some sensor inputs, like steering angle, calibration pot, Z is % TC TRIM % **3d table for slip torque management via cuts , usually Y is TPS or MAP, X is slip error, Z is fuel / ign cut % TRIM **3d table for slip torque management via retard, usually Y is TPS or MAP, X is slip error, Z is IGN TRIM **3d table for slip torque management via boost reduction, usually Y is TPS or MAP, X is slip error, Z is BOOST TARGET TRIM **3d table for slip boost DC ref reduction, Y is Target TRIM , X is RPM , Z is BOOST DC % TRIM **3d table for slip torque management via dbw throttle , usually Y is TPS or MAP, X is slip error, Z is DBW ANGLE TARGET TRIM ----- *Anytrim Control **Enhanced with 3d base tables and closed loop 3d PID factor tables and target tables **Modes are similar/same as to what?s currently available but also added is direct output PWM, CANBUS, Virtual internal channel( used in another AnyControl function) **Every Y and X axis needs to be any available channel in the ECU. **10 of these required vs current 5, **Would allow almost any conceivable functionality/safety in and out of the ECU to be built quickly by the dealer/power user and later evolved into a VEMS built in strategy if wanted **For direct output PWM Anytrim Control 1 , the Duty cycle and Frequency can be fixed elements or come from other Anytrim Control or Anytrim Math or Realtime channel sources ***Example 1 : Closed loop PWM output with varying duty cycle (Base 3d table Z + PID loop Z) but frequency is fixed to Boost output frequency or RPM or from Anytrim Control 2 ***Example 2 : Closed loop PWM output with varying frequency , but duty cycle is fixed to Injector 1 DC% or Boost DC% or IAC% DC or Anytrim Control 2 ----- *Anytrim Math **Allows combining multiple internal run time channels or strategy constants into new values/channels ***Various math functions like + - * / **10 of these, increases the flexibility many times over and doesn?t take up multiple Anytrim 3d tables to produce a new value ------- *Camshaft angle control **Even if exhaust cam is the source of the camsync then trigger sensor input selection already determines what table is used for what trigger input and so intake sensor is always intake table and exhaust trigger is always exhaust table. This would allow a non moving cam sensor to be used for camsync but the variable sensor input is used variable cam movement (eg S50B30 , McLaren F1) ------ *Input channels **Digital (Hz or DC%), Analog voltages, Virtual, Internal run time values, CANBUS, Aim stream and any other potential source can be assigned to a internal "Sensor" ***See email detailing sensor setup *CANBUS/AIM stream/LINBUS/MODBUS/ETHERNET or whatever else Input and Output needs detailing and I have not touched on that here. '''Send us some V4 ECUs and we can all get to work'''
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.