TDC 32 microsec Window Occupancy (Draft)

R. J. Wilkes, rev 7/6/96

At the LSU meeting, we discussed possible reduction of the current 32 microsec time window for TDC data. While cutting the time window by a factor of 2 or 4 would not significantly affect the data volume, it could help, and there may be no good reason to keep the full 32 usec in any case. There was concern that the long open window time might cause the limited edge-buffer capacity to be overrun for some channels, especially those used to record TRG pulses.
In this study, files from the express directory for runs 2015, 2051, 2055 and 2065 were used. The files used had a total of 2311 events with good OD data.

1. "How often does a channel contain 8 hits (ie, 16 edges)?"

In other words, since the TDC capacity is 16 edges/channel, and each hit provides 2 edges, how often is there a potential data loss due to the edge buffer being filled? Figure 1 is a histogram of N_hits/event/channel (the lower plot shows the same data on a log scale), with bin 0 containing the number of events in the sample (2311). Bin 8 contains 2377 entries, showing that on average about 1 channel per event is filled (or overflowed).
For the TDC channel used to record TRG pulses (chan 91 in module 17 in each hut), there is special concern that we may lose trigger time data. Fig. 1b shows the corresponding distribution for these channels: a negligible number are lost. Presumably, the TRG-channel issue will become totally moot when we upgrade to the new front-end boards, which will send only one edge/TRG to the TDC instead of both.
2. "How are the significant data hits distributed in the 32 usec window?"

In other words, what smaller window, if any, would contain an acceptable fraction of all useful hits. This cannot be accurately answered without comparing identified good events with raw data files, but a simple estimation can be made from the raw data alone. One expects a uniformly distributed background (in time) of noise hits, with clusters of event hits around the trigger time. Figures 2 and 3 show the leading-edge arrival times, with the upper histogram showing the full 32 usec window, and the lower histogram showing a closeup of the time region around t=0 (the trigger time, which is shifted to the center of the TDC window by the STOP delay). As can be seen in Fig. 2 ("Hit Arrival Time"), there is a clear and overwhelming peak at the center of the window, only about 1 usec wide. Notice the peak has an appropriate delay representing the TRG delay plus the QTC delay. This plot is for all hits in all good channels over the sample of 2311 events.
For the TDC channel hits, the corresponding plot is shown in Fig. 2b. Next, Fig. 3 shows the same plot as Fig. 2, but for hits with the vladibit on. This demonstrates the reduction in noise data obtained using the moving window clustering algorithm: notice the reduction in height of the uniform background relative to the preceding figures,with negligible effect on the data peak. Evaluation of the safety of the vladibit awaits completion of a separate detailed study (Stachyra).
3. "Are a few hot channels responsible for most of the full buffers?"

As Fig. 4("Channels with N_hits=8") shows, this is not the case. Except for a few apparent hot tubes (all in run 2015, by the way), the full buffers seem uniformly distributed over the range of OD tubes. The lower plot shows the distribution of the number of events (in the sample of 2311) when a given channel has a full buffer. Most channels get filled once in a while, only one or two are filled in more than 1% of the events.
4. "How are the hit times distributed in the window for channels with full buffers?"
   Fig. 5 shows the leading-edge arrival times for channels with 8 hits in a given event. The bottom plot shows all 8 hits for all channels, all events. The top pot shows the arrival times of hit 1 (first out, = last in), the next plot shows the arrival times for hit 8 (last in = first out), and the third plot shows the distribution for the next-to-last hit. The secondary peak at 12 usec in the 3rd plot may be due to mis-sorted hits. The Table shows an ntuple containing the eight hit times (across the page) for the first 50 full buffers (down the page). Note that occasionally the 8th hit is earlier than the preceding hits. Is this merely a harmless quirk of the sorter, or does it indicate a bug in the sorter (ie the 8th entry is sometimes actually the first of the next channel)?
   Fig. 6 shows the arrival-time distribution for the 8th hit/chan/evt for laser flashes. This indicates that for laser data there is a serious overflow problem, which would be reduced for a window extending only to +12 usec. J. Flanagan attributes these numerous late pulses to afterpulsing. Kearns mentions that afterpulses as late as 16 usec were seen in MACRO. To check if the same behavior is seen in hot tubes in real data, Flanagan also looked at muon entry points. He found that indeed, at least on an anecdotal basis, the hottest tube has its first few pulses lost due to buffer overflows. This supports the idea of reducing window size in the forward direction from 16 to 12 (or fewer) usec.

NOTE: Many thanks to John Flanagan and Ed Kearns for help with this report. Errors and false conclusions herein are solely my responsibility.