Tooth skipping hardware

[rusefillc]

OEM trigger wheel generates 360 signals on the second channel. We cannot afford to get this flow of interrupts into rusEFI firmware we need some solution to skip teeth on the hardware layer or else.

ideally the skipping subsustem would have a 'reset' pin so that we can sync skipping layer once we sync on the primary trigger channel

[rusefillc]

@mck1117 I assume we need reset feature for trigger sync?

[blundar]

The main issue that I see is that a pure logic gate divider could essentially start "0" from a different position each time, determined by where the motor stopped last time / where it started this time. The "cam" sensor isn't going to change position, ever. In addition to providing cam position, the edges of the cam sensor could be used as the sync/zero signal. If this could be done and the "crank" 360 / 10 wheel was used purely to calculate engine SPEED without using the teeth for actual timing, this could work. i.e. 1a. start counting period between divided teeth (360/x) 1b. wait for a cam tooth 2a. keep trace of period between divided teeth 2b. set zero/index on edge of cam tooth "0" 3a. update period between divided teeth 3b. use edge index + period to time events If the 36 "tooth" output of the divided sensor was actually used for timing, it could get really hairy because "0" on the divided wheel could move randomly from start to start because even wheel that can start triggering anywhere in rotation, not just in multiples of 10. Another possible logic-solution would be to use a flip flop, AND gate to hold the counter/divider in reset until a cam pulse happens. This would ensure that the counter starts counting on the edge of a cam pulse, so it would always be at the same spot, but I'm not sure how this would work with the multiple "cam" teeth and if I remember right their variable widths.

…

-Dave

On Tue, Jul 27, 2021 at 3:51 PM rusefillc ***@***.***> wrote: @mck1117 <https://github.com/mck1117> I assume we need reset feature for trigger sync? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPY3CTXX54FSC4JGUT5IU3TZ4E5XANCNFSM5BCUIDAQ> .

[mck1117]

why not just have a divide by N (where N is a power of 2) done with flip flops, and the reset input wired to the second channel?

[mck1117]

We can handle this thing outputting some strange pattern, so long as the strange pattern doesn't have any close-together edges, and so long as its predictable on every rev of the sensor.