** real table size inside ECU remains always same, no changes to firmware

** tuningapp shows only used fields (with sane values), custom table size.

** unused fields are filled with max value (over the used range), limits max usable bin value by 1.

** splitting means moving all the next rows/colums to next position

Example 3x2 table would look like below. What do you think about the idea?

|| ||10||25||75||FF||..||

||10|| || || || || ||

||99|| || || || || ||

||FF|| || || || || ||

||..|| || || || || ||

* I thought about something similar, but maybe more flexible (and possibly expensive):

** user could provide arbitrary precision functions, in the same way as patches are modelled in 3D.

** he could of course "edit" the gridpoints of the patch in a chosen resolution (ie: table)

** the tuningsoftware would revise a table representation of the patch, where the linear-interpolation gives the best possible match. This can be implemented relatively simply with either

*** simulated annealing or

*** genetic algorithm

** the user could provide a weightmap (or choose between default weightmaps) so that in given loadsites any error in the approximation weights more than at other loadsites.

** while the patch approach might seem more problematic at first, it eliminates some naughty and unprecise operations related to editing axis-bins, inserting lines, cols.

* stimulator device, with support for more IO: Turn Mik's perl scripts into a product that he used to stimulate the lucas ECU with several signals.

* Nice outputchannel configuration: (The dirty solution is 2 connected dropdown-boxes for each ..._channel config variables. example: "INJFET" and "4" ). Ideally, the tuning program should support the configuration as the table on MembersPage/MarcellGal/EngineSwap/Wiring:

** starting out from a default EC36 pinout

** allowing to hide NC (unused, not connected) pins (table-lines)

** allowing to force changes of (text of) pin functions (eg. if the MAP is connected onboard to an unused EC pin)

** allowing to control a pin from a specific ..._channel function. While the above were simple text-editing and remembering, not related to config, the result of these selections are reflected in config in the relevant ..._channel=.. and h[0] and h[2] values. Relatively simple, yet very efficient.