CAL retriggering study with SLAC data. Alexandre Chekhtman NRL/GMU

1. Gamma-ray Large Area Space Telescope CAL retriggering study with SLAC data. Alexandre Chekhtman NRL/GMU

2. Data used for analysis • Previous presentation was based on NRL data • Event time tag was assigned in the SBC – could contain significant error because of buffering delays • Now I analysed 2 nuon runs collected at SLAC: • Run 135001500: low FLE/FHE thresholds (3 steps above the noise level), 616011 events, 2500 seconds • Run 135002134: flight FLE/FHE thresholds (FLE=100 MeV, FHE=1 GeV), 462675 events, 5500 seconds • I used following time parameters: • GemTriggerTime: 20 MHz counter which rolls over at 225 (every 1.6 seconds) • I add 225 every time the parameter goes back to zero, so I get the trigger time in 20 MHz ticks, increasing monotonically from the beginning to the end of run • GemDeltaEventTime: 20 MHz counter giving the time between the current trigger and the previous one.

3. Time from previous event • Run 135001500 – low thresholds • Huge peak at GemDeltaEventTime < 200 µs • Run 135002134 – flight thresholds • pure exponential distribution

4. Time from previous event - zoomed • Run 135001500 (low thresholds) • Peak of retriggered events is between dead time (26 μs) and 200 μs • This is the period of event data transmission from TEM to GASU • Run 135002134 (flight thresholds) • No retriggering • Exponential distribution goes down to dead time (26 μs)

5. Trigger bits • Run 135001500 (low thresholds) • >300K events have GemConditionsWord=12: • Cal_LO and Cal_HI, no Tkr • Run 135002134 (flight thresholds) • almost all events have GemConditionsWord=2: • Tkr, no Cal_Hi, no Cal_LO

6. Trigger bits for muons and retriggered events • Run 135001500, retriggered events (GemDeltaEventTime<4000 ticks) • Almost all retriggered events have GemConditionsWord=12: • Cal_LO and Cal_HI, no Tkr • Run 135001500, muon events (GemDeltaEventTime>4000 ticks) • Most part of events have GemConditionsWord=2: • Tkr, no Cal_Hi, no Cal_LO

7. Time from previous event – “fine structure” • Run 135001500 (low thresholds) • The distribution of GemDeltaEventTime for retriggered events contains narrow and high peaks with distance between peaks = 132 ticks • This time period corresponds to the transfer of one “data cell” when sending event data from TEM to GASU (see LAT Inter-module communication document, page 15-17) • This fine structure confirms that the retriggering is caused by crosstalk noise produced by TEM->GASU data transfer

8. No fine structure, if retriggered event follows muon event Both plots for run 135001500 with low thresholds • Retriggered event after another retriggered event • Fine structure • Explaination: retriggered events are synchronized with the transfer of data cells • Time between two retriggered events with big probability is equal to multiple of 132 ticks • Retriggered event after muon event • No fine structure (almost) • Data transfer is not synchronized with muon event, except the case when TEM FIFO is empty • Time between muon event and retriggered event could have any value

9. Periodic event rate variations • Run 135001500 (low thresholds) • GemTriggerTime histogram (with bin=10 seconds) shows significant variations with regular pattern and the period ~500 seconds • Run 135002134 (flight thresholds) • GemTriggerTime histogram (with bin=20 seconds) is flat

10. Isn’t it a software bug ? • Run 135001500 (low thresholds) • Histogram plotted by ROOT using SVAC ntuple variable GemTriggerTime • Run 135001500 (low thresholds) • Histogram plotted by IDL using ldf file, read in by Byron’s IDL reader • Only first 150K events are on the plot • Picture is identical to the first period of the left plot • Results obtained from 2 different software tools are identical – it cannot be a software bug

11. Correlation with event number • To verify, if the rate variations are correlated with event number, the following procedure was used • Events with event numbers from 0 to (219 -1) = 524287 were split into 1024 groups (bins) containing 512 events each: • 0-511, 512-1024, 1024-1536, … , 523776-524287 • For each bin I calculated the time dt required to generate its 512 events by subtracting GemTriggerTime of the first event of this bin from GemTriggerTime of the first event of next bin: • Dt[0] = GemTriggerTime(event=512)-GemTriggerTime(event=0) • Dt[1] = GemTriggerTime(event=1024)-GemTriggerTime(event=512) • . . . . . . . . . . . . . • Dt(1023) = GemTriggerTime(event=524288)-GemTriggerTime(event=523776) • total event rate is calculated for each bin as: • Rate[i]=512/Dt[i] • For each bin I calculate: • number of muon events Nmu[i], satisfying the condition GemDeltaEventTime>4000ticks (>200 μs) • number of retriggered events Nrtg[i], satisfying the condition GemDeltaEventTime<4000 ticks (<200 μs) • The rates of muon events and retriggered events are calculated for each bin: • muRate[i]=Nmu[i]/Dt[i] • rtgRate[i]=Nrtg[i]/Dt[i]

12. Time per bin and the number of retriggered events per bin vs event number • Run 135001500 (low thresholds) • Time per 512 triggers as a function of event number divided by 217 = 131072 • There are points with very small time ~20-50 ms per 512 events, corresponding to multiple of 0.5 • There are visible “bands” of points • Run 135001500 (low thresholds) • Points at multiple of 0.5 corresponds to (almost) all 512 in the bin being retriggered events • Similar to left plot, there is “band” structure

13. What is magic number 131072 ? • The event number in the TEM contribution to the event data contains 17 bits: 15 bits in Event ID plus 2 bits in the Event sequence number • I suspect that the “band structure” on the previous slide is related the number of bits set in the higher byte of the Event ID • To verify this I calculate the number of bits set to 1 in higher byte of event number for each group of 512 events – shown on the plot below

14. Rate of retriggered events for different number of bits set to 1 • Rate of retriggered events strongly correlated with number of bits set to 1 in the higher byte of event ID • In addition to that there is slow decreasing of rate at constant number of bits within a period • another factor ?

15. Rate of muon events is constant ! • The rate of muon events from the same run is shown below – it has no variation with event number • The points with big error bars correspond to the bins with very few ( or no) muons due to very high retriggering rate.

16. Discussion • Event ID is a part of TEM contribution to event data which is transferred to from TEM to GASU • The noise being produced during this data transfer process causes the calorimeter retriggering when trigger thresholds are sufficiently low • Probability of retriggering increases when there are more data bits set to 1 in the event number • Could other data bits in the TEM contribution (adc’s etc) also produce retriggering ? • What will happen when number of towers will be bigger and the data transfer rate will be higher ? Could this lead to the retriggering at higher thresholds ?

17. Possible tests • As proposed at the trigger meeting, we could try to repeat the data collection with low thresholds, but disable the data transfer of the TEM contributions to the GASU • In this case we could expect the the retriggering will disappear • Lets try to the test with different FLE/FHE thresholds (5,10,20,50 MeV) to find where the retriggering stops • We could try to the charge injection with self triggering and with auto ranging OFF, to readout saturated LEX8 range for all crystals( containing many bits set to 1 • will it produce high retriggering rate ?

18. Conclusion • Calorimeter retriggering at low FLE/FHE threshold is caused by crosstalk noise produced by the data transfer from TEM to GASU • There is unexpected correlation of retriggering rate with event ID • For flight setting this effect hasn’t been found so far • Additional tests are needed to estimate the potential danger of this effect for complete LAT working at high event rate.