MembersPage/Sascha/AudiCoupe/TriggerPage
MembersPage/Sascha/AudiCoupeMembersPage/Sascha/AudiCoupe/TriggerPageMembersPage/Sascha/AudiCoupe/OutputWiringMembersPage/Sascha

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)

The VR sensors' resistance seems fine:

Polarity

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:


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!

link down http://www.freefileupload.net/file.php?file=files/300806/1156968999/mdd0c.log

Running through auditrigger_logformatter: the mdd0c seems very wrong, sectrig all over the place. Like if there was extreme noise on sectrig. Check grounds. \n

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 !)

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

[Sensors 1 of 3]

[Sensors 2 of 3]

[Sensors 3 of 3]

Notes

Important notes


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:

[new cranking mdd0c.txt] =>

[Sascha_2006-10-02_1_mdd0c_formatted.txt]

(note: prefer filenames with "_" not " " space )

My suspect is a reverse polarity crankhome-VR. This much noise on crankhome-VR would be unlikely otherwise.


Updates

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:

[all_new_sensors_and_proper_verified_polarity_log.txt]

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)

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:

[newest_config-1.0.53_firmware.msq]

make sure to dump with

and zip and upload those dumps. That is the most reproducable way, knowing the firmware version we can reproduce the config 100% without chance for error.