ROI Trigger

[laborleben]

Test and if necessary fix ROI trigger:

• Testing acceptance delay between different trigger inputs and extend acceptance delay if required

• Check boolean logic (AND, OR) between trigger inputs (only AND is possible)

[YannickDieter]

I tested the trigger acceptance window. Trigger was generated using a function generator. The signal was split (blue and purple signal) using T-LEMO with different cable length in order to realize trigger distance of ~40 ns (see picture).

These trigger signals were connected to PM_IN 1 and PM_IN 0 and the trigger output was observed at TEST 0 and TEST 1. Depending on the trigger distance acceptance window (in units of 1.5625 ns) the trigger rate was measured (see picture). This shows that the acceptance window feature works, however the location of the s-curve seems to be a bit off, should be at 40 / 1.5625 ~ 25.

You can also see that both channels (green: TEST0, yellow: TEST1) are responding in case the window is large enough.

acceptance_window_test.pdf

[YannickDieter]

@laborleben @themperek The question is now if the maximum acceptance window of 31 * 1.5625 ns ~ 48 ns is enough or should it be increased? I never used the ROI feature (with FE-I4), thus I have no idea how much delay between HitOr and Scintillator is needed.

[DavidLP]

Without extra hit bus amplification and long LEMO cables 48 ns could be too short.

[themperek]

We can extend but this will add to latency.

[DavidLP]

Can we make it configurable? I think std. delay of 200 ns is good, since this is not a large latency for our pixel chips and we would loose < 1% of the events with Poisson distributed beam and 50 kHz:

dead-time = 1 - exp(- 200 ns * 50 kHz) = 0.01

Or (maybe even better), we choose the lantency of the old TLU firmware for compatibility.

[YannickDieter]

Coincidence of two scintillator inputs was tested at DESY Testbeam and it worked.