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

 _____ 
(  _  )
| (_) |
|  _  |
| | | |
(_) (_)
       
       

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

   ____ 
  / ___|
 | |  _ 
 | |_| |
  \____|
        

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

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''' - missing tooth trigger installs (N-1 or N-2 with or without camsync) and InputTrigger/AudiTrigger (135+ tooth wheel) users (especially with big-ignadv-window ALS) will likely prefer 1.1.x, while others usually still stay with 1.0.x for now (though this will change) '''[http://www.vems.hu/download/v3/firmware/ 1.1.32]''' - only for testing new features on the bench (eg. to test modified MegaTune vemsv3.ini). Don't upgrade from 1.1.27 * '''very important to read all changes between versions you upgrade from-to. Notably a very important change in 1.1.30: missing-tooth wheel users likely need to adjust tooth_wheel_twidth2 (labelled "width of missing tooth" in MegaTune), likely to 00'''. This (width of tooth!!!) effects spark timing. This is very important. * solenoid PWM iac compensates with measured VBATT, so it's somewhat easier to tune with a Bosch alternator where VBATT depends on RPM at idle (unwanted positive feedback). ** Solenoid iac duty=0 (unpower iac) after pump_on_mintime (same behavior as fuelpump), and only apply cranking iac position after cranking starts * '''config.ign_dwellmap''' configurable MAP-based dwell scaleup (VBATT based is automatic) ** 00 no dwell extension at all (neither VBATT nor MAP based): ign_dwell14 is used ** 01 only VBATT based dwell extension (max *2, when VBATT <= 7V) ** values 02..FF : VBATT based extension is automatic. Slope of MAP-based dwell-extension is configured with this variable. MAP-based extension is max *1.4 (+40%), while total scaleup (vbattmultiplier * mapmultiplier) is max *2 *** dwell is extended by (map - 70kPa) * ign_dwellmap/4096 but no more than +0.4 (40% extension that is *1.4). Examples: *** ign_dwellmap=0A (decimal 10) max dwell-extension +40% reached at 234 kPa because (234 kPa - 70 kPa) * 10 /4096 = 0.4 *** ign_dwellmap=14 (decimal 20) max dwell-extension +40% reached at 152 kPa because (152 kPa - 70 kPa) * 20 /4096 = 0.4 *** higher value means higher slope (so max dwell extension reached earlier). Take care not to overload the ignition output or the coil (use lower ign_dwell14 so you only get extended dwell when really necessary). * '''config.iac2load''' see GenBoard/UnderDevelopment/AlphaNIAC ** When rpm < hybrid_rpm_m the iac.position is added to load before table-lookup (for all tables: VE, ign, lambda). Basically proportional to the iac/throttle ratio. Formula: iac.position * config.iac2load /256 / 8 is added to load, that is max 31 if iac.position=FF and iac2load=FF. iac2load=FF is throttle/8 size (area) iac, that would be extremely big. Probably iac2load=06 or similar values could be more realistic (iac 341 times smaller area than throttle). Because of the throttle shape (special at low-TPS) you might need some experiment and logging to tune it * the P and D terms in PID boost became asymmetric. The main difference between simple-boost and PID boost was this (simple-boost was asymetric and therefore easier to tune) * switch-activated '''full-table-and-config-swap'''. Expert feature, must upload valid config+tables to both storage (2 completely different permanent storage area inside the ECU) separately. Same ignition and injection outputs must be used in same positions (otherwise => risk of blowing ignition fuse and flooding cylinders with gasoline. Therefore this does not allow additional injector-staging-hack features, besides the existing staging functionality). Configuration of storage0 (eg. confswitch=C3) can allow to change to storage1. If you want to be able to switch back to storage0 without reboot, config of storage1 (eg. confswitch=D3) must allow to change to storage0. MegaTune does not know about which storage it reads/writes (closing megatune windows before switching to alternate storage seems wise). Useful for bi-fuel, or special different tables like N2O or similar. Switching can also depend on misc1 condition (TPS, RPM, MAP). After switching, the misc1 condition of the new storage will be used (which can be slightly different, eg. to allow hysteresis). For most applications, rpm < 100 (engine off) is recommended, or at least rpm < 1500 (idle). For N2O, the condition will be different of course. ** confswitch=00 disables switching ** confswitch=C3 does load_variables(1) if mcp3208 ch3 goes low ** confswitch=D3 does load_variables(0) if mcp3208 ch3 goes high ** confswitch=83 does load_variables(1) if mcp3208 ch3 goes low AND misc1 condition is true ** confswitch=93 does load_variables(0) if mcp3208 ch3 goes high AND misc1 condition is false ** any mcp3208 analog input channel (mcp3208ch 0..7) can be chosen with confswitch bit 0:3 ** use it with known-good config manually uploaded to storage1 first (mcS1 command). When tweaking from megatune, verify the result after (both storage0 and storage1) * compiled with BOOSTGAUGE (linear analog voltage output on an internal s259 channel for audi dash boost input) '''1.1.30''' although 1.1.28 - 1.1.31 is not recommended (might misfire under certain conditions (rough running), the related config changes are important: * low-RPM improvements for 8 ( InputTrigger/LanciaCosworth ) and 10+1 ( InputTrigger/MultiToothNoneMissing ) triggers ** 4-1 trigger supported (a 4 cyl VW Golf running on it) since 1.1.29 * '''IMPORTANT: tooth_wheel_twidth2 must be 0 when normal tooth < 64 crankdeg (as usual). tooth_wheel_twidth2 is NOT the width of the missing tooth (any more''', as annotated in megatune), but always the upper byte of the normal toothwidth. Normal toothwidth is in '''0.25 crankdeg resolution''' (no change here). So for a 60-2 the toothwidth is 6 deg ( in 0.25 deg unit that is decimal 24=0x0018) ** tooth_wheel_twidth1=18 (24 in megatune) ** tooth_wheel_twidth2=00 * for a 10+1 where a tooth is 72 degrees (decimal 288=0x0120), ** tooth_wheel_twidth1=20 (32 in megatune) ** tooth_wheel_twidth2=01 * so how will the code know the width of missing tooth for a missing tooth wheel ? If the "special N-1" is enabled (primary_trigger bit4=1) than 2xnormal tooth. Otherwise (N-2 assumed) 3x normal tooth. '''1.1.27 Released''' [http://www.vems.hu/download/v3/firmware/v3_firmware_1.1.27.zip v3_firmware_1.1.27.zip] * seems to run well on many cars (60-2, auditrigger and others) * almost same as 1.1.26, only change is InputTrigger/MultiToothNoneMissing N+1 trigger supported where N<=11 '''1.1.26''' [http://www.vems.hu/download/v3/firmware/v3_firmware_1.1.26.zip v3_firmware_1.1.26.zip] '''for testing ONLY''' - several cars running well on it (including 60-2 triggers) * should work with missing tooth as well (and auditrigger of course). Eliminated a rare-case condition which resulted in ignitioncut (when ecu had to be rebooted) ** more testing is under progress, also with N+1 type trigger (like 24+1 non-missingtooth "coiltype"). Note that overlapping dwell cannot be disabled: distributer is still not supported (except with manually limited dwell considering rev_limit). * launch does not retard spark if RPM drops considerably (control-range) below launch_rpm (allows high retard with otherwise weak turbo engines) * TPS-dot (and MAP-dot) acceleration enrichment kicks in sooner, and fades out gradually. Minor retune of the accelerichment enrichment added fuel amount might be necessary * knock_chan=F0 disables knock. Other values select bank individually for each ignition event (practical for V8, V6, I6 and even I5 where there are more than 1 knock sensors). ** knock_chan=00 selects knock channel 0 for all ignition entries ** knock_chan=FF selects knock channel 1 for all ignition entries ** knock_chan=AA selects knock channel 1 for every other ignition entries. Bit7 is for entry0 (belongs to the topmost entry in the MegaTune ignition output and reftooth tables). 0x55 is obviously the inverse, bit7=0 so the sensor belonging to the cyl fired by the topmost ignition entry must be connected to knoch channel 0 (the only knock channel normally). '''1.0.73''' [http://www.vems.hu/files/Firmware/release/v3_firmware_1.0.73.zip v3_firmware_1.0.73.zip] - released * smarter predictive idle-air control (that worked extremely well, or rather awesome in 1.1.x) merged over (in exact form) * Also included an experimental 16x14 firmware compilation under my_make.16x14 for those who think they need more than 12x12 tables. This will be standard practice from now. Recent vemsv3.ini files have the 16x14 tables as well (but default is 12x12), so easy to use it if you really think you need it. * ALS problem (with ALS configured engine refuses to rev up even without als-switch enabled) was reported: under investigation * '''Can I get this compiled (a new release) with INJECTOR_STAGING enabled in my_make?''' Jorgen and I will both need this. Thanks, Jason. '''1.0.72''' [http://www.vems.hu/files/Firmware/release/v3_firmware_1.0.72.zip v3_firmware_1.0.72.zip] experimental (but likely fine) * stepper chip always enabled, even if non-stepper iac configured. (from now, no need for the dirty trick to enable the internal 0x76 (s259_ch7) through misc output) '''1.0.71''' [http://www.vems.hu/files/Firmware/release/v3_firmware_1.0.71.zip v3_firmware_1.0.71.zip] * minor MAP related changes: speed-density resolution improved further (slightly) * ign dualout (very special config) was broken in last few releases: fixed '''[http://vems.hu/files/Firmware/release/v3_firmware_1.1.18.zip 1.1.18]''' * please do NOT use non-released 1.1.23 (except for auditrigger) without bench-testing ! 1.1.23 is only well-tested for auditrigger and not tested for missing-tooth or other. If really want to try newer than 1.1.18 (why?) than prefer 1.1.22 to 1.1.23 * smarter "predictive" idle air control * minor MAP related changes: speed-density resolution improved further (slightly) * ign dualout (very special config) was broken in last few releases: fixed '''v3_firmware_1.1.16''' * minor ALS change: nonzero corr.als (actual als enrichment) disables ego-correction, but ALS otherwise not (eg. when TPS fully pressed=> ALS enrichment not applied anyway) '''v3_firmware_1.1.15''' * ALS deactivation time (config.als_deact_time) unit changed (from 1 sec) to 0.1 sec. If using an old megatune (that rounds 6.3 to 6.0), set 63 for 6.3 seconds '''[http://www.vems.hu/files/Firmware/release/v3_firmware_1.1.14.zip 1.1.14 (12x12 tables)]''' * '''ALS improvements''': after TPS released, softrpm (ignitioncut) is not activated for als_deact_time seconds, even if RPM drops under als_retard_rpm1 and under als_igncut_rpm1 '''[http://www.vems.hu/files/Firmware/release/v3_firmware_1.1.12_12x12.zip v3_firmware_1.1.12_12x12.zip] is the recommended 1.1.x version''' * use this instead of older 1.1.x (1.1.x branch recommended for missingtooth and "none-missing" multitooth wheels) ** not tested with fiatstilo/subarutrigger (probably won't work, so use 1.0.x) ** not yet tested with coiltype trigger with another_trigger_tooth=01 (but should work, obviously trigger_tooth=00 and remember to set missing tooth wheel as recommended by 1.1.11 SUPRA note). Test on bench first, or use 1.0.x * interpolation updates * added '''individual cylinder power information''' to find misfiring cylinder (even in a v8, easily), or other problems ** YOU WILL NEED [http://www.vems.hu/files/Firmware/release/EXPERIMENTAL/VemsMT1.1.12.zip VemsMT1.1.12] to take logs from 1.1.12 (including individual cyl power info) '''1.1.11''' - old * Tested with none-missing style 24+1 trigger of MembersPage/Fero/SUPRA - check the few config values that matter now for "coiltype" that did not matter earlier. Since 1.1.11 also supports the 5 tooth on crank 5cyl with camsync, called 10+1) '''[http://www.vems.hu/files/Firmware/release/v3_firmware_1.1.10_12x12.zip 1.1.10_12x12]''' - old * MAT-retard disabled when tps <= iac_tps_thresh (so will not effect retard even if MAT sensor is heatsoaked at idle) ** MAT-retard takes full effect above tps > iac_tps_thresh + 12% ** interpolation in between * Beware: undocumented staging changes; Dave used it successfully, but do not upgrade to this (before he documents it) if using staging '''[http://www.vems.hu/files/Firmware/release/v3_firmware_1.1.6.zip 1.1.6 ALS changes midway: NOT recommended]''' * ALS retard and igncut RPM ranges, see MembersPage/GaborRacz/NewAlsLaunchAndOthers * als_enrich fades with retard (no als enrichment applied at max TPS) * only in 1.1.6 (dropped later, and candidate for rework; see ignition-cut based idle on MembersPage/GaborRacz/NewAlsLaunchAndOthers) overrun fuelcut enabled even if ALS switch is on: if the ALS timeout or high-RPM limit is reached * 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 use at least 1.1.6 anyway, and you might need to upload firmware with the help of utils from 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 from MT for now (or verify in mct if you do); get it right in the initial setup (ign wires don't change by themselves), change h[1] reference tooth instead ** '''als_retard changed to 0.5 degree resolution, so max retard is 127.5 degree'''. In 1.1.8 and later the specified ALS retard is "absolute", that is from TDC (not relative retard). '''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''' * already mentioned in 1.0.69, but repeat here, just in case: '''h[2]''' sematics changed, '''now allows the use of stepper outputs as ignition outputs''' (for instance to drive an stock/oem external amplifier/ignition module). ** '''YOU WILL LOSE IGNITION DURING FIRMWARE UPGRADE, FROM ALL CHANNELS EXCEPT ignch00 UNLESS YOU CAREFULLY READ, UNDERSTAND AND APPLY THIS SIMPLE CHANGE TO h[2]: i259 IGNITION outputs ignch0 .. 7 are 00,10,20,30,40,50,60,70 respectively''' (that is ign259 channel moved to the upper nibble, bit 6:4, while bit7 and bit3:0 must be zero). Eg. if you had h[2]=00 03 02 01 .. .. .. .. than use h[2]=00 30 20 10 .. .. .. .. * tooth_wheel_twidth1=18 # normal tooth width in quarterdegrees. decimal 24 quarterdegree that is 6 degrees (for 60-2 wheel) * tooth_wheel_twidth2=00 # upper byte of normal tooth width ** for missing tooth wheels this variable is actually not used at all before 1.1.27. It was labelled "missing tooth width" in megatune. For best compatibility, set the upper byte of normal tooth width (for either missing tooth or coiltype trigger). * 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) '''[http://www.vems.hu/files/Firmware/release/v3_firmware_1.0.69_12x12.zip 1.0.69] is the recommended 1.0.x firmware''' (MegaTune release available). * '''h[2]''' sematics changed, '''now allows the use of stepper outputs as ignition outputs''' (for instance to drive an stock/oem external amplifier/ignition module). ** '''YOU WILL LOSE IGNITION DURING FIRMWARE UPGRADE, FROM ALL CHANNELS EXCEPT ignch00 UNLESS YOU CAREFULLY READ, UNDERSTAND AND APPLY THIS SIMPLE CHANGE TO h[2]: i259 IGNITION outputs ignch0 .. 7 are 00,10,20,30,40,50,60,70 respectively''' (that is ign259 channel moved to the upper nibble, bit 6:4, while bit7 and bit3:0 must be zero). Eg. if you had h[2]=00 03 02 01 .. .. .. .. than use h[2]=00 30 20 10 .. .. .. .. ** s259 (stepper A..D) outputs can be used for ignition with bit 3:0 > 0 eg. 0x38,0x48,0x58,0x68) * staging code calculations reworked; at stage point the pw is recalculated based on the size of both sets, duty (/pw) of both sets is matched. With properly set config.inj_stage2_rate variable this results in unnoticable crossover from single to both sets. ** config.inj_stage2_rate unit is 1/32 (0.03125), where inj_stage2_rate has the size rate agains the first set; both sets same size would yield config.inj_stage2_rate = 0x20 = 1.00 ratio. second set 3.2 times as big as the first set would be config.inj_stage2_rate = 0x66 * '''Note: Dual Output ignition not supported in this release''' '''Since [http://www.vems.hu/files/Firmware/release/v3_firmware_1.0.53.zip 1.0.53]''' - old * 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''' - old * 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.