GenBoard/UnderDevelopment/FirmWare/ConfigRelated (2007-03-30 21:54:48)

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

the number of required bins is surprisingly low.

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:


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.


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.

lambdacorrinternal_lcorr=lambdacorr+200lambdameaning65535/internal_lcorroptimal megatune value
0200 256/200 = 1.28 lean327.68255
56256 256/256 =1.00 stoich256 ? eg. 183
255455 256/455=0.563 rich 144.03 0 or higher, eg. 71

The recommendation for the conversion involves an offset of 72 or 73:

Dwell wizard - simple MegaTune calculated value could dwell tuning easier


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.


Unused variables cleanup

Although ALS is implemented and used, it's not easily configurable:

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.

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):