_______ 
(  ____ )
| (    )|
| (____)|
|     __)
| (\ (   
| ) \ \__
|/   \__/
         

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

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

 _       _ 
( )  _  ( )
| | ( ) | |
| | | | | |
| (_/ \_) |
`\___x___/'
           
           

           
     /\    
    /  \   
   / /\ \  
  / ____ \ 
 /_/    \_\
           
           

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:
'''Config and tables related subpage of GenBoard/UnderDevelopment/FirmWare''' '''More bins''' upto 16x16 is possible, (14x16 or 15x15 requires no MegaTune changes) but testing and MegaTune support is needed. Miska was running with 16x14, right ? With the * applied interpolation * configurable (not fixed) bins the number of required bins is surprisingly low. * 16 RPM bins is enough for the VE of most spiky race engines. 8 is perfect for most. We have never ever had a reasonable complaint with 12 bins ** VE or lambda tables should not have such breaks in the MAP direction in any case (0 break normally, and max 1 break if injector opening is misconfigured) * More than 8 MAP bins (ignition/VE/lambda table) does not make possible to tune for better power, even for highest boost engines. 12 is more than enough, even when a blending AlphaN / speed-density is tuned, or if the tuner choses the bins somewhat unreasonably. ** ideal ignadv has 2 breaks in MAP direction, for which 4 MAP bins are needed. The extra 4 bins can be used to smooth out all areas, or spare bins to insert anywhere. The common misconception "more bins needed for high-boost engines" comes from bad injector-opening values (often the lack of proper injopen model in most ECM-s). See GenBoard/Manual/Config/InjectorOpening, For marketing reasons 16x12 or even 16x16 might worth to consider. This is MegaTune configuration issue, though the firmware also needs to be recompiled and tested. It is possible to approximate the ideal maps beyond measure errors with 7x6 (for a high-boost engine with many bumps in the torque curve), or even just a tiny 4x4 for the lambda-target (millions of engines with NBO2 use 2x2 or smaller), but: * VE on variable valve timing or variable intake motor depends on the switchover point * during tuning, it's easier if an intermediate bin can be easily inserted on demand ---- '''Choice of load type for ignition and lambda table lookup''' MembersPage/MattiasSandgren I have several projects where an engine that is mapped with Alpha-N or a (future) blending function of Alpha-N and Speed-Density (boosted motor with no vacuum at low load) could use something other than the TPS input to lookup the ignition table. This also points in to the need for separate rpm and load bins and table size for VE, ignition and lambda map - as discussed above. * Is the development of this mainly a MegaTune compatibility issue? ---- *'''Programmable Injection timing'''. Injection timing angle when the '''injection firing ends''' (0-720 deg) from the TDC, at every RPM bins (only depends on RPM, not MAP). ''fixed injection start angle is useless -Jörgen'' ''I mean programmable injection timing according to the RPM bins -Fero'' ---- '''MegaTune is limited, 1/x conversion is not possible''' Would be needed for lambdatarget=>ECU. * We can make a "view" that is a new page: reading/writing is still from/to l table, but conversion happens (with the help of div_65535_x() ) during read / write (not direct values). * some extreme values: ||'''lambdacorr'''||'''internal_lcorr'''=lambdacorr+200||'''lambda'''||'''meaning'''||'''65535/internal_lcorr'''||'''optimal megatune value'''|| ||0||200|| 256/200 = 1.28|| lean||327.68||255|| ||56||256|| 256/256 =1.00|| stoich||256|| ? eg. 183 || ||255||455|| 256/455=0.563|| rich|| 144.03|| 0 or higher, eg. 71 || The recommendation for the conversion involves an offset of 72 or 73: * lambda_mt = div_65535_x( internal_lcorr ) - 73 * internal_lcorr = div_65535_x( lambda_mt + 73 ) '''Dwell wizard''' - simple MegaTune calculated value could dwell tuning easier * commanded dwell is known (from the controller A command) ** (it is calculated from dwell14 and VBatt) * RPM is known * from this, the desired average (mean) current consumption could be calculated. The installer could change dwell so the measured value is close to this calculated value. ** one or 2 adjustable constant multipliers would be a big help, so is 0.1 Ohm measure resistor is connected in the supply path of 1 transformer, or 0.025 Ohm is connected for 4 cylinders. So the direct readings from DVM could be compared directly * example ** RPM=1200 ** commanded_dwell=3000 usec ** peak_current=5 A ** measure_res=0.1 Ohm ** measured_trans=1 ** desired_reading = measure_res * measured_trans * peak_current /2 * commanded_dwell * RPM / 120000000 ** = measure_res * measured_trans * peak_current * commanded_dwell * RPM / 240000000 ** = 0.0075 for the example, so the dwell can be increased if the DVM measures less than 7.5 mV (at 1200 RPM) across the 0.1 Ohm resistor (that measures only 1 transformer's current). *** Note that when you increase dwell, this calculated value will increase (appr. proportionally), but the measured value increases at a higher rate (appr. squared). *** when you increase RPM, both this calculated and the measured value increases proportionally. ---- * matfactor.c: MAT sensor ADC to MAT internal format (eg. 0..255 means -40 .. 215 Fahrenheit) conversion * thermfactor.c: CLT sensor ADC to CLT internal format * airdenfactor.c: MAT sensor reading to air density correction factor (100 means *1.0, 110 means *1.10 fuel pulsewidth due to appr 30C lower MAT temp). Naturally, thermfactor.c and matfactor.c are similar (with similar NTC based sensors, like used all over, GM, Honda, BMW, and every manufacturer). These are monotonous (except limp-home "bad-sensor-assumed" values at the end of the scale). airdenfactor.c is different, it comes directly from the universal gas law. * airden_ignore=62 // Suggested value=0x62 (decimal 98). Indeed invented to solve the "idling heat soak" problem, by not allowing to lean out the mixture too much at low RPM. 0 disables altogether. ---- '''Unused variables cleanup''' Although ALS is implemented and used, it's not easily configurable: * requires firmware compiled with ALS option * misc2output disables (variables stolen by ALS) Config variables to be dropped or shrinked (so the offset position can be used for sg. useful.) ALS variables are not grouped, they drop in for the minimal MegaTune changes. MegaTune maintainers diff global.h or varstr.h for the 8 (or so) changes (old dropped variables with 2 moved bits), and ''grep als varstr.h'' for new positions. Old MegaTune should continue to work if these variables are not tweaked and sane initial config uploaded. * TODO: drop VE-learning and all related variables. PC-side VE-learning implementations are much better today and allow more tuner-control. The internal double-size VE table goes away, and config variables freed. Other features will be more useful like ** GenBoard/Manual/Config/IdleControl 1 variable of PWM-iac position to converge to when engine is running => to try to close Bosch valve with 24% duty to prevent boost-leak with a weird valve breathes from ambient setup ** 4 points of craning pulsewidth instead of cwl/cwh : -40C, -20C, 0C, +70C * TODO: iac_sol_channel 0x.F (now "disabled") would mean stepper, so the ** iac_step_seq can be freed (only 6 useful combinations anyway for how it is wired, for A-B, A-C and A-D, 2 directions for each). * DONE: iac_overclose_interval (only used for stepper) should not be needed * DONE: dropped fastidle. Was only used when precise_idle. Reused iac_cold_rpm and iac_warm_rpm (for the hysteresis thresholds, actually it became more generic by making it possible to set both upper and lower thresholds) * DONE: free1 * DONE: free2 * DONE: mt_unused * DONE: '''wbo2_warmup_target''' (killed) * '''ign_balance''' is used, but unreasonable. A 16 bit internal igandv makes much more sense, same amount of SRAM-usage, higher ignadv-range, but freeing a config bit. ** trigger_tooth; ign_tdcdelay: with the overlapping code, I think we'll drop trigger-tooth, and change ign_tdcdelay to 1 degree precision (Noone can measure base timing with 0.5 degree precision anyway). ign_tdcdelay must be renamed for safety. Can you propose a new name ? * DONE: tps_thresh * crank_minper - probably better way exist for simple-trigger too (multitooth has superior advanced filter way to notice trigger errors) * tpsdq ? * DONE: baro (pinned to 100 kPa. Fine for 99.99% of users. Might it make tricks harder for extreme boost MAP >= 512kPa ?) * ign_dwell6 - could be calculated from ign_dwell14. Must be replaced by MAP-dependent dwell. That is increase dwell linearly above appr 55..60 kPa (mostly used for turbo engines) * DONE: injpwm6 - now calculated from injpwm * cranking_thres 4 bits would be enough * warmup_rpm_scale 4 bits would be enough * divider 4 bits would be enough * rpmk[2] 4 bits would be enough (apparently everyone uses 12,000/ncyl anyway) ** one byte, multiplied with *100 (very simple) internally would allow any common values (1500,2000,2400,3000,6000,12000,24000, etc...) * tpsdot_kpadot_conf 1 bit would be enough, possibly in shiftcut_conf or near als flags ? * DONE: iac_integral_speed was redundant: iac_ki and iac_integral_limit_dec (and iac_integral_limit_inc) together determine I-term time constant. * DONE: iac_pid_conf => merged into iac_conf ** '''config.iac_pid_conf & _BV(softidle) bit4 moved to iac_conf bit7''' ** '''config.iac_pid_conf & _BV(pid_asymmetric) bit0 moved to iac_conf bit6''' * DONE: iac_ign_advance_change and iac_ign_retard_change: merged to one value iac_ign_slope (but still separate limit for the 2 directions is OK) * ego_target a bit questionable, even for NBO2, but... * DONE: wbo2_edgetime_corr (gave space to als_retard_rpm1) * DONE: wbo2_edgetime_min (gave space to als_retard_rpm2) * wbo2_pump_pid_kd = 0 (likely 0 is the only sane value !) * lcd_backlight anyone uses this? 3 bits would be enough that could be merged into lcd_c0 * DONE: egt1_offs always 0 currently. However, 2..3 bits to select mcp3208 channel would be nice, and 5 bit for offset might be useful with some special HW Config variables to be moved over if config is full (to a table of width=10? note that it's rather an internal change, old config.txt would be usable and MegaTune as well, after minor ini update): * coolant temp bins noone adjusts these, could be flash-constants * warmup enrichment (in function of coolant temp) * iac_ref_pos[] iac reference positions (in function of coolant temp) * awev and awev_temp_scaling (currently 2 bytes, could be 10 for nonlinear config) ---- I would also like a output to drive the CEL light, when knock is detected, as a shiftlight or both, like Apexi Power FC, or Simtek "http://www.scoobymania.com/shop/product_info.php?products_id=814&osCsid=c9d5fe31a7800b8697535492e692cf70" Skassa ---- '''Settings for Nitrous Retard''' by Emil using 9 config bytes, can be taken from ve_learn settings ---- * n2o_mintps ** minimum TPS for activation (full throttle switch) * n2o_minrpm ** minimum RPM for activation (not good to add too much torque on low rpm) * n2o_maxrpm ** maximum rpm, switch off n2o above this rpm (recommended to hit this before revlimiter) * n2o_retard ** amount of timing retard when function activated * n2o_minkpa ** minimum MAP for activation (backup for TPS signal, we dont want to activate on too low load, will cause explosion) * n2o_maxkpa ** maximum MAP for activation (some people use N2O only to help turbos spool quickly) * n2o_input ** input channel for activation * n2o_output ** output channel to activate solenoid * n2o_settings (bits) ** function enabled - 0=disabled, 1=enabled ** deactivated by launch control switch - 0 = off, 1=on(turbo guys might want N2O to spool turbo's before launch, N/A guys wants to activate nitrous when leaving starting line) ---- '''Settings for launch control activated output with delay / pwm ramping''' by Emil - 20080213 will need 7 bytes config ---- *"launch base rpm", launch_rpm *"revlimit control range", softrpm_range *"old launchcontrol / fuel based",als_rev_limit *"Fuel enrichment", launch_enrich *"Ignition Retard", launch_retard old settings for launch control remain, with the following additions: * launch_out_channel ** standard outputchannel setting * launch_out_delay ** time delay for this function ''after''' release of launch control button (100mS scale, 0-25.5 seconds) * launch_out_pwmlow ** start pwm ramp from this setting (% dutycycle) ''can share config byte with launch_out_pwmhigh if we are out of space'' * launch_out_pwmhigh ** end pwm ramp at this setting (% dutycycle) ''can share config byte with launch_out_pwmhigh if we are out of space'' * launch_out_pwmramp ** time for pwm duty to ramp between pwmlow and pwmhigh (100mS scale) *launch_out_ontime ** time for function to stay active after release of launch control, if button isn't re-activated before that. Output goes back to launch_out_conf_offstate setting * launch_out_conf ** bit0: launch_out_conf_enable *** disable/enable whole function ** bit1: launch_out_conf_pwmramp *** disable/enable pwm ramping function ''Can be replaced by possibility to configure ramp from 0-100% in 0 mS, if 0% is fully off for sure, and 100% is fully on for sure'' ** bit2: launch_out_conf_offstate *** state of output channel when not activated, 0=off, 1=launch_out_pwmlow dutycycle (this setting is not important, just thought someone might need it.) ** bits 4:7 launch_out_conf_pwmfreq *** same as boost_conf_pwm ---- These 2 functions proposed can and will be used at the same time, by wiring launch_out_channel to n2o_input channel, through an arming switch. ---- '''Second Stage fuel pump control''' Many fuel pumps consume a lot of current, we can drive low load on one pump, and activate a second stage on configured threshold, This has to stay on for a configurable time, we dont want them switching on and off all the time. will need 1 config byte ---- addition to misc1 and/or misc2out settings: * miscXout_min_ontime (0-15 seconds for each channel, sharing one config byte for both misc1 and misc2 ? 0 is disabled = miscout works as usual) ---- All 3 of these propositions has to work with 1.0.xx firmware, as we cannot run simple trigger without camsync on 1.1 branch firmware, and the fact that 1.0 is more stable. //Emil
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.