rusefi.com

Uses 2x VR sensors on flywheel + Cam-hall:
One VR keeps track of the starter ring for RPM/Position means (135 teeth) while the other senses an addition tooth ("HOME") analogous to a missing tooth trigger setup. Cam sensor is used for phase detection similar to typical fully sequential setups.
This trigger config is found on some early Bosch Motronic equipped engines such as Audi 3B, AAN, 2.2 ltr. turbo as well as some Porsche boxer-6 engines (starter ring teeth amount to be confirmed).

Fitting a newer OEM VAG 60-2 trigger is possible, but a PITA for most users.
https://rusefi.com/forum/viewtopic.php?f=2&t=1690&p=35956&hilit=Audi+trigger+135#p35956

By including this pattern, I recon more Audi 5-cyl users would be interested in the RusEFi plattform for their builds.
I have one candidate up for testing if this trigger would be implemented.

While many triggers are very easy to add, this specific one is not. In order to add this specific trigger some technical improvement of the trigger decoding layer would be needed https://github.com/rusefi/rusefi/issues/2182

Well, in the end we might have got lucky with this 1+135, looks like at the moment 140 tooth is the limit. There is a chance that it's done.

Awesome. Will this pattern be available upon next firmware release for testing?

tmbryhn wrote: ↑

Tue Jan 05, 2021 5:55 pm

Awesome. Will this pattern be available upon next firmware release for testing?

yes, that's how releases work. also available in "latest" build at https://rusefi.com/build_server/

No, it's too many teeth and overall should be done differently. https://github.com/rusefi/rusefi/commit/036c41ecbc2d6df58faa8d8fffb66580040b37a3

Something about merging two signals?! https://www.vems.hu/wiki/index.php?page=InputTrigger%2FAudiTrigger

yes, I think my post here (skip the first half) explains it decently: https://carpokes.com/viewtopic.php?t=2629

It requires dedicated hardware: the cam hall signal is used to "gate" the TDC signal, masking it off every other rotation. This is usually done by using the VR chip's gating input, or by OR-ing the open-drain outputs with another open drain buffer off the hall input. Since the Maxim VR chips don't have this input (LM1815 does), we need to use the latter.

Looking at the uaefi design, it seems easy to add in the proto area to the MAX VR chip. Discrete VR circuit is harder.

I've got a uaefi on order for testing, should be able to show my work then

as far as fw goes, it seems plausible to just do the n-tooth division (short-circuit every n-1 irqs) in shaft_callback - but I suspect this is a bad solution for a whole bunch of reasons (also probably best kept to the github discussions).