Here you can link your report issues with your Genboard V3, firmware, tuningprogram or hardware problems.
Make your report on your MembersPage, and place link in the relevant section (with a "title", so it can be remembered easily). If you dont know the section, put it under "Unknown".
In the report, include at least:
- board version, serial Nr.
- firmware version
- MegaTune version (when MegaTune is used at all)
- intended config.txt (possibly commented)
- mcdmct.txt (captured output of Manmcdmct command.) This is the live config. Very important, since in a bad case it can be different from the intended config (if you used a global.h from a different firmware version; or there is a MegaTune configuration problem, etc...)
- description of the problem
- your investigation so far
- any ideas to proceed
The report, to be considered, must contain ALL necessary info. Without the necessary info, question-answer iterations are needed, so solution is delayed in the best case. If there is not enough info to reproduce, the report is neglected (especially if it contradicts experience). Re-post with the necessary info if you believe it holds.
Hardware: - usually wiring. These are normally answered even if you only use your MembersPage, but if you insist...
- ...
Config: please use your MembersPage where the full setup (engine, triggers, whatever related) is described
- Trigger config or signal noise, but anyway severe misfires above 2.5krpm. v3.3, Serial_nr= 748, with modified Auditrigger ( = 2x VR, 132+1 ), 1.1.24/MT2.25 . Make sure that all data can be found at MembersPage/PeteKrgr, full mcd mct as well mcd & mct plus pictures of my circuit board and from oscilloscope added. Links in my members page.
Firmware:
- SVN 1.0 seem to hold the coil on for fuelpump time when the trigger stops. MembersPage/KeithHargrove/FirmwareBugs
may also happen with 1.0.73 But I could not get my config to work with 1.0.73 . Why ? You should try 1.0.73 or 1.0.75 to eliminate possible problem with your compiler
- InputTrigger/TriggerLog apprarently did not work with 1.1.25 firmware. MembersPage/Akos/AudiAbz RPM reading was fine, but no bytes logged during cranking after (Man)mde40 was issued. We didn't bother to investigate further (maybe we made some error?) because otherwise 1.1.25 seems to work fine (with MAP-based control. Wait before applying to AlphaN until rumours are investigated). Any bench test about this ?
- PS/2 keyboard doesn't work with >1.1 firmwares and GenBoard/VerTwo. 1.0.53 works with 20040720 winavr, but >1.1 tried 20060125 and even newer (that compiles otherwise fine).
- This may be something about newer winavr, because someone has decide to change #include <avr/*.h> to <util/*.h> and removed #include <avr/signal.h>. What even is the recommended winavr version for >1.1? It must be 20060125 or newer.
- DONE: (fixed in svn) knock control sampling was never enabled, due to define mix-up
- Min 95 RPM needed for ignition to work on 4cyl coil-type setup (3.17Hz 50% PW feed to trig1) ? Under this freq injection works fine but ignition doesn't work at all. Wondering is there such limitation with multitooth that could cause flood with slow cranking engines@winter? Shouldn't flood situation be avoided even with very low RPM ?
- DONE: (fixed in svn) If throttle is released while RPM is above config.overrun_fuelcut, fuel is cut by definition of overrun_fuelcut. So fresh air rushes through the engine. Therefore EGO closed loop is switched off until TPS is again pressed more than config.iac_tps_thres (or RPM drops under overrun_fuelresume). Of course EGO is off while fuelcut is active, but it doesn't switch back on even after RPM drops to idle (ego_min_rpm < RPM < overrun_fuelresume). Used firmware was 1.0.53 How could/should this be different ? Just to mention, because it is #1 in the required things list ;)
- DONE: (fixed in svn scheduled for next release) Firmware v53: PWM is not working correctly eg. when injpwm=7F pwm should be 50% when batt_cal is correct? I measured (injpwm=7F) 16V 62%, 12V 82%, 10V ~100%! This was kinda same before v53; injpwm6 added more pwm% @14-16V when it really shouldn't!, pwm dc calculation was limited at 19v, which obviously should have been 14v - DB
- DONE: (fixed in svn scheduled for next release) Misc output boundries were not included in range selection, therefore making for instance switch from 20 to 100% tps impossible - DB
- DONE: check ALS and Launch at the same time (it is reported by Roland that their on patch on 1.0.23 worked OK, but the (well, actually another car with) 1.0.38 (but no ALS related change between 1.0.36 and at least 1.0.43) ALS worked, and Launch also worked, but not at the same time - verified to work properly
- DONE: double-check operation at "> 100% injector duty"
- I made several experiments near (and above 100% injector duty), that is when injector pulsewidth > cam period (engine cyle lenght). I coulnd't find any problem, but I could make a stupid injpwm config that demonstrates the effect that resembles the rumours. See [RPM-sweep mp3 file and config]. Note the comment text at the top of the config.txt file.
- NOTED: Newest WinAVR can't compile 1.0.28 firmware direct from distribution correctly. ECU hangs and need to be jumpered into the bootloader. Downgrading WinAVR to 20050214 release solved the problem. Reported by RagnarB. Shouldn't this be reported to winavr instead ? Use of pre-compiled releases or winavr-20050214 is recommended
- This is also seen using the latest avr-lib release. Some incompatibility must've been introduced.
- is this the same as the previous report commented as "the ALS": Compiling latest svn firmware with ALS makes VE go all over the place, even with the same values in the whole ve table. Compiling without -D ALS it works fine. This is typically a compiler error that we cannot fix, we have seen it before: AtMega/AvrGccFAQ
- DONE: (in mainstream. freq was double) 1.0.30 [VemsMT1.0.30rc3.zip] the dualpwm iac doesn't seem to give fast iac-valve actuation. Tried iac_speed=06,07,08,09 (actually set in MegaTune, tested with mdi commands => as a result PID was untunable) GergelyLezsak's old code was good. More on it, and SOLUTION at MembersPage/GergelyLezsak/IdleControl/Firmware.
- DONE: A low temperature (lower than -40degC) showed as 76 degC with old EasyTherm generated table. This was a known feature, we dropped it.
- DONE: we should also make sure to include properly calibrated tables for the NTC sold in webshop 2200_287 (for v3.3)
- NOTED: Compiling (with what compiler version?) latest svn firmware (revision?) with ALS makes VE go all over the place, even with the same values in the whole ve table. Compiling without -D ALS it works fine. Use of pre-compiled releases or winavr-20050214 is recommended
Tuningprogram (Megatune):
- Megatune 2.25 released for firmware 1.1.18 (and patched to 1.1.26) always saves ALS input channel 0 to msq file. Sets the right value to ECU (unless its saved and reloaded from msq file). Annoying.
- TODO (in unreleased) h[2] new semantics is problematic, bits 2:0 and bit7 are NOT zeroed
- we have boost-target, boost-PID-integral, boost-command-DC and iac-PID-integral logged to megatune, give us a hint to show on some gauges'.
- Eg. add a 5th column to the selectable gaugeset. I added 5th column and even the 1st 4 got ruined (now white and aint work) => emil_ says "i dont think its possible"
- 2006-07-29 primary_trigger upper bits cannot be changed or even checked. Bit6 (nissan-trigger) and bit7 (currently not used, but still should be added) should be added, and if possible, a numeric field so the whole primary_trigger config value can be set or verified easily in one step (=> less chance for error) done
- note that this can confuse the unaware who doesn't care to dump his config and check a few values manually or publish mcd/mct so others can help
- 2006-02-26 naming: INJGROUP or FETGROUP or similar would be the right name for selecting inj-channel. The "group" suggests that it's not a direct output and the group needs to be configured elsewhere done, renamed to INJOUT
- 2006-01-31 [VemsMT1.0.30rc3.zip] looks like lambda bargraph is not working under VE-tuning (no dots at all) fixed from 1.0.36
- 2006-01-21 [VemsMT1.0.30rc3.zip] seems to show 40 degrees "spark angle" instead of 20 degrees (as on LCD, and in reality) fixed from 1.0.36
- 2006-01-19 rumours has it that knock-advance enable/disable in megatune (r28?) is reversed. Unverified fixed
- 2005-09-21 iac activation flag is inverted (Fero reported on phone): not sure which one, the (ON/OFF vs. PWM-stepper - likely) or ignition advance based idle active/OFF
- 2005-09-02
- EGT display (range) is bad, the gauge displays upto 256C (the digital display is good, but the gauge rails out) fixed from 1.0.53
- injector duty cycle... is this fixed already ? fixed in 1.0.36 at least
- 2005-10-23
- In alphaN-mode, at 22% throttle (VE, lambda or ignadv table) 56 kPa (255 * 22%) line is used. However MegaTune shows 117 kPa ( 512kPa * 22%) and places the dot at a different place, Tunable, but very confusing
- Ini file -> vemsv3_v13_r021.zip or up to mt-r027
- firmware -> 1.0.13 .. 1.0.18 .. 1.0.22
- possible solutions:
- fixed in next release: when reporting load, in comm.c A command offset 4 and 5, <<2 used instead of <<3 from 1.0.23. User must still be aware that MAP gauge only shows MAP when RPM > hybrid_rpm_m and load otherwise
- in the future, firmware might report load and kpa in different positions (the dot should always move according to load, MAP gauge always display MAP)
- If you are running alpha-n only and not hybrid mode, its possible to modify vemsv3.ini to show TPS in the realtime tuning, write here or memberspage if you need help.
- thanks for the info. I'm useing Alpha-n only, yes I need details how to modify vemsv3.ini
- Megatune Accel wizard display shows current TPS instead of changespeed of TPS.
USB-rs232 adapter cable windows driver - prolific pl2302
We found a NASTY problem with the USB-adapter windows driver.
- [prolific download page]
- wd_pl2303h-hx-x_v20019v2021.zip 2007/3/22 1471 KB
- v2.0.2.1 for Win2K/XP/2003 (XP Logo Certified)
- used on windows XP-2002 SP2
The windows driver is unstable when 62 byte runtime-log is logged (D command), even if it seems reasonably stable when 56 byte is logged (A command). The user had no problem with 1.0.73 but found newer megatune 1.1.2x unusable ... as we found out later, because of the bigger runtime block. We got certain when reconfiguring the 1.1.2x megatune to use the shorter 56byte block from the A command, it became stable again.
When it freezes, the app cannot be killed from taskmanager, and usually the machine must be hard-rebooted. It is almost certain it is not an application bug, but a windows driver bug. If it was an application, the app would be easy to kill from task-manager "End task". And it would not show up with the alternative "bray terminal" app.
We have to admit it was more stable (maybe freezing every 10 mins not every 2 min) with older windows, even with 62 byte.
Anyway. I'm writing to prolific.
I doubt that it's a MegaTune bug (or intentional behaviour) because v3gui and even a simple terminal program had the same problem
Workaround for now: megatune vemsv3.ini must be configured with ochblocksize=56 and "A" command, not "D" command
V3GUI
- Release (v3gui.exe) made at 2007.08.03 seems to ignore the CLT patch file selected when uploading firmware
- 2007-08-03: in a new session, the mcd-saved.txt and mct-saved.txt entries disappear in the "download config" menu because these entries don't make it into the v3gui.cfg file (likely fixed, must be checked)
- no success message after firmware verification (error is indicated if there is an error, but success should also be indicated)
- 2007-09-17: the session is not (always?) saved
- in the release zip, under ntc/ directory, .hex files must be renamed to .clt and .air otherwise it's unintuitive