Solution to MT error w/ VEMS Signature
The firmware that was shipped with my VEMS unit was 1.0.38. I then attempted to up/downgrade the firmware versions until I wasn't getting this error anymore, and now with 1.0.32 it seems to be ok. But the more I look through the WIKI the more I find people being able to use the newest 1.0.38 firmware, yet I'm not.
Q: Can anyone point me into the proper direction so that I can get megatune to run with the 1.0.38 version of the firmware? I tried the 1.0.23 version which I'm guessing is the last "stable" version according to the FirwareChanges WIKI, but the LCD comes out all screwed up.
A: Start MegaTune either way, even if it complains about the "signature". Go the menu : Settings -> Basic Settings. Now check that your "Map Range Unit" and "Table kPa Unit" are set correctly.
Thank you for the quick reply! But I have told MegaTune that my Map Range is 400 kpa (as I have a 4Bar onboard MAP), but am unable to find the Table kPa Unit you are talking about under Basic Settings. BTW, I'm using/tried MegaTune version(s): MegaTune2.25b654 and MegaTune2.25b748.
I _think_ that MegaTune2.25b748 is old, you could try the version in: http://www.vems.se/UserFiles/File/VemsMT1.0.36.zip that is what almost everyone here in Sweden is using. -Jörgen
Q: Could it be that I need a different MegaTune ini file? The strange thing is that with firmware 1.0.32 all is well, and I don't get this error, but as soon as I uprage to anything newer (up to 1.0.38) I have this problem.
This is the exact error I'm getting from MegaTune, so hopefully that will shine some more light on my problem for you. Thanks!
MegaTune error:
Controller code version does not match signature in vemsv3.ini.
- Expected "0x32" (found in ini file)
- Recieved "VEMS v1.0 12x12 kpa=1,9" (from controller)
- Table corruption may occur, this is usually a very serious problem.
This indicates old ini file. Download newer MegaTune. (maybe only the ini file changed, but easier to download the whole bundle).
Knock sensor info
Also another Q: When connecting knock sensor(s), the VR6 has two, could I connect both to one channel on the VEMS (ch 0)?
As in the VEMS manual (chapter 9.9) it says that Knock A (channel 0) is the one that commonly used, and that Knock B (channel 1) isn't.
- And that Knock A has a pinout on EC18pin3
- true
- but doesn't list a Knock B pinout
- true - not connected. If you really need it, it's possible to connect to it with only removing endplate (an 0805 resistor and capacitor might also be needed, and the wire(s) of course - maybe to a 6.3mm jack mounted on endplate ?). I'd postpone this until everything else works fine.
Easy Therm - Sensor adjustment
For the VR6 the coolent sensor reading is off... I've tried the offset files, but still no luck with getting a decent reading...
So, my plan is to test the sensors, get the proper ohm readings, and then re-compiling the firmware.
I will then make the firmware available.
The Bias Resistor value for the V3.3 boards is: 2.968K Ohm
1.0.73 Firmware related issue with EGO correction/Lambda Target tables
I believe I have found a possible bug in the current version of 1.0.73 firmware (12x12 or 14x16 tables).
I have found that even with EGO correction off, modifying the Target Lambda Table map will change the AFRs. This must be looked into. This is a problem I've confirmed on two separate ECU's/installs running 1.0.73 one car is running 14x16 tables and the other 12x12.
G: it is not a bug!! Lambda table stays lambda table w/o Ego correction too and take a part in fuel calculations. So VE table is closer to real VE of given engine and desired AFR has no influence on its shape. It is great, because: if you want change AFR at some load region on already tuned engine, only one table must be changed - Lambda table; and VE table gives better idea about engine. My safe way to get VE shape is set Lambda table rich at dangerous areas and after VE table is finished, just find best afr for given engine by changing Lambda table only. MembersPage/GintsK
Issue with engine cutting injectors/ignition??
I just finished an install of a VEMS V3.3 on a Corrado VR6 Turbo. I successfully tuned the engine on the rolling road up to 8psi. I did not notice any erratic changes while driving. But customer says that while he is driving at a constant speed/throttle the car will 'turn off' and then after a few seconds resume with a loud backfire the engine will resume again.
Now I have had this issue once before on my friends BMW. At first I thought it was the RPM sensor (VR) and or the wiring, so the sensor was replaced with a brand new unit, and the shielded wire from the VR sensor plug back to the ECU with new wire. The problem still persisted. What I did to get rid of the issue was to load an older MSQ file and that made the problem go away. At that point all I did was import the VE, IGN, and LAMBDA tables into the older MSQ and the car ran fine after ever since.
But now I'm starting to think there is an error somewhere in my MSQ, CONFIG files? I will need to get a recent config download tomorrow from the ECU and will post up here. Strange thing is, I'm not using the same firmware version, and I didn't use the MSQ file from another tune. I started with default configs from the firmware, and made all changes via MT for the ECU options. Possible fault by doing so through MT in the config?.
- Found the cause of the problem, it dawned on me today while at work. Then applied the changes to the Corrado and all is well. The problem was the fuel cur under (kpa) setting.. it was set at 28 kpa, so during light cruise the map sensor would sit around 28 kpa or slightly lower, and then cut fuel. Set to 10 kpa now and the problem disappeared.
- Correction, the problem is still there on the Corrado, and now I have this issue as well on another VR6 turbo car. I really need help to figure this out because of then the backfire during cruise the car runs great. Seems to happen the most during cruise with little to no change of the TPS.
- Publish logs, with note of the position (eg. file ... 1452 sec) where the stumble happens.
- watch for wheel errors.
- watch for other strange things: irregular sensor reading, RPM, corr.air and corr.gamma, dwell, pulsewidth or other suspicious things
- Try to guess if it's ignition or injection cutout. (although often hard to say. Backfire makes igncutoff more likely)
- check everything in VemsTune as well. Go over all settings and tables, everything - also the features you think you do not use. Especially MAT-enrichment related, N2O and the ones GenBoard/UnderDevelopment/FirmwareChanges warns about, related changes between 1.0.73 and 1.0.78
Try these - although we cannot say at this point that any of them is likely to fix the problem
- use ignchmax=05 (not ignchmax=02) for 6 cyl, and set the first 6 entry of the h[2] ignition outputs table
- use crank_minper=00 instead of crank_minper=9C
- try to downgrade to 1.0.73 and see if it persists.
Note that you must make a page for the project, thematically organized (not chronologically, and not mixed with other projects, like this page). In this case you definitely want to publish the trigger details, eg. measured DC voltage, and how you verified trigger polarity GenBoard/Manual/VrSensor/Polarity.
Config and Tables for the 24V Turbo VR6:
http://www.vems.hu/files/MembersPage/Sascha/problems/backfire/base2.msq
http://www.vems.hu/files/MembersPage/Sascha/problems/backfire/config.txt
http://www.vems.hu/files/MembersPage/Sascha/problems/backfire/tables.txt
Sept 18 2008 - Injector driver issue
- Feb. 5 2010 - PROBLEM SOLVED! Was the old flyback board + 30V diode + 630cc Siemens Injectors. Removed old power flyback board = problem solved!!
Having major problems with the ECU! Two days ago injector driver 1 blew. Just today injector driver 6 went. The car runs fine. The tune hasn't been changed at all. What could be causing random injector drivers to fail like this?
- I know it's dumb, but are your flyback connections OK?
- Not dumb at all actually... I check that yesterday... Although I couldn't see or measure anything wrong with a DVM... I decided to cut out the diode and put in a new one... Been good since then! Thanks for the suggestion though.
- Obviously false alarm, blew another injector driver tonight. #6 again... this is not good at all... anyone have suggestions? It also seems like there is a backfire at the time that this all happens and after that the inj. driver is dead and it's flooding the cyl.
- CHECK YOUR ANALOG GROUND! CHANGE THE WIRE. THAT WILL BE THE PROBLEM! --FERO
- Thank you I will check that today!
- Update on problem... I removed the analog input and all is well after replacing the INJ drivers that were burnt. Thanks again for the insight!
- Thank you I will check that today!
- CHECK YOUR ANALOG GROUND! CHANGE THE WIRE. THAT WILL BE THE PROBLEM! --FERO
- Obviously false alarm, blew another injector driver tonight. #6 again... this is not good at all... anyone have suggestions? It also seems like there is a backfire at the time that this all happens and after that the inj. driver is dead and it's flooding the cyl.
- Not dumb at all actually... I check that yesterday... Although I couldn't see or measure anything wrong with a DVM... I decided to cut out the diode and put in a new one... Been good since then! Thanks for the suggestion though.
Back to MembersPage/Sascha