----

Schmitt input helps or hurts

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

# 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).

# if the threshold was reached by normal trigger pulse, it's fine

# 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:

* self stim from an unused (config.act_wot_channel=)S259.. pin to trigger1 (or a stimulator if you like, but the self-stim is perfect for this)

* use the mst3f msp7a (msq..) command for a slowish trigger: coil-type, nx100 RPM

* make a long dual-wire: close to each other

** one is the trigger

** other is ignition transformer primary. A real ignition transformer should be used, with realistic size sparkgap on the secondary side. This is the worst signal in the system the trigger can see around (be coupled with).

** alternatively noise can be injected from a 50..60Hz (eg. from a 9V AC wall transformer; or other signal) with a voltage divider

* on the sending side (at S259 output) use a low frequency lowpass filter to simulate a slow HALL-edge. Anything below 1000Hz is unrealistic (but can be tried as experiment) because that slow rise would cut the HALL signal at 6000 RPM. Appr. 1000Hz cutoff freq provides the worst case realistic signal-slew-rate. That causes several degrees of ignition error at 6000RPM (6000RPM=200Hz trigger signal: 1000Hz means appr. signal rise time of 15..18 crankdegrees). Normally the falling edge from a HALL sensor slew-rate is like that of a 30..100kHz signal, but the rising edge is slower, as of an appr. 8..50 kHz signal.

* use the standard RC filter (10k and 2.2nF) on the receiving side (trigger1 end of the long wire)

* use mde40 and capture the binary timestamps in TerminalProgram as on InputTrigger/TriggerLog

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.