Crankhome VR sensor
Though MT does show RPM values when cranking (between 100-180 rpm), it always gets lost very soon:
The mdd0c logs indicate the crankhome-VR receives noise. We suspect it's 135-tooth ghost that might be injected; possibly in the magnatic domain (not wire capacitive coupling)
- using 22k pullup resistor to 5V
- "pullup for the crankhome was changed to 43k ohm resistor as well" ? so what is the truth ?
- without this 22k pullup I wasn't able to get any rpm signal to the ECU
- decreasing this 22k to 10k could help getting rid of the noise
- MEASURE DC VOLTAGE on the crankhome-VR input and on primary trigger VR input for that matter. (ECU powered, engine off: no cranking needed).
- C40 is also a suspect. Commonly used value is 220nF + 1uF. Maybe this only has 220nF that makes it more sensitive to noise at low RPM (cranking) ?
- verify this later. First
- All the grounds have been checked and are good and all are connected. OK, so installers made very strong grounds very close to EC36. 1 GND + all 4 GND connected with min 1mm2 wires max 30 cm from EC36 (possibly just 10cm). Should be fine than
The VR sensors' resistance seems fine:
- crankhome-VR sensor: 1007 ohm
- 135-tooth: 974ohm
Voltage values for the VR sensor connected directly to a multimeter (not connected to the ECU harness - no pullup). This proves the crankhome-VR polarity is good, since LM1815 in ECU detects falling edge on EC18pin12:
- +1.6mV when approaching
- -1.6mV when leaving the sensor during cranking of the engine
I have captured a mmd0c log which can be viewed here:
NOTE TO DOWNLOAD THE FILES, CLICK ON THE LINK, SCROLL TO THE BOTTOM OF PAGE AND CLICK DOWNLOAD!
Running through auditrigger_logformatter: the mdd0c seems very wrong, sectrig all over the place. Like if there was extreme noise on sectrig. Check grounds.
56 45 4d 53 20 76 31 2e 30 20 31 32 x 31 32 20 k70 a3d 32 2c 32 48 ell6f 3e 0d _ x x 0d _ x x x 0d _ 0d _ x x 0d _ 0d _ x P 0d _ x x x 0d _ x P a6 0d _ a6 x x x x 0d _ 0d _ x P 0d _ x P 0d _ 0d _ x P 0d _ x 0d _ P P a6 x x 0d _ x P 0d _ x P a6 a6 x x 0d _ x P a6 a6 0d _ x 0d _ x P 0d _ a6 0d _ x 0d _ 0d _ x 0d _ x 0d _ x x 0d _ x P 0d _ a6 x x x x 0d _ 0d _ x 0d _ P x 0d _ x P a6 a6 0d _ x x 0d _ x P 0d _ a6 x x x x x x 0d _ x P x x 0d _ x P x x 0d _ x 0d _ P 0d _ x P a6 0d _ x P a6 0d _ a6 x x x 0d _ x 0d _ x P a6 a6 x x x x 0d _ x P 0d _ a6 x x x
It is hard to imagine how can be so many sectrig pulses in above triggerlog, unless the crankhome-VR was inverted (at that time you captured !)
- turn ignitions on
- TerminalProgram, capture log / start log (realterm ver.126.96.36.199, Marcell never used that. brayterm on win and gtkterm/kterm/minicom on linux works well)
- mdd0c => I receive only 00 00 00.....
This is a showstopper, mdd0c log is needed to find out detailed info on trigger. (but it does not replace the DC measurements! just complements)
Wav files of crankhome-VR and crankwheel
Recorded with soundcard, as on ElectronicDesign/SoundRecorder
- the content (circumstances of capture) of files is NOT clear, this largely decreases the usefullness. You should make a list of the files, explaining, most importantly how b00023.au differs from the earlier files (eg. b00003.au )
- crankhome-VR was likely reverse before b00023.au and than became good in b00023.au (did you swap wires?). It's not easy to tell which is good polarity, because the soundcard often inverts the signal. But b00023.au has some noise that is not from primary trigger, but likely from ign and/or injection (might be a good sign). Earlier captures didn't have it.
- luckily, primary trigger does not seem to be mixed into sectrig
- review InputTrigger/AudiTrigger especially the crankhome-VR signal
- measure (and publish!) DC voltage on all 3 trigger signals (engine off but controller powered)
- don't forget to update your wiki page, linking any published files (people watch RecentChanges but not browse files)
- the only efficient way to get help is to publish in wiki what you are doing (measurements, circumstances, setup changes, results, captured files, etc...)
- email, irc, icq, etc... (see ChatViaIrc) are not used for support (unless the wiki site is down, hopefully never again), as they are unsuitable to make a comparably reasonable description of the setup / what's going / current status. Irc is good for nudging if the info is in the wiki, but otherwise only a waste of your time and others'.
link down mcd dump: http://www.freefileupload.net/file.php?file=files/300806/1156969552/mcd.log
Check InputTrigger/AudiTrigger to see if the related variables in mcd match.
link down mct dump: http://www.freefileupload.net/file.php?file=files/300806/1156969628/mct.log
link down copy of my MSQ: http://www.freefileupload.net/file.php?file=files/300806/1156969697/20VT+auditrigger+-+base.msq
A new trigger log since the ECU was fixed:
(note: prefer filenames with "_" not " " space )
My suspect is a reverse polarity crankhome-VR. This much noise on crankhome-VR would be unlikely otherwise.
We have changed both VR sensors, and verified that both work prior to putting them in. We also replaced the hall sensor with a known good one.
I have captured another mdd0c log here:
The RPM values during cranking are random and are between 100 and 220 rpm (something like: 120-170-200-180-210, etc, etc....)
We were unable to get another sound recording of all the sensors because something has either happened to the cable and/or laptop input.
But I have uploaded a recording that was taken by Claudio of the 2 VR sensors and Hall sensor prior to changing them, and they look very good and clean!
here is the link to the sound recording:
[audi_90_all_sensors.aup.zip] (just remove the .zip ending to revert the file name to audi_90_all_sensors.aup - IT IS NOT A ZIP! but the wiki web file thingie wouldn't let me upload the file with a .aup extention)
- use wav files (not "aup")
- prefer to zip them (not just rename to zip)
Every recording is named for the sensor and if it was taken in the engine bay or inside the car through the harness.
I don't know what else to look for...
Here is also a copy of the current msq that we were using:
make sure to dump with
- mdV (prints firmware version)