InputTrigger/AnalogSide

This page is about the LM1815 circuit we use for InputTrigger on GenBoard/VerThree

The aim of the circuit is to allow a huge input amplitude voltage range for easy installation and support for VR type engine(or wheel) phase(which has RPM info of course) sensors.

Look at the [waveform generated from VR] type InputTrigger


History: the former inferior optocoupler circuit

GenBoard/VerTwo used the same optocouple based circuit that was used in motorola-megasquirt. Even though it went through several iterations in the ancestors, the circuit is not very good.

An input trigger needs:

The optocoupler could also provide total isolation, but it's not required, nor used here: the input and output GNDs are actually connected. Protection from input spikes is not a big deal, it can be solved with well sized resistors, caps and diodes, which are needed anyway.

GenBoard v3.0 early revisions (never manufactured) had 2 selectable solutions:

After comparisons, the optocoupler based circuit was dropped, since it cannot cope with the basic requirements: no hysteresis. Even though it definitely works with difficult installation and software filtering, but why not do better?. Read below.


The solution

So a professional solution with the LM1815 chip was implemented, which can handle any type of InputTrigger (although the resistor-values depend on type). 2 channels of them, of course.

After reading the datasheet and inspecting proven applications like

lm1815_circuit.jpg

We put 2 instances of a similar circuit on GenBoard/VerThree PCB.

The LM1815 is not very cheap:

But it's a very good and proven solution. Something similar is used in EDIS module for EDISIgnition (so those using EDIS will not need to use the LM1815 on GenBoard/VerThree).

The input amplitude range is amazing in any case: it can clamp upto +-3mA, the external resistos must be sized according to this (but never belive me, read datasheet).

That means that without the external voltage divider it can trigger on a 200mV .. 50V peak2peak signal. 200 mV is small enough: you can acquire it with a few turns around a HV wire.

I have a wire with 2*470k resistors in it, in series. I can plug into the wall which is in Europe 230V effective (+-400V peak) and trigger GenBoard/VerThree with it: 50Hz reads as 1500 RPM (at least for 4 cyl, since this depends on config).


High Voltage input: ignition transformer primary (not secondary!) side

LM1815 based VR circuit can be used for coil-setups (the wire going to the transformer primary of an alien ignition) too: it is recommended to use an external (or onboard) voltage divider with a 900..1000k (eg. made from 2*470k in series) and a 100k to GND. This divides the max 400V (rather 200V normally, when sparkplug is there on the secondary) peak2peak signal to about 36V peak2peak (1/11).

applications:


Triggering on falling edge not ideal for directly tapping transformer primary

Unfortunately the falling edge is triggered, but this is not very good: the rising edge would be much better, since there is only one rising edge, with significant amplitude. Normally there is a smaller and bigger falling edge, and the smaller wants to be neglected (and is in fact, due to the adaptive histeresys, but not ideal). Look at the textual scope snapshot for the why there are 2 falling edges:

Therefore some people feel more comfortable to wind a few turns around the coil wires (primary or secondary is better?) and trigger from there. A scope comes handy.


VR sensing without the LM1815 chip

This is only for the curious, since the LM1815 circuit is very nice and proven, and used all over the project, eg. there is 2 channels on GenBoard/VerThree PCB, 2 channels on InputTrigger/AudiTrigger (and on small round WideBand meter unit).

Earlier we tried smaller footprint OPA circuits with success (ask Dave), although we did not do very intensive tests.

A very simple basic comparator circuit built from OPA (with Schmitt-trigger histeresys input, any analog introduction books have the circuit example):

SignalConditioner.GIF


using with HALL sensor


Schmitt input helps or hurts

As irc discussion shows, this is kindof tricky for a HALL sensor.

  1. we set the threshold energy. We do that exactly the same way wether with Schmitt or without: with RC (values might slightly depend on input voltage-threshold level). Appr RC=5..22usec is acceptable and provides significant noise immunity. Too high RC causes unwanted delay that shifts the trigger angle (slightly) in function of RPM (can be corrected in sw in the worst case - if you tune your ignadv yourself this does not effect the result, just the exact absolute reading).
  2. if the threshold was reached by normal trigger pulse, it's fine
  3. If the treshold (that we set to our liking above ) was reached due to noise (interrupt flag has been set, a Schmitt would not clear the interrupt flag), we want the seen signal to return as fast as it can, so we can test in SW if we like, and neglect the interrupt. If the treshold we set is reached, interrupt is fired wether with Schmitt trigger or normal input: the Schmitt trigger just prevents detecting that it was a noise not a real pulse

Even though the Schmitt trigger makes things slightly worse for the trigger edge (by stopping possible improvements by SW), in practice (with reasonably set RC) the reasonable noise level is more than one amplitude lower than what would cause problem (and the need for more sophisticated sw filtering is not yet proven) .

I recommend an experiment:

The above experiment would show behaviour at the other edge (eg. rising edge, if only falling is configured to fire an interrupt).

If we see a problem, we might consider a mega88 or a tiny on v3.3. While it's much more expensive than a 74AHCT132PW, it merges InputTrigger/AudiTrigger (allows 135-1 type), and allows sampling both trigger-edges for even a 60-2 HALL-setup. (Both trigger-edges can be sampled for upto 36-1 with current HW without significant sw-mods).

Note that to support any argument, things have to be summarized. Irc does not make that possible, so irc is not suitable to support any but the most trivial arguments. In fact the lack of summarization can (and often does) stop you from finding any good support statement for what you feel is right (which can be right).

The ideal solution would be DSP-like analog processing of the trigger signal. Might be possible on the ARM, but not feasible on AVR.

See GenBoard/VerThree schematic


See also InputTrigger/AudiTrigger