_   _ 
 | \ | |
 |  \| |
 | |\  |
 |_| \_|
        

  ____  
 |  _ \ 
 | |_) |
 |  _ < 
 | |_) |
 |____/ 
        
        

 #       
 #       
 # ###   
 ##   #  
 #    #  
 ##   #  
 # ###   
         

 __     __
 \ \   / /
  \ \ / / 
   \ V /  
    \_/   
          

###      
 #####   
 ##  ##  
 ##  ##  
 ##  ##  
 ##  ##  
#### ### 
         

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
'''Collecting explicite''' information on some BMW E46 M3 engine install. We've guessed way too much already, and been on the wrong path because of misinformation. '''PLEASE make measurements, and REPLACE QUESTIONS WITH ANSWERS so you specify every significant aspect of your setup''' ---- '''ECU is v3/10172 - confirmed''' Originally vemslog from another ECU: v3/10112 (originally manufactured as HALL/HALL) was provided, so it was '''suspected that ECU has HALL primtrig input and VR primtrig sensor was actually used''' * but uncertainty about trigger, or wrong vemslog from another ECU makes support ineffective despite the extra work. [http://vems.hu/vemstune/bugreports/reports.php?cmd=view&key=3SAHAH here] is is the '''right vemslog file of the V3/10172''' * there is '''no primary trigger signal. only the battery voltage drops when I try to start'''. OK, so serialnr is corrected, '''still no explicit information that VR trigger is used (although suspected so, but no verification measurement)''' * If you need help, '''fill in the missing''' info on this page as instructed (eg. VR sensor resistance, to have the initial set of sensible info finally (required for tech support). Not specifying (=> guessing) trigger type or falsely specifying serialnr (=>guessing) ECU serialnr (or, in this case both :-) makes support impossible. Be exact about the sensor type, measurement details so practical advice can be formed and support can be attempted. ---- '''P259 outputs''' * can you test P259 outputs ? ** Measure with DVM, with +5V or +12V as a reference (or for example 100 Ohm or higher pullup resistor). ** configure MISC2 output to certain p259/x - make sure it is not configured for anything else - and toggle, expect output ON/OFF If LM1815 input is good, but no output (logic level signal to processor): it can be '''suspected that p259 got damaged and LM1815 +5V''' (shared small regulator for p259 and LM1815) is pulled near GND, preventing LM1815 operation. '''Possible causes''' of p259 damage * grounding was insufficient (temporarily, or persistently), see GenBoard/Manual/GroundConnections * output current overload (low resistance load or short to +12V ?) * welding, lightning, static electricity * ECU disconnected while powered up * small metal fragment inside ECU (extremely rare, but not impossible, eg. small Al chip) * problem caused by condensation (rare) * aging (unlikely) * other reason If p259 is confirmed to have failed, and grounding is absolutely good (or better), p259 can be removed (ECU can run without p259 chip if GND is good) If we '''drop 2 ECU-s from the 10th floor, and one survives, the other fails, it does NOT mean that doing so is within specifications, or that the failed device was bad from the start'''. * Engineers call it "unspecified behaviour": one device might work (perhaps for some shorter or longer time), the other might not, although both were good originally. * there are several electrical equivalents of dropping ECU-s from the 10th floor (insufficient grounding is one of them); ** Unfortunately it is often not easy to recognise (without very careful inspection => it is possible to damage several devices in the same setup; happened before, so '''careful inspection, measurements and taking notes are highly recommended to prevent further problems''' ... believe it or not, it is NOT to cause extra work, but to prevent more problems to follow) ** Some ECU might survive, others might not, and from the fact that "it works with ... ECU" => it is absolutely invalid to conclude that the other ECU was faulty ** people usually (almost always) draw that conclusion, but it's wrong ** we've seen thousands of setups, we can help with careful inspection to make it work reliably in the long term if (and only if) doing measurements and taking notes and other instructions are followed ---- '''Measure, and FILL IN / CORRECT / CONFIRM details''' '''Primary trigger ... VR or HALL ?''' Check basic things '''If VR:''' * '''measure VR sensor resistance (expected: 400..1400 Ohm)''' * also '''measure (with ECU disconnected) between EC36/pin27 and EC36/pin26: is resistance the same ?''' * with ECU powered and sensor connected: '''measure DC voltage on EC36/27''' (expect +150..250mV) ** with '''primtrig disconnected, and 1k between EC36/27 and GND 0.15 .. 0.25V expected''' '''If HALL trigger (now unlikely):''' * measure HALL supply DC voltage (usually +5V, rarely +12V) ** optional (note): HALL supply current is usually 6..15mA * please measure EC36/27 voltage with sensor disconnected (expect >4V) ** and with a 1k between primtrig sensor and GND (0.8 .. 1.5V expected). ** If not good: apply a 4k7 .. 6k8 "pullup" resistor between signal and +5V and repeat measurement. * can you scope EC36/27 HALL signal ? 0.5V / 4V or similar ? With HALL sensor you can even measure with DVM, pushing the car a bit in gear5 the signal will change 0/5V or similar. I hope that helps, we can continue with some useful input. ---- In anything trigger related the trigger type is important to mention. A working ... sensor is used ? v3/10112 has HALL/HALL inputs and it will NOT work with VR sensor; the spare ECU might have VR input and that explains why it works. In VT report v3/10172 is explicitely mentioned, but v3/10112 in the filename was more believable (when discrepancy: usually the filename is correct and human text is errenous) '''v3/10112 (the original .vemslog was from, but it seems was misleading info''' (from oid10258): 1 x ECU VEMS V3 - withSDcard: no - Service: normal - secondary_trigger: HALL - '''primary_trigger: HALL''' - mounting-style: flanged case - MAP connection: 300 kPa simplenipple - LCD connection: no - Knock input channels: 1 - ignition driver: 8 - Flyback: HighZ-only 30V flyback - EGT input: no - 1-wire interface: no ---- Note : 10172 seemed FALSE originally, but now we consider '''v3/10172''' from OID10493 to be the ECU in the setup with trigger problem, which has VR !!!! : 1 x ECU VEMS V3 - 1-wire interface: no - EGT input: 1 - Flyback: HighZ-only 30V flyback - ignition driver: 8 - Knock input channels: 2 - LCD connection: no - MAP connection: 300 kPa simplenipple - mounting-style: flanged case - '''primary_trigger: EC36/27 VR''' - secondary_trigger: EC36/13VR
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.