## ## #### ## #### ## ##
_ _ | | | | | |_| | | _ | |_| |_|
______ | ___ \ | |_/ / | / | |\ \ \_| \_|
#### ## ## ###### ## #####
______ ( ___ \ | ( ) ) | (__/ / | __ ( | ( \ \ | )___) ) |/ \___/
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''' '''VERY IMPORTANT''': for any firmware, the '''VemsTune MUST be newer than the firmware''' (see File / Firmware info). * Only use older VemsTune (at your own risk) if absolutely necessary and you really know what you are doing. * "Help/Manual update" only updates ini files, which is not enough in all cases. * Old vemstune (sometimes even with updated ini files) might not warn about important misadjustments, or might not show some settings at all! (No surprise it does not show values added in the future) ** Sticking with and old VemsTune (that worked perfectly for some similarly old firmware) after upgrading to a new firmware is a very bad idea. Actually it is '''best to install VT first, and do the upgrade with the new VT !''' * '''new VemsTune applies some useful config changes''' when old saved config (eg. 1.1.85) is uploaded to newer firmware (eg. 1.1.96). This saves a lot of time and headache ---- This page is normally updated by development team only. Unless it's something obvious or minor (eg. spelling), do not edit this page without reading this: * For install-related problems (like needing to upload firmware after bootloader upgrade) use your own MembersPage. * For generic (hopefully reproducible) issues, see IssueReports. * Feature requests moved to GenBoard/UnderDevelopment/FirmWare '''IMPORTANT: when uploading new firmware''' to a controller (even with a motronic55 connector!), to prevent filling cylinders with fuel or possible igncoil or igndriver damage: * '''remove ignition fuses''' (especially important if uploaded firmware is 1.1.85 or older) * '''remove injector connectors and remove fuelpump relay''' ** or otherwise make sure the fuelpump is off, eg. hidden anti-theft switch ** (especially important if uploaded firmware is 1.1.85 or older) ** Upload and verify Firmware ** Upload and verify config, and measure voltage in the injector connectors before powering the fuelpump ** Explanation: when table positions change inside EEPROM (as between 1.0.73 and 1.0.78), the h[0] and h[2] might get corrupted (might fill the cylinders with fuel). * to avoid filling cylinders with fuel (or other problem), '''after firmware upload, always upload config and tables''', reboot, verify, measure, than power ign and inj only if all is well. ** always upload config after firmware upgrade - even an unrelated old config from a very different setup is better than nothing. Do not even try to set everything manually without a config upload. It will take many hours or days, and it will not work ! You have been warned. It is of course recommended to go through all dialogs, but only after uploading a saved config. * '''but first of all: 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. '''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...) ** the plans are necessary so the team can cooperate with the applicant to sort the necessary files/functions for which access is needed for the given task. The development team attempts to cooperate. Access to the chosen functions is granted after the development team decides that cooperation is likely to work out. * 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. '''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), extrapulse triggers (some honda and homemade triggers) and all VVTI (camshaft-angle-control) and table-switching apps will likely prefer 1.1.x * 1.1.x always supported 60-2 trigger and supports dual config since 1.1.3x (read below). * very few will use 1.0.x now ** 1.0.x is unlikely to ever support TableSwitch '''IMPORTANT: use new VT, or at the very minimum, update VT ini file''' before upgrade (especially if upgrading to a firmware newer than VT) and check validate after upgrade. * '''Without VT ini update (eg VT older than firmware) don't expect that it works''' (although in many cases it does work). * minor manual interventions might be needed (that will be automated in some future VT ini). ** Eg after upgrading a simple-coil trigger, if the extrapulse or ls4 config bit (these bits are "don't care" in earlier firmwares) is enabled it will give no spark. '''When upgrading to non-released firmware''' (eg. 1.2.15), the following steps should be applied: * start with a tuned engine running well on '''earlier firmware''', either latest released (eg. 1.2.11) or newer (eg. 1.2.14) * upload the '''new firmware''' (eg. 1.2.15) * optional: upload the new version ( from experimental/ or X/ directory if necessary) * enable the '''new functionality''' in config Do some testing (at least a spin around the block) with logging in each step. Report should contain the sequence (eg. GOOD, GOOD, GOOD, WEIRD IAC oscillations; with '''vemslogs''' for all steps, at very minimum for problem cases). ---- '''[http://svn.x-dsl.hu/f/ 1.2.35]''' - soon, for testing and capturing vemslogs with expert supervision * '''BroadcastDatastreamAim via 2nd UART''' (assuming 1-wire /I-button not used in same setup) ** useful for several AIM compatible receivers (TX => RX of multiple VEMS EAW52 rounds, dash, dataloggers simultaneously) on 2nd UART ** while android is connected to main RS232 port (in triggerframe mode, which has some advantages; but TF is request/response protocol so need software relay if data to be sent to multiple receivers, as multiple RS232 "TX" wires cannot simply be connected - except with RS232/RS485 adapter but that half-duplex mode is special: not enabled in standard firmware and VT and android software...) * note: using newer compiler 4.8.1 (which we must always handle with care: seems good on bench and engine, but more bench and engine tests are in progress; Currently only experts use these new features in very special apps) ---- '''[http://svn.x-dsl.hu/f/ 1.2.34]''' - experimental, only for testing and capturing vemslogs with expert supervision * reverted to the Apr 18th compile which was great success with BMW S65 CAN bus * '''BMW S65 v3 controlled quad Vanos and v3/CAN-bus controlled IAC and ETC (DBW electronic throttle)''' ** uses SPI-bus CAN addon module ** (unlike the dummy throttle) bridgeoutput driver not needed (controlled via CAN-twisted-pair, terminated bus). Note: unlike S85, S65 has 240ohm in all actuators (3x), ecu requires 240 ohm termination to get to the 60ohm total ** BMW s65 is aready in racing competition in the UK, owner reported car running much better than on the stock management. Final 430hp (e85) with factory NA engine (also on same dyno measured better than stock, which is rare for NA engines: BMW tunes them quite well) : at least it confirms good behaviour (on car) of the 1.2.34 firmware with 4 cam control + CAN. Needless to say, this setup is for experienced installers. * improved sync for WBO2 sampling => EGO control when 2 WBO2 channels are configured and used for control. ---- '''[http://svn.x-dsl.hu/f/ 1.2.33]''' - internal version * analog input multiplexer (with VT that supports it - scheduled release 2016-03) ---- '''[http://svn.x-dsl.hu/f/ 1.2.32]''' - experimental, only for testing * adjustable [http://vems.hu/vt/help/v3/v3_electronic_throttle_control.html ETC] VBATT compensation code * anytrim extensions; more input sources, modes and channels (5 instead of 3) available, more info [http://vems.hu/vt/help/v3/v3_anytrim_control.html anytrim help] * (experimental) Ign+Lambda tables, possible to tune using Y axis is calculated load, see [http://vems.hu/vt/help/v3/v3_alphan_settings.html alpha-n help]. ** smooths out the transitions when using ITB's VE(Alpha-N) and Turbo, normal users use KPA (or TPS) * Honda F20C later type / K20A, sometimes sees 1 sometimes 2 crank pulses between two following cam pulses (supported again) * table Kpa unit = 4 (>510 values in kPa based config and table axis values) fully supported '''be ware this also needs [http://vems.hu/download/v3gui/dev/VemsTune-Install-2015-03-16.exe VT Dev >= 2015-03-16] version''' * boostcontrol ** speed based closed loop control available (previously only refdc based) ** boost sensor calibration (when using external boost sensor) no longer shared with baro calibration * * AC idle_up control (refdc/steps add) with (optional) FAN link and (configurable time) delayed compressor relay activation [http://vems.hu/vt/help/v3/v3_idle_ac.html more info] ---- '''[http://www.vems.hu/download/v3/firmware/ 1.2.31]''' - only for testing (no known issue, should be at least as suitable as any earlier version) * '''Electronic Throttle "integral scaling curve"''' ** See [http://vems.hu/vt/help/v3/v3_electronic_throttle_control.html integral scaling curve] ** ETC PID I (integral term)'s max contribution to actuator PWM duty% can be nonlinear with abs_error (abs_error=abs(TPS-target)). Allows even better follow of very sudden target-change, while still reaching target precisely. Dummy configuration: constant 100% (and 60..100% for integral max positive/negative effect, the other 2 new variables) would be compatible with 1.2.30 and earlier semantics. * supporting a very special (uncommon) setup: speed density for fuel and TPS for other tables ** normally if MAP is used for fuel, then MAP is also used for every other tables. Normally TPS is used just for fuel (with MAP compensation or without) or TPS for everything. All these have been supported for a long time and worked well. ** TPS for everything except fuel is very uncommon and required minor changes: now used on a Porsche 911 (for some reason, experimentally) with this 1.2.31. ---- '''[http://www.vems.hu/download/v3/firmware/ 1.2.30]''' released (no known problems) * MembersPage/JorgenKarlsson/MiataNb implemented (Miata trigger, with camsync) ** Triggerlog was not provided. We made test wav and tested with that (tested OK). ** in VemsTune update ini-s from web; configlets/trigger/Mazda_Miata_NB_4_3_Camsync.txt . ** Note for the curious: configured similar to subaru 6+7 (with camsync of course), but no advanced missingtooth filter (config.primary_trigger bit3=0 ) : * '''LSU 4.9 with standard v3 hardware officially supported''' See [http://vems.hu/download/sensors/LSU4.9/ printable pdf] ** Power up ECU and measure nernst voltage (with nothing connected. Config does not matter at this point). If less than 4V (above GND), then '''install a 27k resistor between nernst and +5V''' for correct operation (pullup resistor for nernst current according to Bosch requirement: nernst reference current replaces the LSU4.2 reference oxygen gas connection-tube, which was sensitive to clogging. LSU4.9 sensor has faster response, and longer life expected under similar conditions). ** If the 27k nernstpullup resistor is installed (inside the box or outside), nernst measures >4V (typically appr 4.9V) when open circuit. With a 1k pulldown test resistor towards GND) measures typically appr 175-180 mV => don't install another 27k externally if already installed internally. ** '''LSU4.9 must be selected in config''' (independently possible for 1st and 2nd WBO2 channel). Other than that, same PID values work (eg Ri target is 165). ---- '''[http://www.vems.hu/download/v3/firmware/ 1.2.29]''' testing * Subaru 6+7 (also Suzuki and Fiat Stilo) allow operation without camsync * minor PID change: sum(error * I_term) instead of sum(error) * I_term ** normally same result, except when I_term is changed suddenly + significantly during tuning (makes tuning a tiny bit easier) ** if upgrading an engine with ETC (eg. from 1.2.21 fw), upgrade to 1.2.29 (2014-11-24) or newer. ---- '''[http://www.vems.hu/download/v3/firmware/ 1.2.28]''' testing only * special support was needed for some 60-2 BMW V8 with weird position of the sectrig missing tooth (BMW S62 only ? Thanks to Rija for triggerlog) ** compiled with -D MIN_MAX_PRIM_PER_SEC_CNT ** TODO: point to an explanation of a related special max_prim_per_sec_count=.. secignore=.. example with triggerlog image ---- '''[http://www.vems.hu/download/v3/firmware/ 1.2.27]''' testing only * faster syncup for most trigger types * including honda extrapulse trigger (with or without camsync) ** also always correct syncup for Honda extrapulse trigger under all known conditions ** that's great but where is the file? neither http://www.vems.hu/download/v3/firmware/ or http://svn.x-dsl.hu/f/ has it *** Under the experimental directory. Direct link: http://www.vems.hu/download/v3/firmware/experimental/v3_firmware_1.2.27.zip ---- '''[http://www.vems.hu/download/v3/firmware/ 1.2.26]''' testing only * faster syncup for coiltype + camsync ** also for InputTrigger/LanciaCosworth (which was actually very hard to start with recent fw). ---- '''[http://www.vems.hu/download/v3/firmware/ 1.2.25]''' testing only * For testing (or if living on the edge) use 1.2.25 (not 1.2.24). * no config change (but check earlier important things, eg. 1.2.23 CLT_IGN_ADJUST) ---- '''[http://www.vems.hu/download/v3/firmware/ 1.2.24]''' internal testing only (currently under investigation, not recommended at this time) * '''added 5 cyl non-standard 30-2 and 30-1 crankwheel support''' ** unlike 4/6/8 even cyl engines, '''5 cyl''' needs special "avoid tooth" for missing-tooth setup, so please, if possible: with 5 cyl, stick to 15-1 (homemade wheels) or the factory 60-2 ** instead of inventing new missing-tooth trigger setups (the 30-2 and 30-1 was now tested, and also confirmed working well in the field). ** It's not relevant to coil type triggers, but why not mention the 5 cyl options while we're at it: c270 (factory 135 tooth on crank); or the reasonable c010 trigger is also option (5 pulses on crank); c020 (10 pulses on crank) would work (with campulse not exactly at crankpulse) but not reasonable. * internal: TPS overflow avoid (which was not impossible earlier with certain tps_low/tps_high values if TPS > tps_high happened. Was not possible with most tps_low/tps_high values, or if calibrated to max TPS reading less than 99.8%) * 2014-04-02: '''improved SD card support for sdv2 cards''' (very common nowadays), and SDHC also ** still only the cards shipped with v3 SD-card socket are supported, any other cards are "YMMV" (your milage may vary), but with the new code the set of cards that are likely to work well grows greatly (and hopefully not many types of cards produce insidious results while apparently seem to work). ** almost all SD-cards we tested worked; notable exception: a Chinese clone of "Elite Pro" 2GB card that, when used from SPI writes partial blocks (yes, unbelieavable), and shows other anomalies (files don't show up in VT, so not confusing). * For '''1.2.23 and older fw, disable SD card logging if SD card is not inserted''' (and verified operational), or if there is any chance SD card will be removed. (disable SD-card in config when removing card, or insert new working card) ** verify operation with SD-card overview ---- '''[http://www.vems.hu/download/v3/firmware/ 1.2.23]''' recommended for testing * '''CLT_IGN_ADJUST (coolant/load based ignadv adjust table)''' ** useful to decrease spark advance for high CLT, high load (high MAP), eg. some engines (many Subarus) need lower ignadv when very warm to prevent knock ** also possible to increase spark advance slightly for warmup ** take a look at the coolant/load based ignadv adjust table, make sure it's not random (should be set to some reasonable value during upgrade, but do verify it). Set it to all-0 if no better idea. '''Don't install 1.2.23 or newer firmware without making sure reasonable values are set in this table''' * as always, VemsTune '''must''' be newer than firmware, use the most recent, and '''don't forget to run iniupdate''' ---- '''[http://www.vems.hu/download/v3/firmware/ 1.2.22]''' - for testing * same as 1.2.23, but compiled without CLT_IGN_ADJUST (no coolant/load based ignadv adjust table) ** preferrably use 1.2.23, and 1.2.22 only for comparison (1.2.22 has no advantage except that ini-files are similar to 1.2.20-1.2.21) ---- '''[http://www.vems.hu/download/v3/firmware/ 1.2.20]''' - obsoleted by 1.2.22 and 1.2.23 * acceleration enrichment within 25 msec (was 100 msec) ** with 1.2.20, one might need to set 1/4 (quarter) of previous accel enrichment amount ** retune accel enrichment if possible: some adjustment of the bins could help, especially for lower (dV / dt) values * several other speed improvements (eg 60-2 V8 engine >10000 RPM, with double high-frequency wheelspeed signal, injangle, knock, camshaft-angle-control, ETC, VT-comm all active at the same time). * narrowband lambda sensor: selectable input channels (2 inputs, similarly selectably individually for each cyl, like with dual WBO2) ** (NBO2 might have not worked in some previous fw versions) normally not used for real installs anyway (only used for factory harness plug-n-play before swapping to LSU4 and bigger injectors) * requires uhex bootloader (all boards and ECU purchased since 2011-03 has uhex bootloader) Verify in VemsTune File / "Firmware info": Marked by the 'u' as in "v3.3_u009583" ** older devices upgradable after locking certain internal "fuse" bit with an [https://shop.vems.hu/catalog/cable-p-165.html AVR-ISP] device (or a cheap 5-wire DSUB25 parallel printer port stk200 or similar ISP cable with avrdude). * EVO trigger (with camsync; would be c004 without camsync): supported with wider range for threshold angle (slightly lower than 90 deg allowed: if starts hard because of extreme angular acceleration at startup, try lower than 90) * HEMI / Elise (Rover-K) triggers supported: without camsync, or with camsync (new). * Injector staging: scales actual pulsewitdth, not pulsewidth + deadtime (verify tuning after upgrade, especially if staging was enabled) * known issue: with some configuration (only when stepper iac configured) ADC reading might stop. Fixed in 1.2.22 Any install configured with stepper iac should not use 1.2.20, upgrade (see 1.2.23) ---- '''[http://svn.x-dsl.hu/f/ 1.2.19]''' - for testing only * ETC related (more choices - to get right): ** selectable TPS/PPS1 threshold for IAC activation ** ETC selectable PWM frequency. * planned (under construction): faster and more precise TPS/accel enrichment ---- '''[http://svn.x-dsl.hu/f/ 1.2.18]''' - for testing only * support "secignore" = 1..30 again ** 1.2.16 and 1.2.17 was restricted to secignore = 255 ("ignore sectrig pulses above...") after cranking / initial syncup was made faster (for coiltype or missingtooth + sectrig triggers) ** secignore is important for some BMW with multitooth type (eg. 6+1 or 8-1) sectrig (most often exhaust cam), like the S54 and similar, where practically secignore = 10..16 (decimal) work ** reminder: if the interesting sectrig pulse in triggerlog shows up at tooth10 (every 2nd crankrot), than use +3 (secignore=0D, that is 13 decimal) * '''triggerlog optical improvements''': distinguish different ingout entries ** and visualize primtrig relative gaps. Eg 2 (or 3, for N-2) times taller pulse shown at missing tooth), and TDC also seen better (due to compression slowing the piston) ** makes it easier to set ignition outputs (strobe is still needed for proper "TDC after the trigger" setting but at least easier to get close this way) ---- '''[http://svn.x-dsl.hu/f/ 1.2.17]''' - for testing only * higher (1 crankdeg) resolution for knock window start position ** better knock-sampling support for high individual cylinder retard (>10 deg) like used with odd-fire (although odd-fire knock is still untested on real engine). * with ETC configured, inj-H (and/or INJ-G) acts as PWM-command (for external power-module) if INJ-H (and/or INJ-G) is not enabled in ANY injgroup ** this-way ETC power-module can be connected to older controller without disassembly and internal mods (note: for any InTake/DriveByWireThrottle application, it is still obligatory to setup safety relay and 2nd sensors and configure the safety functions with proper acceptance thresholds, and requires high quality installation in every respect) * the "Pump on After powerup" function supports non-p259 fuelpump (also the time restarts from correct button touchon; otherwise measured from powerup of course). ---- '''[http://www.vems.hu/download/v3/firmware/ 1.2.16]''' * "unpower IAC when not moving" configurable (iac_conf bit0, same bit as for stepper) when IAC PWM dual-solenoid is configured * of course new VT is needed (even from [http://vems.hu/download/v3gui/dev/ Dev] * virtually same functionality as 1.2.15... the reason for this version: ** experimental 1.2.15 (from 2013-08-20 or so) had stumbles (due to misfire as it turned out, that took some time to reproduce). Now fixed, and named 1.2.16 to prevent any uncertainty. ---- '''[http://svn.x-dsl.hu/f/ 1.2.15]''' for benchtesting (obsolete) * compiled with KNOCK_ALTERNATIVE (with tuner-defined knock thresholds in a 8x4 table, 8 RPM and 4 kPa bins; not 8x8 as earlier, and not the more complicated 2-knock-sample per event that was default) ** made lotsof tests (with new VT and Preferences / update of course) with good results. Notable exception (yet untested): odd-fire maserati (or any other weird setup with >= 10 degrees cylinder-specific spark delay for any cylinder) should use earlier firmware (will be supported again of course). * somewhat more tolerance if wheelspeed signal amplitude diminishes at high frequency * made als_retard configurable absolute/relative * made coiltype (eg. c004 "4+1" or c024 "24+1") trigger with sectrig sync reasonably fast (was annoyingly slow since 1.2.7, if attempted after the initial fuelpump "priming") * '''Release of 1.2.15 is delayed''' because finding misfire ('''missing a few consecutive ignition pulses''') symptom early September, reproducible with certain config at least with 2013-08-28 and 2013-08-29 builds ** not reproducible (not seen at all) on earlier builds like 2013-08-12 or so ---- '''[http://svn.x-dsl.hu/f/ 1.2.14]''' for benchtesting * '''Electronic DC-motor based throttle''' with 2 pedal-sensors and 2 throttle-sensors ** 2 dimensional RPM, PPS1 => throttle-target curve ** curve for verification of PPS2 (2nd pedal position sensor) ** curve for verification of TPS2 (2nd throttle position sensor) ** different PID values for above target and under target: the throttle response could be tuned to yield perfect response with virtually no overshoot or undershoot (several throttle-bodies tested) ** ~500 Hz PWM, via precise HW-pwming (OC0). Injector-PWM-ing cannot be enabled simultaneously with ETC. (either high-Z inj or low-Z with series power-resistor is possible of course). ** safety relay shutdown (and configurable overrun fuelcut) if throttle way above target, or 2nd sensor verification (PPS2 or TPS2) failed - with configurable thresholds. * iac2etctarget: how much IAC.position can effect electronic throttle target 0 .. 24.9% ** effectively work can be split between IAC and Electronic Throttle in ANY ratio * TPS overrun fuelcut delay configurable (0 .. 3.1 sec) ** time measured after TPS released (even if RPM > overrun_fuelcut, fuelcut won't kick in for the configured delay). ---- '''[http://svn.x-dsl.hu/f/ 1.2.13]''' for benchtesting * select EGO1 and EGO2 for each injector (EGO correction based on WBO2 channel1 or channel2) * For odd-fire maserati, injection is 30 crankdeg delayed every 2nd injevent ---- '''[http://svn.x-dsl.hu/f/ 1.2.12]''' for testing * for '''missing tooth trigger''' (60-2, 36-1, etc...) with camsync, '''secignore=246''' (which is 256-10) means that sectrig pulse coming at tooth 0-10 is ignored ** this is '''useful if sectrig normally comes right before tooth0''' (which is the pulse after the missing tooth), as in some BMW (sectrig pulse at the middle of the missing gap 6..12 crankdeg before tooth0 pulse; with HALL the chosen edge can help but not with VR sensor), but sometimes sectrig is delayed to slightly after tooth0 (either because of VVTI action, or cambelt sloppyness, or agressive clutch action). With this config it tolerates this and does not resync (no stumble) ** another example: secignore=240 (which is 256-16) means that sectrig pulse coming at tooth 0-16 is ignored. Example values: ** secignore=246..250 for wheel with 22 or more teeth, ** secignore=250..253 for wheel with 10..11 teeth ** secignore=253 for wheel with 7 teeth ** secignore=254 might work for wheel with 5 teeth (or even less) but it's not recommended: sectrig pulse should NOT come near the primtrig missing tooth for any low toothcount wheel (or any homemade wheel, since those should be HALL anyway, and it's easy to satisfy this condition by choosing the right primtrig edge and sectrig edge) ** secignore=255 means sectrig pulse is not ignored, no matter at what position it comes. * '''Added support for SUBARU H6 pattern'''; 36-2-2-2 but a different pattern for '''engine H6''': 19, missing, 10, missing,missing - see See InputTrigger/SubaruEngineHsix ** Normally used with camsync (and camshaft-angle-control ~VVTI/AVCS). ** "Ignore sectrig pulses above" = 94 (secignore=5E, or 5F) for H6 engine ** For Subaru H4 engine, set "Ignore sectrig pulses above" = 62 (secignore=3E, previously didn't matter), see InputTrigger/SubaruThirtySixMinusTwoMinusTwoMinusTwo * Convenient calibration of WBO2 2nd sensor (without plugging sensor2 into socket of sensor1) ---- '''[http://www.vems.hu/download/v3/firmware/ 1.2.11] - Released''' * LCD page9 can display 4 EGT and 2 lambda ** it seems popular now (especially in USA) to log multiple channels that v3 can do easily (some v3 ordered with 8 EGT-inputs and 2 lambda) * During launch, launch_maxkpa takes over boost_target (if lower) ** nice on tires * 2nd ibutton switches to eeprom page-B ** example usage: page-A can be "wallet-mode" and page-B can be high power (or "fallback to safe-defaults" and "cutting-edge under-tuning", whatever one likes) 2nd I-Button is easy to configure in new VT (remember the base rule: VT newer than firmware). Options in short (internally coded in a backward compatible way in config prohibit_config bit 7:6): * 00 : Ibutton disabled * 10 : Ibutton enabled, antitheft, no keepalive * 11 : Ibutton enabled, antitheft, with keepalive * 01 : Ibutton enabled, but only for switching to page-B with ibutton_code2 (prohibit h/l : firmware version dependent): I-button touchon not required to start the engine. ---- '''[http://www.vems.hu/download/v3/firmware/ 1.2.10 ] - offered to wide audience for testing, extremely promising''' * Tranny drumsensor support: when enabled, gear detection is calculated from shiftcut analog input (and 6 specified voltages, 1 for each gear) ** in this mode, shiftcut activates when outside the ''voltage[gear] - shiftcut_potlow .. voltage[gear] + shiftcut_pothi'' window ** configured shiftcut_potlow and shiftcut_pothi should be small values (around 0.15 .. 0.2V) not 2V and 5V as for traditional shiftcut activation ** of course, shiftcut/launch sharedinput makes no sense together with drumsensor=enabled * bugfix: fixed the undefined behavior, after we found and reproduced by an otherwise invalid setup (floating analog input): when LCD is enabled in config (regardless of wether LCD is connected or not) AND lcd_pagestep enabled (or inverted0..inverted7 input selected) * bugfix: for wasted-spark ignition when ignout0 was among the channels, eg 0,2,0,2 (or 2,3,0,2,3,0) limited the dwell below the expected 360 crankdeg (minus a few hundred microsecond). ** 0,2 (or 2,3,0) worked but the multiignout config is normally preferred (for better indication in individual-power and knock). Either ignout setup works fine now. ---- '''[http://www.vems.hu/download/v3/firmware/ 1.2.9]''' available for testing * PID boost with "target based reference PWM duty" option is easier to tune for very quick reaction and small overshoot (if the hardware actuator is good) ** reference DC can be configured in function of RPM, boosttarget ** PID can be configured to switch to PD when boost is way too low, or to PI when boost is too high ** actually, configurable thresholds for operation ranges: ** boost off ** max-DC (to help spoolup) ** ref-DC ** ref-DC + PD ** ref-DC + PID ** ref-DC + PI * communication improvement: send overview of all pages command was improved internally. Better behavior when connecting during driving (eg. android) ---- '''[http://cell.dyndns.ws/f/ 1.2.8]''' for testing * wheelspeed dependent PIDboost uses wheelspeed2 when config.als_max_cut bit7=1 (wheelspeed1 when bit7=0) * experimental tachout change ---- '''[http://cell.dyndns.ws/f/ 1.2.6]''' for testing. - ALS/launch combined * wbo2 "quick-on-line" improvement (might be more generic than 1.2.4 - 1.2.5, eg. graceful with more sensors/cases, one more reason that 1.2.4 - 1.2.5 is unlikely to ever get out of experimental status). More testing follows with 1.2.6 (and testing only). * when '''both ALS and launch functions are activated''', if ALS_OVER_LAUNCH ( config11 bit3 ) is set, depending on TPS: ** if TPS < TPSx ALS is authoritive ** if TPS > TPSx launch is authoritive ** where TPSx is als_retard_maxtps or als_cut_maxtps (whichever is higher) ** in other words: in the configured ALS TPS-window => ALS acts, at higher TPS launch will act. ** note that because of this, depending on the setup, at some points higher TPS can result in lower RPM ! Provide feedback (Fero, especially you !) * Mazerati was reimplemented in 1.2.6 (under testing) for very quick sync at startup and ** using 10BTDC teeth during cranking (like a kickstart motorbike). ** If RPM > cranking_thres than old behaviour applies, eg. time from short-gap (and per-cyl sparkdelay). ** '''config also changed, use latest ''': ** start from a 6 cyl config ** apply '''configlet from vemstune''' (bottom of primary trigger dialog), which overwrites config13 variable so after that enable alpha-N, matretard is necessary. Plus, just in case, check these: ** ODDFIRE set ! ** next trigger tooth=2 ** reftooth: 0 10 8 6 4 2 .. .. ---- '''[http://cell.dyndns.ws/f/ 1.2.5] was experimental, now obsolete, WILL NOT BE RELEASED''' - * '''new "trigonLONGgap" option''' implemented in InputTrigger/ShortGapTrigger (that is coiltype + fiatstilo/subaru + advanced missingtooth filter => this configuration traditionally triggs on short gap) set trigger_multitooth_Nminus1 (bit4 = 1) effectively '''primary_trigger=BB instead of AB''' ** trigonLONGgap means: '''throw away short gaps, and trig on longer gaps''' (somewhat like the missing-tooth detection, but unlike a proper N-1 or N-2 wheel or the best MembersPage/YasecElise , don't assume that there is a sufficient number of sufficiently placed short-pulses) ** could be useful for MembersPage/FPhil/OddFireWastedSparkEvilStartUp apparently timing measured from the pulse after the 90 degree gap is better (than timing measured from the pulse after the 30 degree gap) ** would also be useful for Nissan 350Z V6 engine where 10,10,10,10,10,10,10,10,10,10,20 crankdeg pattern repeats (yes, that is 3 missing teeth 120 crankdeg apart so not suitable without camsync even for wasted spark or igndualout limphome) *** hard to tell out why Nissan didn't use a proper 36-1 or MembersPage/YasecElise or InputTrigger/SubaruThirtySixMinusTwoMinusTwoMinusTwo trigger, but at least an improvement from the terribly unprecise (even at normal running and high-RPM) Nissan-practice of timing from cambelt-driven camshaft where cam oscillates with 110 msec period. * fuel consumption on LCD page11 ** l/h ** and for the wheelspeed fw also l/100km (which is == cl/km that is centiliter/km, or centiliter/mile if wheelspeed is calibrated to miles per hour). '''[http://cell.dyndns.ws/f/ 1.2.4] - was experimental, now obsolete, WILL NOT BE RELEASED'''. SubaruEj (or maserati) should use newest firmware, other installs should use a released firmware. '''Workaround for the weird Subaru''' --design-- evolution where the measurement of the '''4th trigger''' is required because the camsync does not move with cam actuation * [http://vems.hu/vt/help/v3/v3_camshaft_angle_control.html page bottom shows: third trigger = SDA = Atmega128/pin26] ** the 4th trigger is next to it (SCL = Atmega128/pin25) same as wheelspeed2. * at configured "sectrig measure tooth" firmware measures wheelspeed2 pulse position instead of sectrig when speed2_sensor=01 ** so configure in VemsTune '''Base Setup/Speed Sensor/2nd wheelspeed sensor calibration = 1''' ** also configure in VemsTune'''Base Setup/Speed Sensor/2nd wheelspeed divider = 1 (for future compatibility)''' ** just in case it's not obvious: '''DO NOT configure 2nd wheelspeed sensor calibration = 1 if not having 4th trigger sensor'''. Value=0 to disable, or actual calibration if using 2nd wheelspeed input as wheelspeed input (frequency measurement) ** when ordering assembled controller for such Subaru, write in the order comment: "suitable for subaru shortpulse triggertype wheelspeed2 input and VR=>HALL divby1". The default aggressive hardware filter or the VR=>HALL divby4, which is perfect for wheelspeed input, would prevent this operation so this is very important. ** otherwise everything is same as for [http://vems.hu/vt/help/v3/v3_camshaft_angle_control.html sectrig based intake cam control] proven in BMWs, Ford, Honda, Suzuki, etc... (target table, measure tooth, output configuration). The only difference is that with this "2nd wheelspeed sensor calibration = 1" configuration the position of the 4th trigger pulse (connected to 2nd wheelspeed input) is measured instead of the sectrig pulse * ButtonImmobilizer '''keep-alive=enabled mode supported again''' (was not supported about 1.2.0 -1.2.3, accidentally) ** after enabling, test that after >30 second powerdown ECU is in "safe mode" after boot (and only allows running after touching on I-Button with configured ID) * when 1-wire IButton antitheft is enabled '''warning_light flashes''' after powerup before 1-wire Ibutton touched on (when injection and ignition is prohibited) to remind the driver (antitheft mode) ** Note: warning light '''must be p259 output''' for this to work, because other outputs are disabled in this state * wideband change: comes up faster if ECU powered down only for a second and sensor is still very warm. Not all sensors behave same under these conditions and this might not always work as expected (remember, if wbo2 does not measure sensor is likely to get clogged so revert ASAP if experiencing that), so we're collecting experience and will apply improvements ** also improved under extremely rich conditions (like 0.65) ---- '''[http://cell.dyndns.ws/f/ 1.2.3]''' - highly experimental, Viper only (for anything else use 1.2.2 or older, really) * Subaru type (or short-gap, similar to maserati, can start with the "maserati" configlet at the bottom of "primary trigger" dialog) * advanced filtering=enabled ** with disabled it won't work * nr of wheel on tooth=10 * tooth width=72 degree * set ign channel count to 8 to be able to set variables (finally change back to 5) * reference tooth=0,9,8,7,6,5,4,3 ** note: the missing 2 entries: 2,1 are wired in for this trigger * ignout=0 1 2 3 4 0 1 2 (just example) ** note: the last 2 (idx 8,9) entries are alias idx3,4 so 3,4 in this case (5 wasted spark channels are used but all 8 configured +2 aliased internally in firmware) * '''only change ign channel count to 5''' after setting all 8 channels of reference tooth and ign outputs. * inspect triggerlog carefully, and preferrably start with benchtest ** benchtest with Viper "Z020" trigger: seems ok ** configlet (bottom of primary trigger dialog) will be available for Viper in new VemsTune to adjust all the above several settings with 1 click ---- '''[http://cell.dyndns.ws/f/ 1.2.2]''' - TESTING - very nice for audi 135 "c270" trigger Beware: triggers other than the 135 tooth auditrigger are not well tested at this point (and 1.2.2 offers little improvement for them anyway), so benchtest before playing on real engine. 60-2 seems good at least. * note1: TDC after the trigger (ign_tdcdelay) might have changed ** to the safe side: without adjustment, 1.2.2 ignites 1 tooth (=2.67 degrees) later than earlier firmwares ** If unsure, leave earlier config, only compensate after strobing ! * note2: '''divby9 is recommended for 135 tooth''' - which means tooth width=24, tooth count=30, next trigger tooth=6 and related reference tooth array * note3: '''only divbyN is supported''' (so even for divby3, which is not recommended from now, and not well tested) divbyN and divider=3 must be excplicitely set * for non-135 tooth, the recommended divbyN range is 5-120 (max 128? but practically 5-65 or upto 71 anyway). DivbyN N=2 needs benchtest before use ** uploading [http://vems.hu/files/MembersPage/MarcellGal/Audi/etc/5cylAudi_c270_divby9.txt divby9 configlet] or [http://vems.hu/files/MembersPage/MarcellGal/Audi/etc/5cylAudi_c270_divby27.txt divby27 configlet] allows changing only the divider related parameters without ruining VE and other tunings. (in new VT, will be on bottom of primary trigger dialog) * '''[http://vems.hu/files/MembersPage/MarcellGal/Audi/etc/v3.3_u003637-2012.06.28-10.44_14800RPM.vemslog vemslog 135 tooth c270 running at 14800 RPM]''' with [http://vems.hu/files/MembersPage/MarcellGal/Audi/etc/v3.3_u003637-A-2012.06.28-10.44.36divby9.vemscfg this divby9 vemscfg] ** This 2 million pulses per minute (14800 RPM with auditrigger) is on table benchtest with a clean generated signal and both wheelspeed calibration=0 (off). ** With real "hazy" signal and wheelspeed calibration non-zero (enabled), the maximum RPM is obviously lower, but the mechanical stresses blow up the engine before the ignition delay deviation due to high-RPM would be >0.5 crankdeg. ---- '''[http://cell.dyndns.ws/f/ 1.2.1]''' - intermediate non-release only for audi 135 tooth "c270 divbyN" (N=9, 27 or possibly 3) * For audi c270 divby3, the trigger mods and motorsport features like camshaft-angle and multiple wheelspeed inputs lowered peak-RPM. In 1.2.1 we made +n*100 RPM possible (still not 11k RPM like we had on bench earlier, but >9100 RPM on bench). Config checklist: ** make sure HALL-dirac is OFF (both triggers) ** sectrig_maxrpm=40 (enable nissan temporarily to set to 6400 RPM, disable nissan) ** reboot ** Note that sectrig camshaft-angle measurement (would be useful for adjustable cams) is off above sectrig_maxrpm (eg. 6400), and triggerlog sectrig might be lower precision even at lower RPM. '''1.2.2 pushes auditrigger RPM-limit further (and should make 1.2.1 obsolete)''' ---- '''1.2.0''' - for testing (test results welcome, of course) * fixed 1.1.99 issue about "comm sometimes bailing out and sending CRC error (after about 30 mins in lab, some installers reported 5 minutes in field) ** engine running was not effected by this, but annoying when tuning, so 1.2.0 is better than * ButtonImmobilizer '''ADC keep-alive=enabled mode NOT supported''' (=> from 1.2.0 to 1.2.3 ADC keep-alive must be disabled for the immobilizer function to work) ** this was by accident, sorry (and thanks for reporting, support immediately added back at 1.2.4). ---- '''1.1.99''' - seems to operate OK, but 1.2.0 recommended because of annoying usable testing (test results welcome, of course) (if you tested experimental secret versions, check firmware info so you don't accidentally leave any 1.1.99 earlier than 2012-05-07 on an ECU) * getting '''more and more positive feedback''', including Fero's Nissan 360 tooth (6cyl, using ignore sectrig above 4000 setting) works perfectly * '''wideband measures up to 50 lambda measurement per second''' (when both channels enabled: 25 per channel) ** EGO also improved when "dynamic speed"=enabled (recommended testing). ** just in case, recommended to verify wbo2 free-air calibration and check nernst voltage is appr. 4.5V (0.45V above pump-) * configurable warmup LSU4 wideband sensor on boot when ego_conf WBO2_WARMUP_ONBOOT bit1=0 ** useful during early stage of install (although it's best to have a blindplug in the exhaust until the engine idles well), or for producer-gas powerplants * config11 bit3=1 disables launch when ALS switch is activated (earlier, and when bit3=0, launch takes precedence). See (improved operation in) 1.2.6 ** renamed in new VT. Note: this bit used to be called the "Throttle-body / port injection" (so you can toggle in old VT) and had no effect on operation at all before firmware 1.1.99. * there was a bit long feature-freeze while important tools were developed and improved to confirm ignition and injection correctness and accuracy in a large number of setups, in wide range of operating conditions ---- '''1.1.98''' - NOT released (only for testing !) and will never be released * '''KNOW BUG: ADC-can-freeze at startup values''' - fixed in 1.1.99 but 1.1.98 will not be release ** on bench, when we play trigger continuously, and do LOTSOF power-cycles, ADC (eg. MAP, TPS, ... values) can freeze once in 30 cases ** on real engine (someone said every 50th startup on a 60-2 4cyl, every 10th on a mitsubishi 4cyl) it can also act same way (than engine idles at MAP=101kPa like trash) * both WBO2 channels are displayed in VemsTune (and captured in vemslog). Question. How do you calibrate second WBO2 chanel/ display free air O2 reading??......... ** when ordering assembled controller, request in order comment that both WBO2 channels are tested (otherwise some pins like heater2 might be used for other functions, like analog input channel) *** Respecting the above, also ensure R103 75k soldered on existing or self built boards. * '''selectable noise-cancellation strategy for wheelspeed1''' input ** after improving noise-filtering to work well (with automatic time-threshold) with a shown noise-pattern (prelling), some users complained that their wheelspeed worked well earlier with the manually adjustable time-threshold but not with the new one. So we made the old / new strategy selectable from config * '''tachometer output improved at high RPM''' ** (unlike the precise ignition and inj outputs, tachout is issued from userspace, but now with higher priority). ** Freq was ok but duty was deviating, some tacho-gauges shown to be sensitive about this, now improved * '''more tolerant''' to race condition between '''auditrigger''' 135 pulse signal and the crankhome-VR pulse. (eg when the sectrig pulse comes after 269, 270 or 271 primtrig pulse). ** auditrigger camhall scope (in 1.1.97) made the firmware to only work for c270 auditrigger, now c129 (like MembersPage/KevinBlack/PorscheTurbo ) and divby43 and divby27 works again * stepper pins set to 12V at poweroff (not to GND) if negative polarity configured for stepper iac * made MembersPage/Fero/MitsubishiEVO sync condition stricter after startup in [http://cell.dyndns.ws/f/v3_firmware_1.1.98_evosync.zip 1.1.98_evosync] ** This means that before first spark it will need a full camsync revolution (1.0 .. 2.0 camrot depending on starting position: 1.5 camrot on average), but more tolerant to noise at startup. ---- '''1.1.97''' - NOT released (only for testing Nissan 360 and more testing for BMW double-vanos) * Around when subaru 36-2-2-2 VVTI (camshaft angle control, AVCS) was implemented, the subaru 36-2-2-2 without camsync config setup was hijacked for some time for mitsubishi-evo (a setup made according to bogus specs we received, later remade with a different approach and config). Now from 1.1.97 gifted back to subaru (while factory subaru-s have camsync, which was not effected, it makes sense to run subarus with wasted spark setup without camsync: possible again). * high-current (powerful) unipolar stepper driven from 4 injector outputs. ** We'll think about how this (rarely used, but useful) feature to make the chance minimal that this annoys those who don't use it. Not compiled in by default (and needs special config: stepper+ iac-dual-solenoid configured) * triggerlog is now useful at higher RPM (eg. with 60-2 at >9k RPM), as the primary teeth are "compressed" (eg. only missing tooth is shown at high RPM, not every tooth) * more tolerant if sectrig is lost (or moved out of the allowed window) at high RPM especially if missing tooth primtrig signal is OK (especially useful with doublevanos / VVTI apps). * '''360 tooth Nissan trigger implemented''' (eg skyline) ** 4 or 6 window pulse goes to primtrig-HALL ** sectrig=HALL, 360 pulse connected to EC36/13 ** hardware-divby4 NOT required (and not recommended), since benctest RPM>12000 RPM (more than 2.1 million pulses / minute) without the divider * cam-hall scope is possible (hall connected to third trigger instead of masking the crankhome VR). Known limitation in 1.1.97 (only effecting auditrigger divbyN and divby3 in 1.1.97, and not an issue from 1.1.98): ** only the traditional c270, divby3, 2*135=270 real tooth per cycle works (90 teeth in config). c129, or divby43 or divby27 does NOT work ---- [http://vems.hu/download/v3/firmware/ 1.1.96] - RELEASED * '''extrapulse triggers''' (with cam position measurement support for camshaft-angle-control) ** like some Honda 30, 30, 30, 10,20, 30, 30, 30, 30, 30, 30, 30, 30 crankwheel ** 120, 120, 40,80, 120, 120, 120 camwheel (typical 6cyl inline truck/powerplant engine) ** other extrapulse trigger examples: 60,120, 180 or 90,90, 180 (the simplest 4-cyl crankwheel). The latter can be configured as 4-1 also. * '''BMW double-vanos''' with 60-2 primary trigger ** 6+extrapulse MUST be connected to sectrig ! ** optional (but recommended): the other cam, 6 evenly placed pulses can be connected to the 3d trigger. The "exhaust cam" table is used for this, regardless of which cam the signal is actually from (is this from the intake cam in the factory app ?). ** Fero(BMW Tököl) needs to swap the intake and exhaust cam signal connections (so the 6+extrapulse goes to the secondary trigger not the 3d trigger). * '''RPM actuator''' ("shiftlight") semantics changed at very low RPM, because the intended hysteresys was non-intuitive for configured 0 or 100 RPM threshold: ** if configured to 0 RPM, then shows running (trigger pulses seen) / not running ** if configured to 100 RPM, then turns on above 200 RPM, turns off below 100 RPM ** if configured > 100 RPM then works as originally (+-100 RPM threshold) * with original InputTrigger/AudiTrigger "Hallgebersignal" is around the crankhome-VR pulse (VT/Tools/play trigger "c270" type: sectrig is every 270 primtrig pulse: every second crankhome-VR masked away by the HALL signal) ** in some installs like the camsync is short and so unfixably offsetted that it cannot mask away one of 2 crankhome-VR pulses ** from 1.1.96, '''if Motorsport/camshaft angle control/third trigger is enabled with auditrigger''', than one sectrig pulse expected every 135 primtrig pulse, and the '''camsync can be connected to the 3d trigger input''' (only available on econoseal pin if requested explicitely, since normally only useful for double-VVTI setups where exhaust cam is also controlled hydraulically like the BMW double-Vanos) ** pleasant side-effect: all 3 triggers show up in the triggerlog ("primtrig", "sectrig", "exhaust cam"). See example: in VemsTune analyze the triggerlog from [http://vems.hu/vemstune/sharingcenter/reports.php?cmd=view&key=Rx3Q7b download zip of this share]. Therefore with this setup it's even easier to diagnose if the crankhome-VR or the cam-HALL signal is faulty. Traditionally possible to diagnose by disconnecting HALL sensor (with cam-HALL inverter, pulling HALL input to GND also needed) ** for now, only tested with divby3 (not with divby27 or other dividers). Keep the 3d trigger disabled unless you really know what you are doing and ready to bench, strobe, etc... Just in case, VemsTune validate will warn if 3d trigger is enabled (usually not intended). ---- '''[http://vems.hu/download/v3/firmware/ 1.1.95] - RELEASED''' * '''improved wheelspeed filtering''' of noisy (prelling) wheelspeed signal (on both wheelspeed inputs) ** Sami provided a suitably noisy log (thanx!) from the mechanical reed-relay of his audi transmission, so we could implement better filtering that handles this case: ** Above 318 (km/h or mph according to calibration) it's considered prelling-noise and filtered. 255-318 is allowed (no overflow to 0), measured speed stays high. 0-255 is displayed normally (good signal was good earlier also). * For 1.1.94 and earlier, wheelspeed dependent launch-mode must be used when wheelspeed is used at all. ** even if all launchRPM values are same (say 4500 RPM) and speed bins are all 255 ** from 1.1.95 the no-wheelspeed dependent mode might work as expected (even if wheelspeed>=1) with just 1-RPM value configured ** it is still recommended to use the wheelspeed dependent launch-mode (which is more flexible anyway) when wheelspeed is used. * SD-card read-retry number bumped up so ** '''some really slow cards that did not work earlier can now be used''' (the standards does not specify max delay) ---- '''[http://vems.hu/download/v3/firmware/ 1.1.94] RELEASED''' * [http://vems.hu/manual/vemstune/help2/htmls/v3/v3_transbrakecreep.html Trans Brake Creep] ** feature was implemented in 1.1.90 but now TRANS_BRAKE_CREEP enabled in default my_make (available to every VEMS user without special request) * logging will restart if SD-card is removed and (usually another) card is inserted. ** drag and rally racers requested this to restart SD-logging within about half minute after SD-card swap (even if engine is not stopped) ** this feature was implemented in 1.1.92 and worked well for SD-card swap, but if the SD-card was removed but another card not inserted (or SD-card logging was enabled with card not installed at all), the reinit attempt disabled interrupts for milliseconds (not microseconds), causing occasional trigger-error. Fixed in 1.1.94 : Now enabling SD-card does not cause trigger-error even if card is not installed (This cannot cause trigger-error in <1.1.92 since it does not try to reinitialize the card again and again, only at startup). * if priming pulse was configured non-0, than actual priming pulse was min 6 msec (range: 6.1 to 31.5 msec) ** new range is 0.1 to 25.5 msec ---- '''1.1.93''' - was never released, now withdrawn, see 1.1.94 notes * [http://www.vems.hu/vt/help/v3/v3_camshaft_angle_control.html exhaust cam control] also supported with 2 solenoid "Vanos" mode (not just with PWM "suzuki"-mode) * in 1.1.92 and 1.1.93 disable SD-card logging if SD-card is not installed or removed (otherwise trigger-err might show up every 32 second). ** If SD-card is enabled, it is recommended to use >=1.1.94 or < 1.1.92 so this cannot effect even if SD-card is unplugged or disconnected ---- '''1.1.92''' - was never released, now withdrawn, see 1.1.94 notes * InputTrigger/SubaruThirtySixMinusTwoMinusTwoMinusTwo supported with '''camshaft control of both left and right camshaft''' ** A (right, intake) connected to secondary trigger input ** and B (left, also intake but connected to "exhaust cam input"). ** please note (if upgrading from a working pre-1.1.92 subaru config) that tooth0 got 30 crankdeg delay to the "4BTDC10" point so: trigger_tooth=02 (instead of 3) and TDC delay=120 deg - verify with strobe ! * suzuki cam position (camshaft angle control) also supported ** both are tested with signals that match scopeshots (and also fluctuated a bit to allow reasonable deviation). Need real-engine tests (experienced installers). * MembersPage/Fero/MitsubishiEVO supported * iac_close_minmap can be set to any reasonable (non-FF) value, will not effect IAC flag * in 1.1.92 and 1.1.93 disable SD-card logging if SD-card is not installed or removed (otherwise trigger-err might show up every 32 second). ** If SD-card is enabled, it is recommended to use >=1.1.94 or < 1.1.92 so this cannot effect even if SD-card is unplugged or disconnected ---- '''1.1.91''' - will not be released * Anytrim controls expanded with speed sensor inputs as trimming source * GPS speed sent out to Round on AIM protocol * in 1.1.91, leave iac_close_minmap at FF (510 kPa default value) - or use 1.1.92 ** otherwise iac flag might be left on in some cases, possibly effecting sparkadv (due to iac retard) ---- '''1.1.90''' - will never be released * Iac can force to specified duty when reached the specified Map (usefull for Boost) * Injector dead time has a simpler strategy * Triggerlog logs the Spark events * Maserati trigger support: MembersPage/OddFireSixCyl * Staging injectors can switch with RPM limits ---- '''1.1.89''' * v3 can now log GPS data to SDcard ** when vemstune notebook is not connected, a GPS can be connected to comm-port (our GPS is 4800 baud, which, unfortunately is different from the standard 19200 baud aim-default baudrate) ** anyway, time information is no longer lacking for logfiles ... this way GPS replaces RTC ** second serial input on V3 also can use for GPS ** for details see: GenBoard/LoggerIntegration/MMC * MembersPage/DamirMuha/MagnetMmarelliCamSensor support ** new sectrig setting: to neglect the offending pulses from 3 (or more) sectrig pulses * the new vemstune (coming out late Febr) syncs superfast to 1.1.89 ** VT recognizes page-data checksums and only downloads changed pages (like rsync). ** But initial config-download is much faster also * Secondary trigger input can use as a stand-alone primary trigger ---- '''[http://vems.hu/download/v3/firmware/ 1.1.88] Withdrawn !''' * withdrawn because compiled with KNOCK_ALTERNATIVE that seems to cause problems (ign advance different than table) under certain circumstances. '''Upgrade to latest released version is highly recommended.''' ** the actual ign-advance is in the log ** if the upgrade is expensive, we'll benchtest any config on request (best to use MembersPage or VemsTune Help to post vemslog or vemscfg) and report if the test shows it is effected, and upgrade the config to latest release, test that too, to make upgrade a simple "connect and upload" type 4 minute operation. * '''Rover K series 36-1-1-1''' type MembersPage/YasecElise trigger supported ** from "primary trigger" dialog upload configlet "4cyl 36-1 no camsync", press validate. Set number of tooth to 32 (not 35). Press burn. You just configured "elise trigger". From tooth_wheel=20 (decimal 32) the firmware will know it's not 36-1 but elise type trigger. However, 2011-01-24 vemstune configcriteria rules are not yet prepared for this special case, and might fire false warning (so reftooth 0 18 0 18 is good). ** or use "rover-k_lotus-elise_e324" configlet ** "e324" type generates this pattern (Tools/Play trigger) * compiled with KNOCK_ALTERNATIVE defined (so the knock amplitude threshold is configurable per loadsite). * the wheelspeed (non-PS2) version also sends fuel consumption over serial to AfreshTiny/AimDisplay if set up properly (eg. wheelspeed must be calibrated) * PID boost overflow bug (injected after 1.1.81) fixed. * 4+1 (coiltype 2 pins on crank + 1 pulse on cam) worked on bench but RPM=0 on engine (even though inputs were perfect in triggerlog), [http://vems.hu/files/Sanci/ vemslog files here] ** we don't know if auditrigger divby1 workaround works (because the starter on the engine failed just when we wanted to try this). Investigating the issue '''[http://vems.hu/download/v3/firmware/ 1.1.87]''' - release candidate * max 1.1.85 recommended for now. '''If you really need 1.1.87 (use nonps2 and), use newest VemsTune''' * '''see SafetyMode''' - just in case: be prepared to set ECU calibrations / prohibit manually (one time operation. Should be automatic in new vemstune, but better be prepared than surprised). * we had a few positive reports with VT NIGHTLY VemsTune-Install-2010-12-22-commModel.exe (including triggerlog), but ... '''1.1.86''' - unreleased, internal version '''[http://www.vems.hu/download/v3/firmware/ 1.1.85]''' - '''released''' * auditrigger '''divby2 changed to divbyANY''' ** toothrel_missing=01 for divby2 ** toothrel_missing=19 for divby26 ** toothrel_missing=1a for divby27 ** with auditrigger 11000 RPM could be reached earlier (in benchtests) using divby27. Not 25500 RPM as with lower toothcounts, but sufficient. ** note: auditrigger divby3 (which is used in hundreds of 135 tooth audi engines) maintains compatibility '''[http://www.vems.hu/download/v3/firmware/ 1.1.84]''' - '''not released. Benchtests first before uploading to the real thing''' * anti theft iButton function, see ButtonImmobilizer for details (also related to '''anti-flooding SafetyMode''' in 1.1.83) * Wheelspeed measures faster (lower time-constant used in internal software filter) ** '''second wheelspeed input implemented''', see: InputTrigger/WheelSpeed * New LCD page (page 10) ** I have been running/driving on 1.1.84 all day today, it is running well. I cannot test speedsensor response speed (my car is too slow!) until I install in race car this weekend. KevinBlack ** false-positive trigger-"errors" under certain conditions. Operation not effected. '''[http://www.vems.hu/download/v3/firmware/ 1.1.83]''' - was used for VIP-testing. '''Will not be released''' * '''anti-flooding SafetyMode implemented for firmware upload.''' * config/table switch modifications, see [http://www.vems.hu/manual/vemstune/help2/htmls/ VemsTune help ] for more details [http://www.vems.hu/download/v3/firmware/experimental 1.1.81] - '''Released''' * got many positive feedback. ** upgrade properly (always upload config after upgrade - even an unrelated old config from a very different setup is better than nothing). Do not even try to set everything manually. It will not work ! * easily configurable injection angle * better trigger-error indication ** we'll work for more graceful handling of trigger errors (related to injection-angle) ** some false-positive trigger-error got introduced in 1.1.80 when the new sectrig window was reworked, not fully fixed even in 1.1.81. It only effected the reported flag, not actual operation. Sorry about the inconvenience. Only report such false-positive if also happens in 1.1.84 or newer. * VVT (variable valve timing) reimplemented (not using anything from the old code). Only 1 control loop now, but target table reserved for 2nd control loop too. ** only for missing-tooth+camsync trigger ! Eg. coiltype or subarutrigger not (yet) supported [http://www.vems.hu/download/v3/firmware/experimental 1.1.80] - NOT released (1.1.81 or newer is recommended) * easily configurable '''injection end-angle''' (angular position when the injector output switches off) '''in function of RPM''' ** mostly matters at low load loadsites with aggressive cam engines. With a port-injected audi 20-VT (with cyl1 injector output in same position as cyl1 ignition output) smoothest idle and best throttle-reaction was achieved around 300 ATDC = 420 BTDC (was not very sensitive to precise adjustment, a window of at least +-30 degrees) ** secondary-trigger need to be configured as cam-sync for inj-angle to work properly. Without camsync (eg. with a missing tooth wheel) after startup, the chance for the sweet half is 50% at best. [http://www.vems.hu/download/v3/firmware/ 1.1.79] - '''will not be released''' * better low-RPM cranking behavior. Display calculated RPM (reading not stick to 100) well below 100 RPM. Also lowered min RPM for expected behaviour output actuation. Ign and inj outputs off below that. 28-70 RPM for most triggers (if signal is reasonably good). The real minimum RPM also depends on cylinder count, HW setup and trigger type and setup. ** the price is +1/2 crankrot to get initial sync in most situations. * '''config12=20''' (bit5=1) means wheelspeed is sent in km/h in the AIM packet ** config12=00 means wheelspeed is sent in 0.1 km/h (VEMS internal value *10) as in the [http://www.vems.hu/files/MembersPage/NanassyPeter/AIM_support/AIM-ECU%20protocol.pdf aim specs] . Fero says that unfortunately the AIM display does not follow the AIM specs, so AIM display shows 10 times higher than the sent value interpreted in 0.1km/h ** to enable/disable this divby10 one needs to upload small config12=20 configfile manually, or use 2010-06-28 or newer VT (or apply http://www.vems.hu/files/pacsa/aim_wheelspeed_patch.zip ini files to recent VT) * known bug: no TPS update under certain circumstances (harder to reproduce in real engine, easier on bench) [http://www.vems.hu/download/v3/firmware/ 1.1.78] - '''release candidate''' * note: coiltype withOUT camsync (c008 distributer) that didn't sync earlier also passed tests * '''stop the coolant-fan during cranking''' if RPM < cranking threshold * Subaru 36-2-2-2 support with camsync InputTrigger/SubaruThirtySixMinusTwoMinusTwoMinusTwo ** the code was backported to experimental/1.1.76 (see 1.1.76 below) * InputTrigger/TriggerLog changed so '''secondary trigger pulse timestamps''' (if secondary trigger is enabled) are also sent through the serial port to help installing and verifying camsync+crankwheel setups (like the subarutrigger that has 2 low-toothcount VR wheels). ** '''CRC also added''' so higher than 19200 baud can be used => not just for cranking log, but multiple thousand RPM can be logged as well. 19200 baud limits triggerlogging a 60-2 wheel (with or without camsync) to 900 RPM, and the 135 tooth auditrigger (45 teeth logged) to appr 1200 RPM. (ManmcB08mde40) 115200 baud allows much higher RPM (with 135 tooth auditrigger triggerlog is not recommended above 7000 RPM anyway). ** to support the sectrig timestamp and CRC, the format is incompatible with old format. The old tools will not work (mde40 can be captured with brayterm, but uptodate VemsTune needed to analyze the file or VT can also read directly from the controller). Actually the format was changed twice, now it allows other type of timestamps for future extensions (like ignition events) ** for the curious: mde40 output has 0x7E marked frames. Frames need unescape (0x7D,0x5D => 0x7D and 0x7D,0x5E => 0x7E). Each frame has N* primtrig + <optional sectrig> + 1byte type + 2 byte CRC (+ 0x7E frame-marker). With type=2 the sectrig is there (2 byte big endian timestamp in 4 usec resolution), while type=1 lacks sectrig timestamp. ** VemsTune Tools / Record, Analize Triggerlog is being prepared for displaying the additional data (from captured file or real-time data from controller) ** if the missing tooth advanced filter (primary trigger bit3=1) is enabled with auditrigger (c270 pulsetrain), than div-by-27 is applied instead of divby3. With this it's internally not a 90+1 any longer but a 10+1 trigger with tooth width=72 degrees, another_trigger_tooth=02 and h[1]=00 08 06 04 02 ... See 11500 RPM auditrigger log on InputTrigger/AudiTrigger (while most triggers have 25500 RPM limit, traditionally the 135 tooth auditrigger had sub-10k RPM limit, now beyond 10k RPM). [http://www.vems.hu/download/v3/firmware/experimental/ 1.1.77] - will not be released * unfortunately with the original HALL-dirac implementation missing-tooth + camsync did not syncronise at all (fixed in 1.1.78 experimental 2010-06-21) * using matching vemstune ini-s is absolutely essential. The new functions will cause serious problems with random values (think about injection and ignition trims). Review all the related dialogs carefully 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.