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
With the
- applied interpolation
- configurable (not fixed) bins
- 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
- 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)
For 1.1 release, config variables to be dropped or shrinked (so the offset position can be used for sg. useful.) Marcell makes 1.0.32 experimental compile. ALS variables are not grouped for now, just use where they drop in for the minimal MegaTune changes. MegaTune maintainers can diff global.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.
- DONE: free1
- DONE: free2'''
- DONE: mt_unused
- DONE: wbo2_warmup_target (killed)
- ign_balance seems unused now (0)
- 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
- injpwm6 - could be 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...
- wbo2_edgetime_corr and wbo2_edgetime_min: will be dropped after a slight change in wbo2.c
- 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
- 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)