InputTrigger/NissanTrigger (2011-08-05 21:32:41)

For the Nissan CAS trigger (360 pulses) 3 possible solutions (one working, one should be easy and one hard)

Current solution is a 24+1 slot trigger wheel as described here: VehicleFitment/Nissan

We have a number of cars running on these trigger disks.


Leaving the 360 impulse disk - we can also implement this after someone writes exact pattern info here (in place of the "..." below) - from a reliable source or measurement.

Fill in this form (and correct if necessary): signal is normally 0V (according to patent FIG.3 at least), but 5V in the small slots:

THANX !

Best I can do right now (Gunni)

Download this

http://downloads.picotech.com/winxp/PicoScope6Automotive_r6_5_78.exe

Then open this file

http://www.megaupload.com/?d=SJVJBNIK

It´s a SR20DET 1997 engine captured trigger input

Should be easily viewable in the Picoscope program.


Geek notes

A hardware divby4 divider can help. We have divby4 / 8 implemented with HCF4024 circuit (under PCB manufacturing, originally for high toothcount ABS wheels). Since this circuit has (active-high) reset input, this can be useful to make a precise 180, 90 or 45 pulsetrain from the 360 tooth.

It explains the syncing methods used by nissan, hope it helps.
  • because the sync pulse is mostly 0 (and high for only a short time), the active-high reset input of the HCF4024 seems suitable
  • is the sync pulse falling edge not racing with (the rising or falling edge of) one of the 360 pulses ? (I assume not, because that would be very stupid. This would make a counter-type implementation impossible, but a helper "assistant CPU" could still help)
  • configuring sectrig input=both edges and firmware modification is necessary with the 4-window sync pulsetrain
  • by blocking 3 of the 4 windows, (and using a HW divider) firmware mod would not be needed (good for experiments, but this should not be needed finally)

Besides any necessary HW, suitable config will be provided (configlet to be able to upload to suitable firmware with 1 click).


Alternative solution would be (without HW divider) a software divide by the main processor. The processor is definitely capable (up to at least 17000 RPM). But unfortunately we have some tasks in interrupt that would need to be rewritten. (not the trigger input capture interrupt, but other interrupts that could interfere).

From auditrigger bench experiments that worked at 11000 RPM (pulse=2.66 crankdeg), we know that 8300 RPM (pulse=2 crankdeg) is possible without major rewrite. Going above the "all pulse always sensed" threshold could delay ignition by 1 tooth (2 crankdeg) or more (not advance that could blow engine). We speculated that without HW divider going above 9300 RPM could be too much work that would delay other developments unacceptably. So we will only implement fw mod that works well with HW divider.


See also