_     
 | |    
 | |    
 | |___ 
 |_____|
        

           
     /\    
    /  \   
   / /\ \  
  / ____ \ 
 /_/    \_\
           
           

   ___  
  / _ \ 
 | | | |
 | |_| |
  \__\_\
        

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

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

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:
'''This page lists important changes to the firmware. Check this before downloading a firmware that is meant for production''' '''When updating the board with latest firmware, READ EVERYTHING BETWEEN OLD AND NEW REVISION''' and check if any of the changes affects your configuration. Take action if necessary. For example, if you used an 1.0.13 firmware, and upgrading to (eg. 1.0.23), when reading through all changes for intermediate releases, you will see (at 1.0.14) that fuelcut_min_kpa must be adjusted reasonably. If you skip 10 mins to read through, you'll sit in the cold car for hours and wonder why the engine does not start and notice injector pulsewidth is 0. Developers: please update GenBoard/Manual matrix when configuration semantics change. Ask on that page (in the relevant matrix element; make a line if necessary and start to put in links you find) for questions about config variables. '''You can report problems/bugs on this page:''' IssueReports ---- '''Users upgrading to 1.0.36 and above please note:''' There are some issues with the ALS configuration that may not be apparent when upgrading your configs from an earlier version. These are detailed MembersPage/GaborRacz/NewAlsLaunchAndOthers Windows users have an easy solution to solve this issue detaile at MembersPage/PhatBob/ALSConfigFix ---- '''Downloadable firmware releases'''. These are not intended for compilation. See SubVersionSvn if you want to get involved in development. Publish the my_make on your MembersPage if you just want a firmware compiled with some special options. The "Genboard Public Licence" allows modification of firmware (algorithimic changes, additions etc) if the modifications are sent back to authors. Much of the sourcecode was published, and everyone so far who sent modifications got read-write access to the firmware tree. Because of repeated (intentional or unintentional) violations of the copyright, developers decided to apply control over the sourcecode that allows well-intended use but prevents violation * "normal" customers don't (and shouldn't) need to modify firmware * anyone with skills to modify firmware who want to do so: apply for access. See SubVersionSvn . Don't forget to detail your plans ("I implemented / I want to implement ..., concept is ..., any simulations, or PC-testcode, etc...) * an NDA is necessary that allows modifications (algorithimic changes, additions etc) for self-use or use in reselled VEMS products, but does not allow carrying the code (or concept) to competitive products. ** So open is really not open (open is open when you have right to modify to your own non commercial needs, without opensource 'virus' effects), as per above licensing sentence - and of course this openness don't mean anything competitive actions which might violate your rights or NDA etc. stuff, but just own code modifications to own or customers using controllers supplied by you - use. ** Above also means, that one can't gain - software vice - any competitive edge, if I use 'one single line' of your code - not even when using assmembled controllers/kits supplied by you. ** Yet, NDA can work both ways, but why one should bother ? ** And of course one have plans and some succesfull implementations like overlapping events*, mapped individual cylinder fuelling trimming, double PWMmed fans (individual settable trip points), EGT safety functions OBDII/EOBD with regulations/drive cycle functions and more. *Althought Motorola and Siemens has far better processors for engine control than this -> fex. more capture compare units, IO, memory etc.). Maybe one should start yet another project from scratch ;) '''Changelog''' '''1.1.5''' * ALS retard and igncut RPM ranges, see MembersPage/GaborRacz/NewAlsLaunchAndOthers * als_enrich fades with retard (not applied at all at max TPS) * below (iac_cold_rpm + launch_rpm)/2 RPM, the shiftcut is not activated (that is daily street driving or idle). But activated during race driving. * in the highly experimental http://www.vems.hu/files/Firmware/release/EXPERIMENTAL/ VemsMT-1.1.5-pre6.zip see the README.txt and beware of a few catches: ** firmware 1.1.5 included, but you might need to upload firmware with the help of an old megatune (the COMx.txt solution does not seem to work on all win, even within XP it works some PCs, not on others. Will not be fixed, because soon replaced by a new GUI firmware upload application) ** avoid changing h[2] ign sequence (or verify in mct if you do), change h[1] reference tooth instead ** but other than that, it should be fine, including the new ALS variables seem to work OK. Note that als_retard changed to 0.5 degree resolution, so max retard is 127.5 degree. ** config.txt and tables.txt example for Fero, 36-1, 4cyl wasted spark engine '''1.1.x overlapping dwell and timing from last tooth (coil-type is not supported in 1.1.x yet)''' Running well on 15-1 and 60-2 wheel with camsync and without camsync (any other multitooth N-1 and N-2 should work).[http://www.vems.hu/files/Firmware/release/v3_firmware_1.1.4.zip 1.1.4 NOT YET RELEASED]. '''Several variables need to be set properly for it to work''' * tooth_wheel_twidth1=18 # normal tooth width in quarterdegrees. decimal 24 quarterdegree that is 6 degrees (for 60-2 wheel) * tooth_wheel_twidth1=48 # missing tooth width in quarterdegrees.decimal 72 quarterdegree, that is 18 degrees (for 60-2 wheel) * reset_engphase_after - this is a bit stupid now, might change in future: ** reset_engphase_after=40 # with camsync # since 720 degrees = 2880 quarterdegrees = 64 (modulo 256) ** reset_engphase_after=A0 # when NO camsync # since 360 degrees = 1440 quarterdegree = 160 (modulo 256) * h[1] is the reference tooth array (trigger_tooth and ign_tdcdelay is added to this to get TDC), for each output specified in respective h[2] entry. Examples: ** h[1]=1E 00 1E 00 .. .. .. .. # 60-2 4 cyl (tooth 00 and 30) *** another_trigger_tooth=1E ** h[1]=8A 3C 1E 00 .. .. .. .. # 60-2 4 cyl with camsync (tooth 00,30,60 and 90) *** another_trigger_tooth=1E ** h[1]=60 48 30 18 00 .. .. .. # 60-2 5 cyl with camsync (tooth 00, 24,48,72 and 96) * also, set camsync if appropriate * als_retard changed to 0.5 degree resolution so max 127.5 deg retard is allowed (relative retard: it was absolute in 1.1.2 but we decided orig behavior relative is the way to go so interpolation works best) '''Since 1.0.53''' http://www.vems.hu/files/Firmware/release/v3_firmware_1.0.53.zip - reasonably well tested * LCD config routines have been reworked. The PWM controlled backlight and other options are not correctly enabled when their bits are set to 1 not 0. This is not consistant with the documentation found in global.h and the behaviour of megatune (see latest vemsv3.ini file). * Software brightness has been implemented for noritake VFD screens. '''Since 1.0.50''' - experimental, but low risk * mdd04 has more useful InputTrigger/AudiTrigger (primary trigger toothcount at the time secondary trigger) triggerlog that works high RPM too (mdd0c only useful for cranking because of serial baudrate!) '''Since 1.0.49''' * compiled with -D ONLY_LAST_TOOTHTIME allowed extremely fast revvup MembersPage/YasecElise to start '''Since 1.0.46''' - http://www.vems.hu/files/Firmware/release/v3_firmware_1.0.46.zip '''COUNTER-recommended, interpolation-problem, compiled with new compiler... stick to 1.0.45 or a recent version''' * injpwm6 was dropped (reasonable injpwm-DC calculated automatically from battery voltage) ** als_launch_input ( ALS and Launch activation input channel selection) was added in place (so with MegaTune injpwm6 "added pwm-duty" can be used to tweak it, until MegaTune vemsv3.ini gets updated; verify with mcd anyway). *** 0xFF = ALS and Launch activation are original default SDA and SCL *** 0x43 (decimal 67) ALS is mcp3208 channel 4, Launch is mcp3208 channle 3 *** 0x62 (decimal 98) ALS is mcp3208 channel 6, Launch is mcp3208 channle 2 *** ... you get the idea. Pull to 5V with a (1k .. 20k) pullup resistor, and pull to GND with a switch / button. '''Since 1.0.45''' - http://www.vems.hu/files/Firmware/release/v3_firmware_1.0.45.zip * very minor change: for idle solenoid, if PWM period=0 configured, than original extremely-fast softpwm applied (instead of the nicely controlled period as now). Some audi idle solenoids like it. '''Since 1.0.44''' - [http://www.vems.hu/files/Firmware/release/v3_firmware_1.0.44.zip 1.0.44 experimental prelease] * ego.correction initialized to start from 100% (no leaning for a split second when WBO2 just warms up and ego starts to act that caused hickup) '''Since 1.0.43''' - [http://www.vems.hu/files/Firmware/release/v3_firmware_1.0.43.zip 1.0.43 experimental prelease] * '''tach output tach_div changed to allow precise fine-tune of the output'''. 16 (hexa 10) is the default, results in 1 tach pulse for each event. For a 5cyl equipped with a 6cyl tach gauge use tach_div=0D (decimal 13: 6 * 13 /16 / 5 = 0.975 that is 2.5 % error); * note: >100% injector duty code rewritten because of a misunderstanding. This should be good (but not well tested), but testing didn't reveal problem with old code either (only found some strange unreasonable config eg. injpwmt=24msec injpwm=6% duty that - although does what it should, can confuse the unaware). * 1.0.43 has better initial sync for multitooth N-2 or N-1 wheel with camsync (note that it needs lucky missing-tooth and camsync relative position to work always well with in 1.0.42 and before). '''Multitooth advanced filter changed''' - neglect if you don't use it (but read if you like primary_trigger=09) * toothrel_normal=Nn #tg_prev * n/16 <= tg <= tg_prev * (1+N/16) * toothrel_missing=Mm #tg_prev * (1.25 + m/8) <= tg <= tg_prev * (2.5 + M/8) '''Multitooth advanced filter OLD semantics - before 1.0.40''' If the tg (time-gap) between 2 teeth compared to tg_prev (previous time-gap) * if( tg_prev * (1-n/16) <= tg <= tg_prev * (1+N/16)) than it's '''considered normal tooth''' * if( tg_prev * (1.5 + m/8) <= tg <= tg_prev * (2.5 + M/8)) than it's '''considered missing tooth''' '''Multitooth advanced filter NEW semantics - since 1.0.41''' If the tg (time-gap) between 2 teeth compared to tg_prev (previous time-gap) * if( tg_prev * n/16 <= tg <= tg_prev * (1+N/16)) than it's '''considered normal tooth''' * if( tg_prev * (1.25 + m/8) <= tg <= tg_prev * (2.5 + M/8)) than it's '''considered missing tooth''' As you see, for the missing-tooth condition, original 1.5+m/8 changed to 1.25+m/8 ... Also, the "n" changed, that is the lower nibble of the toothrel_normal. In new, recommended values: * toothrel_normal=85 # (decimal 132) for either N-1 or N-2 * toothrel_missing=D6 # (decimal 214) for N-2 and 22 (decimal 34) for N-1 '''Since 1.0.36''' - ALS made nicely configurable (variables not collide with knock2) * It is '''extremely important to not leave any random data in the ALS variables''' (because it might retard heavily or add much fuel, etc...) Adjust the variables even if ALS is not used: see "disable" on the bottom of MembersPage/GaborRacz/NewAlsLaunchAndOthers '''Since 1.0.34''' - beware that this was accidentally compiled without AUDITRIGGER option (in my_make), that is without 135-tooth support. We'll compile 1.0.35 soon. * some variables dropped that you'll not feel sorry for; * if your '''iac_integral_speed''' was significantly lower than 0xFF (255) and your iac PID is already tuned fine: using a factor of 256/iac_integral_speed : ** scale up iac_integral_limit_dec ** '''and''' iac_integral_limit_inc, and scale down iac_pid_ki * earlier iac_ign_advance_change and iac_ign_retard_change merged to a common iac_ign_slope * awec allows 3 times longer afterstart than earlier awc (unit is 6 crank rotations vs. previous 2 crank rotations). Note: decay is slower in the first half of the afterstart * '''new als variables''': see MembersPage/GaborRacz/NewAlsLaunchAndOthers for how to configure or disable '''Beware, [http://www.vems.hu/files/Firmware/release/v3_firmware_1.0.32.zip 1.0.32] .. 1.0.35 is not released'''. Only a compiled snapshot. BMW dualpwm is believed to be fixed. my_make has ALS, SOFTLAUNCH and other enabled in a way that doesn't collide (cheers!) with misc2_output options (like in 1.0.31: therefore 1.0.31 is not recommended even for testing). Requires in-depth megatune (vems.ini) knowledge (it should be a 20 mins vemsv3.ini job for someone knowledgable, plus 80 mins testing!) Don't use it unless you are testing and absolutely know what you are doing. * I drove around with 1.0.33 and it seems to work fine. I used an old MegaTune (r028 or so that was already installed) - the variable offsets are unchanged (except for the meaning of some previously unused or "of little use" variables). Others drove around with 1.0.34. '''BEWARE: 1.0.30 is not released''' - no known problems so far (been used on several cars for weeks now). BMW dualpwm air-valve users made an improvement that should go into 1.1.0 (or 1.0.31, but soon time for 1.1.0 number). Not suitable for recompile, but EasyTherm provides hexpatch utility (and manual method) for changing temp-factors. * iac_conf bit5=1 (add 0x20 == decimal 32) enables dualpwm. Configure PWM-iac (precise-idle, but stepper disabled), and set this bit. The iac_sol_channel is PWM-ed normally (like a PWM valve) and the next GenBoard/Manual/DigitalOut channel (see GenBoard/Manual/DigitalOut/Table) is PWM-ed inverted. This is useful for the BMW type valve, see MembersPage/GergelyLezsak/IdleControl and MembersPage/GergelyLezsak/IdleControl/Firmware for more info. * iac_speed is removed from the upper bits of iac_conf, removing the double bit(4) allocation. iac_afterstart_steps config variable is removed and replaced by '''iac_speed''', pwm frequency is now adjustable (as is stepper speed in steps/second) from config through adjustment of iac_speed variable (higher iac_speed means lower frequency / steps/second) ** iac_pwm_frequency = 1 / ((4 + iac_speed & 0x3F) * 4uS * 256) = xxx Hz ** iac_stepper_speed = 1 / ( (1 + iac_speed & 0x3F) * 1024uS) = xxx Steps / S * the default tables (that anyone can change for himself, see EasyTherm) changed slightly: airdenfactor -40C (first=0 and last=0xFF position) will no longer assume faulty sensor. * 0V on MAP sensor (which normally does not happen) will no longer mean 100kPa (limphome). But kpafac=00 (otherwise stupid value, since 2kPa MAP sensor range is meaningless ;-) will mean 101 kPa so anyone can trigger limphome from keyboard if he knows what he's doing. '''since [http://www.vems.hu/files/Firmware/release/v3_firmware_1.0.29.zip 1.0.29]''' - '''Experimental, use at your own risk''' * InputTrigger/AudiTrigger seems to be working on the batch with one known problem: must be rebooted if trigger is lost (switch off ignition for a second if engine stops). Care is needed to provide clean input signals, eg. not injecting primary trigger into secondary trigger input (via capacitive coupling). mdd04 provides binary debug with appr 5+3 bytes per camrot, while mdd0c is verbose binary debug with appr 273 bytes per camrot. Capture and publish binary logs (with notes of how they were taken, eg. RPM) in case of any problem. mdd00 switched auditrigger debugging off. '''since 1.0.23''' * shiftcut_conf default=00 (old behavior, disables igncut and shiftcut stuff) ** bit4=1 enables fuelcut when shiftcut is triggered ** bit1=1 enables spark-cut for shiftcut_time * 4 msec time when shiftcut is triggered ** bit0=1 enables spark-cut at rev_limit - 200 RPM (ignition based redline instead of fuel based) * shiftcut_channel specifies mcp3208 input channel: default 0xFF disables shiftcut; 0..7 enables shiftcut for configurable time (shiftcut_time * 4msec) after the given mcp3208 input channel (default is 06 for mcp3208 channel06, that is mcp3208pin7) is pulled to ground * Now the temp calibration tables (airdenfactor, matfactor, thermfactor) live on dedicated flash-pages, so can be changed independently from the rest of the firmware. ** Either tweaked in the vems.hex file before uploading the whole vems.hex ** or in the flash. However, this requires a new bootloader, as unfortunately the old bootloader does not support erasing just one page :-( (only the whole application-part of the flash) '''since 1.0.18''' * fixed tps acceleration enrichment. It left infinitely small time for user to press TPS in the last couple releases: effectively disabled tps accel enrichment. The sampling is now synchronized to the tps acceleration enrichment calculation, so result should be more deterministic than earlier. * note that interpolation of the n[] table (ignition advance) was not fixed because no problem was found: it tested perfect! '''since 1.0.17''' * boostcontrol configured with MAP-target considers the scaled MAP (not the MAP sensor input voltage) * boost_conf bit3:2 00,01,10,11 means 20,40,60,80% reference position for the solenoid. 40% or 60% recommended if otherwise no idea. (TODO: someone check the generated assembly code for overflow at the 8*8 bit multiplication - result should be 16bit). '''since 1.0.16''' * small firmware bugfix: from megatune config.primep was altered instead of element 0 of the b[] table (boostcontrol-target) '''since 1.0.15''': * the new (1.0.14) '''fuelcut_kpa is renamed to fuelcut_min_kpa'''. Meaning is unchanged, read below * new variable to prevent overboost (useful until the boostcontrol PID is tuned) '''fuelcut_max_kpa=FF to disable'''; fuelcut_max_kpa=F0 to cut fuel above MAP > 240 kPa (assuming the default ''MY_CONF += -D KPA_CONFIG_RESOLUTION=1''; naturally same meanse 480 kPa for ''MY_CONF += -D KPA_CONFIG_RESOLUTION=2'') * tach_channel=FF to disable * tach_divider=.. is not used. Use FF for now, I think 00 will be used finally to disable completely '''since 1.0.14''': * 8,10,12 or 16 cyl support with multitooth wheel * Compiled with 12x12 maps. Known (optical) bug: h-table is apparently 12 element wide on LCD * fixed the boostcontroller bug, that effected boost-target (calculated from the TPS and t[] and b[] table). If you are planning to use boost control, get this bugfix. * the firmware intro has been re-introduced to the LCD code and tested. This is an optical feature but tells the user what firmware revision they are running. * some boostcontroller items have been added to the display * changed airdenfactor to not lean any more above MAT > 60C (actually, it enriches above MAT > 60C with appr. +0.1%/C ). Below MAT < 50C the universal gas-law is followed (which is appr -0.33%/C). A small plateu is applied from appr. MAT=50..60C * added '''lowmap_fuelcut function: config.fuelcut_min_kpa=0E''' recommended (fuelcut under 14 kPa) or up to 12 (fuelcut under 18kPa). The hysteresis is compile-time (3kPa, and applied as config.fuelcut_kpa + LOWMAP_FUELCUT_HYSTERESIS). Those who use KPA_CONFIG_RESOLUTION=2 (for extreme boost; rare) know that every MAP-kpa related config values must be multiplied by 2 (so max range is 510kPa and 09 means 18 kPa): fuelcut_kpa is no exception. fuelcut_kpa=00 gives old behavior (disables lowmap_fuelcut), but why would anyone do that ? It is '''extremely difficult to tune''' injopen, injocfuel, kpaoffs and other config variables that become significant at low-MAP ''' for nice engine operation at MAP=0..10 kPa '''. The result was engine-stumbling when you suddenly get your foot off the throttle - the iac reference positions, config.iac_integral_limit_dec and overrun_fuelresume can be tuned to eliminate the stumbling by ensuring MAP > 10kPa always holds at RPM < overrun_fuelresume, but appropriate fuelcut_min_kpa value ensures fuel is cut even if those crazy-low MAP values - and therefore short pulsewidths - are reached. This works so well that config.tpsdq related decel-fuelcut seems quite useless, scheduled for demolition in the near future. '''since 1.0.13 rc5''': * Tested with MegaTune r021, the high resolution MAP and RPM shows correctly in megatune. * New config variables for '''advanced multitooth filter''': config.toothrel_normal=0x8A recommended (for either N-1 or N-2 wheels). config.toothrel_missing=0xB5 (for N-2, eg. 60-2) and config.toothrel_missing=0x00 (for N-1, eg. 36-1). Actually, '''these only matter if the advanced multitooth filter is enabled''' by config.primary_trigger bit3=1 and multitooth is configured bit1=0 (thus primary_trigger=09 instead of 01). If using the values recommended earlier: primary_trigger=01 for multitooth, or primary_trigger=FF/FE for "coil-type", the new (toothrel_normal and toothrel_missing) variables do not effect operation at all. For multitooth (either with the advanced filter ON or OFF ), watch the wheel_error counter (W.. on the top of LCD page 01: mlp01), if it keeps increasing, the trigger setup must be examined. A few counts during startup (cranking) is normal. '''since 1.0.13''': * camsync improvements * resync if VR trigger has noise during cranking * unfortunately rc5 was compiled with decreased trigger resync-noise-suppression (mostly used at first-crank) values (since than reverted, to decrease chance of firstcrank misfire in case of noisier setups) '''since 1.0.12''': * better MegaTune compatibility (vemsv3.ini r16 or newer) '''since 1.0.11''': * kpa configuration resolution '''can be''' changed to 2kPa (but is 1kPa by default) for very high boost engines: add ''MY_CONF += -D KPA_CONFIG_RESOLUTION=2'' to my_make * Note1: changes also needed in MegaTune vemsv3.ini * Note2: all the following config variables change to max 510kPa range (2kpa unit): ** k[] table ** ego_maxmap ** config.inj_stage2_start_map ** tpsdot rates ** hybrid_rpm_a ** hybrid_rpm_m ** some kpa text on LCD will become 2 kPa (eg. the axis in mtt menu) ** misc1out_minmap ** misc1out_maxmap ** misc2out_minmap ** misc2out_maxmap ** ve_learn_kpa_scale (this is not in 2kPa units, but it needs to be doubled ?) * restart not needed after adjusting wbo2_nernstdc_target (from menu) to take effect. * iac integral starts at max value, not 0 (higher iac position => faster startup without throttle) * better wbo2 leave_warmup condition (leaves warmup and starts normal heater control earlier if sensor was warm for some reason; eg. because of mde02) * after ''mdd02'' command, fuel is cut if throttle is pressed (above tps_thresh). This can be used to calibrate WBO2 free-air calibration with WOT and fuelcut (or as a minimalistic "antitheft"). ''mdd00'' changes back to normal behaviour. * comm.c changed for recent r008 MegaTune (more variables logged) * in the r1.0.11 minor lcd_display changes: "RPM:" string was addded (back), and fixed the scale of free-air o2 on LCD * in the r11 there is a new feature on LCD page00 (mlp00): La:... shows Lambda (like "0.95" or "1.02") or O2% (like "20.7" - note that the dot moves to different position in this case!) or undefined (??.?) ** note: there was a small problem with 02 display, so in the r11_v2 in lcd_print_current_o2() a small fix was made to lcd_print_XX_X( t32 >> 8 ); ** note: 'mde02' command must be used to switch on WBO2 unless engine is running (trigger is applied). This is intended this way. '''since 1.0.9''': camsync with coil-type primarytrigger (not restricted to multitooth). '''VERY IMPORTANT: USE secondary_trigger=02 if you don't use camsync, otherwise (eg. with commonly used FF value, that works no more) you won't get spark nor fuel nor automaticly activated WBO2 !!!!!''' '''Remember:''' * WhatEverYouDoYouDoItAtYourOwnRisk * GenBoard/Manual/License/WBSensor applies to the release, since it has WBO2 enabled in my_make ---- '''2005-02-20''' * committed 2x20 LCD support. This is identical to 4x20 except that it has twice the number of pages. Every second page is just the bottom 2 lines of the 4x20 version. '''2005-02-08''' * stable revision of 2004/11/24 16:00 was tagged as STABLE_1_0. This was done in order to separate alpha quality code found in HEAD with tested production quality code we should be running. Each revision tag will only be modified with bugfixes. '''2004-10-31''' * BoostController (old variables not changed) and improved injector-opening rampup control. '''injocfuel semantics changed''', see GenBoard/Manual/Config/InjectorOpening '''2004-10-27''' * '''Improved idle control'''. Ignition advance is adjusted to maintain a constant idling rpm. To disable this feature, set iac_ign_advance_change=00, iac_ign_retard_change=00, iac_ign_advance_limit=00, iac_ign_retard_limit=00, iac_ign_threshold=ff. ---- '''2004-10-10''' * '''speed-density precision bumped up greatly. The first chance ever for the diy-ers to do precise fueling for turbo engines'''. The old semantics we used earlier (inherited from motorola-megasquirt) used 4% (!) steps at 25kPa MAP (and 1% steps at 100kPa). This was the last remained inferior signal precision in the whole fuel-calculation (we made everything nice in the meantime, eg. ego correction. this waited somehow...). Now this signal is 11 bit internally (1/20 %). * '''set config.kpafac to your MAP range [2kPa]'''. ** 2.5 bar MAP sensor: 7D ** 1.15 bar MAP sensor: (hexa) 39 ** 5.1 bar MAP sensor (impressive boost !!): FF (max value) if ''kpafac'' value is set to 00 (not recommended), the old behavior is maintained, where ''(config.config11 & _BV(MAP_SENSOR))'' decides if the 2.5 bar or 1.15 bar lookup table is used. This way it is possible to configure nonlinear table (not sure if it is useful), but precision is inferior (anyway, it is possible to make precision better: tell us if you need nonlinear for some reason, and higher precision). '''Note that this makes GenBoard/VerThree the first diy ECM that supports boost pressure higher than 150 kPa without hack'''. (this was the main reason for the change: a racecar runs at 200..240 kPa boost and they asked us to make precision superior) ---- '''2004-09-17''' * eventqueue changed in some ways: ** more reasonable inlining ** faster reaction ** better readability CVS head, with eventqueue.c 1.96 (or earlier 1.94, but not 1.95 experiment) is good for production. Played with eventqueue, make it simpler and faster. For readability and marketing reasons; because some people are concerned about parameters that cannot be measured in engine output, only on oscilloscope. At '''15000 RPM''' measured 6/20 degree average delay in the ign signal, this is now lowered to about 4 / 100 degree (could be even better with further changes). This is '''so close to theoretical optimum 0.000000 sec that it means less than 0.3C degree in intake temps (MAT)'''. ---- '''2004-09-12''' * comm.c tabledump improved so it can send out the 16x8 table (if someone forgot what he sent in :-), someone please test mct command (write here) -> mct command verified, j/l/n/r 16 wide, h/k 8 wide - DB . If VE_TABLE_FIX is defined in my_make (what a bad name !!!) the 16 bit learnt VE table is outputted in j[x]=xxxx xxxx xxxx ... format, possibly 16 values on a line (if VE_SIZE_RPM=16). ---- '''2004-08-27''' * config.cwl, cwh, injpwmt and primep can be configured to higher than 25.5 msec : see GenBoard/Manual/Config/CoolantTemperature '''2004-08-25''' * knock sensor code is now allowed to modify ignition advance. Unless you have mounted a knock sensor, set config.knock_conf = 00 AND config.knock_default_retard = 00 such that the actual ignition advance, as specified in the n-table, is unaffected. ---- '''2004-08-08''' * the multitooth branch initialized engine.igncount properly => cranking was long for coil-type setup. (it was immediately obvious from TimingLight table tests, so I guess everyone uses multitooth trigger). Anyway, anyone with coil-type setup should upgrade. ---- '''2004-07-28''' * synchronized o2() to WBO2 calc_afr(). This allows setting faster EGO convergence, without the risk of divergent behavior for bad (speed_limit =) config.ego_pid_kp; config setting. * maybe we could make calc_afr() even more frequent, with increasing the frequency of nernst sampling or just running the pump controller more often. Someone could experiment with it. ---- '''2004-07-27''' * multitooth setup improved. * Dave will test it soon (and document the new variable), and than it worths to upgrade (with multitooth setup). * preparations done for ''time from last possible pulse'' ---- '''2004-07-25''' * change config.tooth_wheel_twidth2 to include the config.tooth_wheel_twidth1 as well (add tooth_wheel_twidth1 at upgrade if you had it configured before); That makes tooth_wheel_twidth2 = * 2 * tooth_wheel_twidth1 for a 36-1 and * 3 * tooth_wheel_twidth1 for a 60-2 ----- '''2004-07-07''' variable intake actuator (simple RPM-based switch) and WOT actuator (that switches at WOT, but only above a certain RPM) for NOS made easily configurable. Both the RPM and the output channel is configurable. On GenBoard/VerThree you can select a free channel, which can be a 100A FET if you like (like IRL2203, but the connector cannot handle that current). Even several channels (this is only for the injector FETs) can be selected to switch at the same time, according to GenBoard/Manual/DigitalOut '''Set all these config variables to FF if you don't need the feature:''' <code> uint8_t act_wot_rpm; // WOT switch RPM threshold (FF=disable) uint8_t act_wot_channel; // WOT switch output channel selector (P259_0) uint8_t act_rpm_rpm; // RPM switch RPM threshold (FF=disable) uint8_t act_rpm_channel; // RPM switch output channel selector </code> Iac.conf is extended to select between a ON/OFF idle air valve, and a PWM controlled type by unsetting/setting bit 3 of iac.conf See IdleControl/IdleValvePWM ----- '''2004-05-26''' Lambdacorr table is now unconditionally used. If no l-table was used before, then add the following (stoich) table to tables.txt <code> ### lambdacorr: afr=14.7 ### l[0]=38 38 38 38 38 38 38 38 l[1]=38 38 38 38 38 38 38 38 l[2]=38 38 38 38 38 38 38 38 l[3]=38 38 38 38 38 38 38 38 l[4]=38 38 38 38 38 38 38 38 l[5]=38 38 38 38 38 38 38 38 l[6]=38 38 38 38 38 38 38 38 l[7]=38 38 38 38 38 38 38 38 </code> The lambdacorr-values are a multiplied enrichment: <code> lambdacorr = (l+200)/256 </code> You can see that 56 (hexadecimal 38) means a 1.0 (stoich) lambdacorr value. ---- Discussion about a limphome feature: GenBoard/UnderDevelopment/FirmwareChanges/LimpHome ---- Release system discussion: GenBoard/UnderDevelopment/FirmwareChanges/TestingAndReleases
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.