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.
- 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)
- 8 MAP bins is enough for the ignition/VE for highest boost engines
- 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.
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 )
Why matfactor.c and thermfactor.c files (and also inc files) are 'similars' in recent firmwares ?
Should it be so that airdenfactor.c should be similar with matfactor.c and not thermfactor.c ?
At least MSTools, Easytherm etc. generates matfactor and airdenfactor files from same air temp sensor data and thermfactor contains settings for coolant thermistor sensor or I'm missing something ?