What to measure and what to think about when running secondary trigger VR on a 3.2 or 3.3
- is the correct solder jumper installed?
- SJX
- is the sectrig LM1815 pin7 adaptive threshold RC circuit soldered on fine ?
- check the schematic
- Don't forget to look for missing components, especially the 0805 resistor from LM1815pin7. 100 .. 180k is fine, or even a 0k short.
- What signal does the LM1815 output to the AVR on IC3?
- Should be a 0/5V square waveform, only 5V for a short 60usec after the input negative going edge
Make a report of your measurements. All pins.
Report reasonably please
- NEVER forget the version serialnumber history of the board
- did you make the sectrig part ? You likely forgot a part from the sectrig part. It involves only a few components, just check the sch and the components. What part connects to LM1815pin7 ? Something is in the air (with 1 pad) ?
- take pics of the LM1815 involved area
- Make a report of your measurements. All pins.
If you start to write these few things systematically, it's very likely the problem is revealed in no time. Rumbling on irc you waste much time, without result. This is very important. Reports without the most basic info, or to the wrong place is useless.
Emil's board - reply after the report requirements stressed on irc
v3.2, standard, Earlier trigged by primary trigger VR in a car.
- It seems my board works both with secondary=HALL and VR driven by soundcard.
- configs: http://kombi.ulkhyvlers.net/vems/audi/
- it seems to work, but with auditrigger config, after trigger is stopped, it does not resync (only after reboot). Investigating the possible reasons. Very strange, since the firmware difference between auditrigger and coiltype primtrig + camsync setup is minimal and located at one place
- coil-type + home signal (and matching config) works fine, syncronizes as it should even after a stop
Miska's board
- V3.3, with auditrigger setup (complete board)
- No any reasonable output signal on output pins (pin10, 12) when input signal is applied Note that truth table say that pin11 must be low for pin10 to reflect RC pulse.
- Measured 100mV level from pin 12
- stays at 0V constantly, except for some noise when voltage drops in pin14
- in comparison between primary and secondary, only difference is missing output
- Input signal
- Feeding 5V logic level signal through series cap
- Measured secondary trigger input signal 900mV square wave from pin3 (-200mV to +700mV)
- Measured primary trigger input signal 970mV square wave from pin 3 (-200mV to +770mV)
- All components ok (according to sch) in visual check
- VCC (pin 8), GND (pin 2) ok
- in Pin 14, raising voltage after positive going zero-cross, falls down to 0 at negative zero-cross
- in pin 7, voltage rises when input signal is applied.
- Measured 2V level from both primary and secondary triggers with applied signal
- Repeated the tests with output disconnected (SJ7 open) and 5.4k pullup to Vcc with same results
- Problem was solved by replacing lm1815 chip. There was still some problems, IC3 voltage was 3.88V constanty. I desoldered C103 and it seemed to help (solder blob under it)
- When testing in car I had similar problems (secondary and primary signals gets mixed, lots of false secondary triggers) that Magnus is describing below. With mdd04 logging applied, trigger pattern looked like SpSPSpSPSpppppSpPpppppSpPpSpP...
- Using appr. 0.5m shielded cable with 2 signal wires (signal and signal gnd) between motronic and EC36 connectors. Both VR signals have their own cable. Shielding is connected only to motronic connector end.
Magnus board (aka 944_Driver on msnordic)
- V3.3 Serial 351
- U12 and R162 soldered to board and a pull up resistor is added between U12.11 and VCC as shown in the LM1815 data sheet.
- Stock Porsche 944 engine with 2 crank sensors but no cam sync. (Motronic 1.1, working fine with the sensors)
The problem is that interference from the starter gear sensor is triggering the secondary LM1815 circuit too. Cranking on the starter with the plugs removed and I get about 15 Vpp from the starter gear (quite high for cranking speed) sensor and 1.5 Vpp from the crankhome sensor. The interference found in crankhome signal is about 200 mVpp. Shielded cables are used all the way from sensors to the board.
So you are sure, that
- the crankhome VR sensor (600 Ohm?) is connected
- try to use separate shielded cable for the crankhome VR, not the same as used for the cranksignal. So use 2 shielded cables, min 2 wires in each, 1 for GND and other for signal. Connect shield on ECM side only
- try to divide the 15V crank signal with eg. 10k/1k resistors at the ECM side, and see if the interference drops to 10 (it's at the board: we'll find out sg.) or aint drop (in the cable: in this case move the dividor circuit to the sensor end of the cable)
- Do you see other suspicious things, like serious ground or supply noise ?
- where is the location of interference ?
- in cable ?
- onboard ?
- at LM1815 section
- from EC-pin to LM1815 wire ?
I tried to decrease the starter gear senor output by applying a 1.5 kOhm resistor in parallel with it, but that didn't do much good. The interference got smaller but not much.
Is it possible to modify the circuit around the second LM1815 chip in such a way that the interference is ignored at all engine speeds? Just connecting the U12.5 pin to VCC will probably not fix it for all rpm I am afraid since the interference will get bigger with increasing rpm.
Does anyone know how Bosch solved the problem since it works fine with the stock motronic box?
It's very important to check that the secondary VR ("crank-home") is not inverted. The falling pulse-edge at the zero-crossing must be fast and sharp.
It's also possible that the signals mix in the magnetic field. If separate cables are used, and scope shows that primary is injected into secondary even with ECM removed, than this is the case. The 135-tooth can be reversed if necessary, so it can easily be subtracted from the secondary, with only just one properly sized resistor - but hard to size the proper value for this mixing resistor without a scope. (maybe also possible, looking at the mdd04 log output, and sweeping through possible values with a variable R: the midpoint of the R-range where the interference is removed is OK).