My plan is to install v3.3 on a Porsche 944 -83. My idea is to place the the genboard in a empty motronic box and use as much as possible of the original wire harness. I guess one of the bigger problem I will have to deal with is the
trigger system 2 VR-sensors
- one keeping track of the referens point ("crank home") 58.5 degress before TDC
- crankhome-VR counting the 130 teeth on the starter gear.
I understand it is a version of the "auditrigger". The engine will be using the stock motronic distribiuter to start with.
2007-04-25
Anyway, I had the car running last year but with some kind of trigger problem around 6000 rpm. I used firmware 1.0.36 and the 'standard modifications' with bigger C40, shorted R182 and 14k pullup for the crankhome-VR signal. C103 problem is also taken care of and I changed R57 to allow higher rpm if needed.
Trying to fix the problem I tried a resistor network to feed back a part of the disturbance signal in opposite phase but it didn't help at all since I didn't get the signals to cancel each other as expected.
- The sensors are probabaly not placed in such a way so it is possible
- did you try to reverse the 135-tooth signal ? If motronic uses magnetic-shadow elimination originally, than this is most certainly needed (since we have reversed the crankhome-VR)
The engine was running but got trigger errors once the rpm was over idle speed.
My next step was a firmware update to 1.1.22 and the latest suggested modifications to the HW according to the InputTrigger/AudiTrigger page. Right now it is not working a all. I get a RPM reading while cranking but it does not want to fire like it should. I have to study more about the latest auditrigger info.
- take care about the GenBoard/UnderDevelopment/FirmwareChanges, eg. since stepper outputs can be used for ign-output, instead of 03 you must write 20 in h[2] to fire ignch2
- h[2]=...
- you might want to share your old (1.0.36) config/tables and your 1.1.22 guesses so we can review and help. It is very likely that it's just something minor
OLD
No one who knows anything about the triggersettings for the auditrigger?
- similar as InputTrigger/AudiTrigger , BUT
- tooth_wheel=87 (decimal 135; yes, this is important: 135 as this tells the ECU that auditrigger style is needed! Don't change it to 130)
- another_trigger_tooth=36 needs to change from decimal 54 to 2*130/4=65
- trigger_tooth and ign_tdcdelay: I'd apply orig values first, than use your lamp and tell us
2006-05-04
I have trouble understanding how to set up all trigger settings for my configuration. I'm using firmware 0.36.
This is my current config.txt, it has a lot of strange things and errors lets focus on the things that will give me a stable trigger and correct rpm reading in Megatune.
http://www.vems.hu/files/MembersPage/MagnusKarlstrom/config/mcd.txt
I guess these are the lines to put focus on, correct?
divider=02
alternate=11
rpmk[0]=0B
rpmk[1]=B8
config11=30
config12=30
config13=00
primary_trigger=C3 ????
secondary_trigger=99 ????
tooth_wheel=82
trigger_tooth=00
another_trigger_tooth=41
crank_minper=30
tooth_wheel_twidth1=01 ????
tooth_wheel_twidth2=FF ????
cam_sync_r_edge_phase=03 ????
cam_sync_f_edge_phase=03 ????
reset_engphase_after=05 ????
toothrel_normal=FF ????
toothrel_missing=FF ????
I think we need ONE good page that explaines all trigger related settings in the config.txt, I can't be the only one who don't understand it...
2006-03-31
The MAP/TPS issue was due to some errors in the config.txt. With help from msnordic I found the Alpha-N/Speed-Density Blendning under Extras in menu and changed from 25500 rpm to 0 rpm. That fixed the MAP problem.
The other problem:
Code version does not match signature in vemsv3.ini
Expected "VEMS v1.0. 12x12 kpa=2,1
Received "VEMS v1.0. 12x12 kpa=F,F
was fixed by downloading the config.txt from the board and remove the last strange line which caused an error and generate the config again and upload it.
- can you publish a config.txt that you think results in bad config.mtt (also, take note of how you generated it, eg. with make_conf.pl or UsabiLity/GenBoard/WinTools) ? Maybe it's possible to make the mtt generation more robust.
I have been looking at this and when I use download-config.bat it takes a very long time to perform the download and the result i corrupt. The last lines of the config are:
boost_conf=FF
boost_targetoffs=FF
boost_minpressure=FF
boost_pid_kp=FF
bip_b
_ywFhaoFkfF=ro_fop
With mcd in the terminal it works fine and the config can be generated without errors :-)
The only strange thing at the moment is the firmware upload problem, it only works once in a while and only after board has been without power for some time.
Maybe it sees RPM signal (depending on trigger setting and trigger HW) ? If so,you need the "f" option with prog.pl (or megaloader) so it enters BootLoader even if "engine running" (use with care; eg. fuelpump and ignition coils unpowered if possible). But since I have a working firmware uploaded I don't care to much about it right now.
Now it's time to get back to the trigger again. Hopefully I will soon be able to bring the car to Ă–rebro so I can do some tests on it.
2006-03-29
- Since both applications (firmware upgrade and MegaTune) seem to have problem, the serial port might be a good first suspect. Are all other readings in MegaTune OK ?
Controller code version does not match signature in vemsv3.ini
Expected "VEMS v1.0. 12x12 kpa=2,1"
Received "VEMS v1.0. 12x12 kpa=F,F"
The F,F explains things. It seems like a configuration issue (the kpa_conf=FF currently in effect is meaningless; admittedly I didn't know that it results in such interesting and confusing show, maybe Dave Brul will give it some test and maybe make it default to some less surprising default behavior for bad config).
- kpa_conf=21 # MAP sensor (config.kpafac) resolution = 2kPa; other config items (including k[] table) is 1 kPa unit (not "high-boost")
- (Man)mttcmttgb3mttc21mcs(bye) would be a quick command to send (make mtt would get something similar with a short config.txt file that only has kpa_conf=21 ) in if you cannot quickly find these variables in MegaTune
It is a bit hard to tell if all the other readings are okay since I don't have sensor hooked up to the board. Battery voltage and TPS are however okay.
A very strange this is that the MAP value is following the TPS value!
- the offset used for MAP (runtime; or MAP related variables) between firmware and MegaTune didn't change.
- maybe you have LCD ? if no, check Manmll command and look for P... like P102 (which means MAP=102kPa)
Manmll returns:
RPM:0000 W00SFFI00
58 -00 c0000 i0000
0000 iac:040 122
- mcd dump (check kpafac, kpaofs)
kpaoffs=80
- in any case, it's a good idea to check the basic stuff, like ground, flyback, etc..
2006-03-28 first update since the dinosaurs left us...
Problem again
After moving to an other city and some other stuff I thought it was time to make some progress with the VEMS project. Downloading a new version of the firmware and Megatune felt like a good start, specially since the firmware now has support for the trigger on my car.
After having some problem with the firmware upgrade due to 50Hz disturbance triggering the LM1815 circuit I finally managed to figure that out with some help from Emil (using 'f' option to megaloader or prog.pl I guess). The board was upgraded to 036 and config files uploaded with some warning and an error.
I started Megatune and at a first look it looked okay, but it was not. The map value is not behaving normal at all, it starts at 0 and then slowly climbs to ~140 kPA shows no response to blowing and sucking in the hose to the MPX sensor. This worked okay before I started the upgrade. The MPX sensor also seams okay since the output voltage changes with the pressure.
My next step was to try to upload the firmware version I previously used but that didn't help, the map value is still crazy. It also took me many tries before I managed to upload the firmware despite that the trigger inputs now are shorted to prevent disturbances. The upload process fails at a random point and reports an error writing a word. After many tries and leaving the board disconnected for a while I finally managed to upload the 036 firmware and config again, but the map value is still crazy.
That is wrong with this board? Didn't it like to move from FinspĂĄng to Ă–rebro? I did :)
- Since both applications (firmware upgrade and MegaTune) seem to have problem, the serial port might be a good first suspect. Are all other readings in MegaTune OK ?
- the offset used for MAP (runtime; or MAP related variables) between firmware and MegaTune didn't change.
- maybe you have LCD ? if no, check Manmll command and look for P... like P102 (which means MAP=102kPa)
- mcd dump (check kpafac, kpaofs)
- in any case, it's a good idea to check the basic stuff, like ground, flyback, etc..
2005-10-xx
Problem is probably solved! :) I replaced the xtal before I checked my mail and this page and that seems to have solved the problem. I made some comments below.
Serial cable and power cable has been attached to the board for some initial testing before soldering more parts to the board. The only problem is that it does not work the way it should.
Strange, because boards go through testing, during which all the supplies (7 or 8 including the max232 -8V), the ISP, the serial communication, the WBO2 pump circuit is tested.
- the Mega128 seams more or less dead (no signal at the x-tal). how do you measure the signal? The impedance of the measurement device can stop the xtal oscillation. However, you can try to heat the xtal solder. I used my oscilloscope and a 10:1 probe so I don't think the impedance was a problem since I have used it before with other chips. Heating up the xtal solder didn't help.
- often it takes half an hour before it starts up so you can get some communication with a terminal program. Manmll command works fine (this is impossible without
- but Megatune can not connect to the board. don't forget to leave "Man" mode (if you entered) by issuing the "bye" command. I rebooted the card after switching to Megatune
Once you get it starting it will stay alive until you remove power for a few minutes. 5V supply is always okay and the reset signal goes to high every time you apply power.
- My next idea was using ISP cable and BASCOM-AVR to connect to the chip and see if BASCOM's 'identify chip' function worked. It did not, BASCOM didn't get any data from the chip. BASCOM and the cable worked fine with a Mega88 chip both before and after my test.
- Are you aware that the atmega128 has the PDI, PDO in the ISP interface (not MOSI, MISO) ? Acording to the schematic MOSI and MISO should be found at pin 7 and 8 in the JP_ISPI?
- you can measure all supplies of the AVR (there are a few VCC, AVCC, AREF...)
- measure supply current around 80 mA on first start up (not working)
- write serialNr 351
- inspect the AVR and max232 area visually looks good
Q: What to do next?
- order a new board from WebShop (and optionally a few small parts you like), choose money-order (don't pay, just refer to this site). Keep the "believed to be bad" board in it's current state before we decide about it (either you'll find later it was just something small, or we'll ask you to return later to someone in Sweden or Hungary).
A very nice offer, hopefully I don't need a new board now.
2005-09-XX
The parts has arrived and everythings looks fine. Delivery was very quick! :)