A.Chekhtman1 GLAST LAT ProjectInstrument Analysis meeting, June, 24, 2005 CAL retriggering study with SLAC data. Alexandre Chekhtman NRL/GMU Gamma-ray Large Area Space Telescope

A.Chekhtman2 GLAST LAT ProjectInstrument Analysis meeting, June, 24, 2005 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 : low FLE/FHE thresholds (3 steps above the noise level), events, 2500 seconds –Run : flight FLE/FHE thresholds (FLE=100 MeV, FHE=1 GeV), events, 5500 seconds I used following time parameters: –GemTriggerTime: 20 MHz counter which rolls over at 2 25 (every 1.6 seconds) I add 2 25 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.

A.Chekhtman3 GLAST LAT ProjectInstrument Analysis meeting, June, 24, 2005 Time from previous event Run – low thresholds –Huge peak at GemDeltaEventTime < 200 µs Run – flight thresholds – pure exponential distribution

A.Chekhtman4 GLAST LAT ProjectInstrument Analysis meeting, June, 24, 2005 Time from previous event - zoomed Run (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 (flight thresholds) –No retriggering –Exponential distribution goes down to dead time (26 μs)

A.Chekhtman5 GLAST LAT ProjectInstrument Analysis meeting, June, 24, 2005 Trigger bits Run (low thresholds) –>300K events have GemConditionsWord=12: Cal_LO and Cal_HI, no Tkr Run (flight thresholds) –almost all events have GemConditionsWord=2: Tkr, no Cal_Hi, no Cal_LO

A.Chekhtman6 GLAST LAT ProjectInstrument Analysis meeting, June, 24, 2005 Trigger bits for muons and retriggered events Run , retriggered events (GemDeltaEventTime<4000 ticks) –Almost all retriggered events have GemConditionsWord=12: Cal_LO and Cal_HI, no Tkr Run , muon events (GemDeltaEventTime>4000 ticks) –Most part of events have GemConditionsWord=2: Tkr, no Cal_Hi, no Cal_LO

A.Chekhtman7 GLAST LAT ProjectInstrument Analysis meeting, June, 24, 2005 Time from previous event – “fine structure” Run (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

A.Chekhtman8 GLAST LAT ProjectInstrument Analysis meeting, June, 24, 2005 No fine structure, if retriggered event follows muon event –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 Both plots for run with low thresholds

A.Chekhtman9 GLAST LAT ProjectInstrument Analysis meeting, June, 24, 2005 Periodic event rate variations Run (low thresholds) –GemTriggerTime histogram (with bin=10 seconds) shows significant variations with regular pattern and the period ~500 seconds Run (flight thresholds) –GemTriggerTime histogram (with bin=20 seconds) is flat

A.Chekhtman10 GLAST LAT ProjectInstrument Analysis meeting, June, 24, 2005 Isn’t it a software bug ? Run (low thresholds) –Histogram plotted by ROOT using SVAC ntuple variable GemTriggerTime Run (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

A.Chekhtman11 GLAST LAT ProjectInstrument Analysis meeting, June, 24, 2005 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 ( ) = were split into 1024 groups (bins) containing 512 events each: 0-511, , , …, –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]

A.Chekhtman12 GLAST LAT ProjectInstrument Analysis meeting, June, 24, 2005 Time per bin and the number of retriggered events per bin vs event number Run (low thresholds) –Time per 512 triggers as a function of event number divided by 2 17 = –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 (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

A.Chekhtman13 GLAST LAT ProjectInstrument Analysis meeting, June, 24, 2005 What is magic number ? 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

A.Chekhtman14 GLAST LAT ProjectInstrument Analysis meeting, June, 24, 2005 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 ?

A.Chekhtman15 GLAST LAT ProjectInstrument Analysis meeting, June, 24, 2005 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.

A.Chekhtman16 GLAST LAT ProjectInstrument Analysis meeting, June, 24, 2005 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 ?

A.Chekhtman17 GLAST LAT ProjectInstrument Analysis meeting, June, 24, 2005 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 ?

A.Chekhtman18 GLAST LAT ProjectInstrument Analysis meeting, June, 24, 2005 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.