______ 
 |  ____|
 | |__   
 |  __|  
 | |____ 
 |______|
         
         

   _____ 
  / ____|
 | |     
 | |     
 | |____ 
  \_____|
         
         

         
|\     /|
| )   ( |
| |   | |
| |   | |
| |   | |
| (___) |
(_______)
         

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

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

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:
* Idea about flexible table bins (autronic style) ** 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.
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.