This is going to be a bit odd, but I will put it out there. Convert each of the four signals into a TTL events. You then setup an matrix such that each row column intersection is a high speed binary counter that starts when one of its inputs goes high and stops when its other input goes high. The uC then reads in each of the binary counters to determine the exact time comparisons after a predetermined about of time (single interrupt). So if you have sensors A, B, C, D at locations 0, 90, 180, and 270, you would compare A-B, C-A, A-D, B-C, D-C. This would give you all the positional data you need provided you can achieve a high speed and reliable circuit. You would setup a 8 bit flip flop circuit with a high speed clock as your triggers. The first signal enables the clock and the second signal holds it so that you can read in the state of the binary counters (8 flip flops per comparison circuit). That uC could be a simple Arduino and you read in each flip flop like you would memory addresses. Once you complete, you finish the hold signal to complete the reset.
Off my rocker?
Thanks,
Frank
That’s the basic idea in using the onboard timers but so far as I can tell the timers in AVRs don’t work as needed, at least not any better than using ext interrupt pins and getting a timestamp via an ISR. Timers in PICs work differently and can time a pulse directly. See the description for Timer1 (Fig 4-6).
http://www.mikroe.com/chapters/view/5/
According to PJRC using the ext interrupt pins (not pin change) on a 32U4 the latency can be under 5 usec … perhaps that’s good enough, with a tweak to check for “simultaneous” interrupts ??
http://www.pjrc.com/teensy/td_libs_Encoder.html
Mee_n_Mac:
That’s the basic idea in using the onboard timers but so far as I can tell the timers in AVRs don’t work as needed, at least not any better than using ext interrupt pins and getting a timestamp via an ISR. Timers in PICs work differently and can time a pulse directly. See the description for Timer1 (Fig 4-6).
http://www.mikroe.com/chapters/view/5/
According to PJRC using the ext interrupt pins (not pin change) on a 32U4 the latency can be under 5 usec … perhaps that’s good enough, with a tweak to check for “simultaneous” interrupts ??
http://www.pjrc.com/teensy/td_libs_Encoder.html
Holy blast from the past on PJRC. I own one of his displays: http://www.pjrc.com/store/mp3_display.html
Musing on how a system using a PIC w/2 such (as above) timers might work …
You’d set the timers to zero and enable the gate control pins. Keeping with the 4 detector scheme, one timer/2 detectors does vertical off-center timing, the other horizontal, in all other respects the 2 channels are identical. When either of the detectors … ummm, detects, it generates a pulse to the PIC gate control pin. The timer then counts up from zero. When the other detector detects it resets the pulse, thereby stopping the timer and (IIRC) generating an interrupt. The ISR can leisurely fetch the timer reading for the distance calcs and make ready for the next shot. If the pulse is so short (“simultaneous” detections) that the timer doesn’t increment, that’s a dead center (along that axis) hit. If the ISRs overlap, so what … the times are already frozen and will remain until read (or the next shot).
The conditioning circuitry must do a few tasks;
-
digitize the analog detector signal
-
generate or reset the above pulse
-
do the previously mentioned 1 shot function so there’s only 1 pulse per hit despite the msec long analog signal
-
output some digital indication of which detector (of the pair) went off 1’st so up/down, right/left can be known by the PIC
Whether this approach is any easier for the OP, or necessary, is ???
I still have concerns over basic piezo equipment being reliable. I still think that bolt on knock sensors would be best.