Scintillator Group Reporting:
Lori Gray, Erik Katsavounidis, Ioannis Katsavounidis,
Sophia Kyriazopoulou, Massimo Orsini, Paolo Saggese, Stefano Stalio,
and Bob Webb
Editorial Note:
During my two week shift we did not hold a formal group meeting
in order to put together this report. Instead, I have assembled a
collection of e-mail reports from the scintillator group members to
make this report. I want to apologize in advance for any work going
on at the lab that is not reported here, since several of the MACRO
troops were on vacation at the end of my shift.
Overall the detector ran smoothly during this period. The biggest
hardware problem faced during this period was recovery from a "half hour"
power outage on Wednesday the 23rd. During this outage 2/3 of the
detector had to be turned completely off to insure that the UPS would
be able to keep the working 1/3 of the detector alive during the outage.
This outage made it impossible to complete the necessary calibrations
for this week.
=====================
Lori Gray reports the following work being done on the Lamosska trigger
and other related scintillator studies:
During the past two weeks I have been working on four different
"projects".
1) I, with the help of others, have been debugging the wfds that
have presented themselves as "sick" in the recalibration runs
that I performed after "the fix". More often than not, however,
the problems are actually not associated with the wfd card. In
debugging these wfds we found (or rather reconfirmed) three
serious base problems (1b09-00,2w01-0,2w05-0); three switchbox
problems (resulting in dead pmts) (1t11-0,2t05-0,4c03-0); one
"super pmt" which is as of yet not understood (2c15-0); and there
are several candidate switchbox/gain problems in supermodule 6
which will be checked on this coming Wednesday. In terms of
wfd cards I saw serious problems with 6w09-0 and 6w13-0 (2 inputs
of the same card) which, combined with the pedestal problems
evident in normal data resulted in the card being replaced with
a spare last Wednesday.
2) I have also been running lamosska calibrations. The first
objective was to ensure that the lamosska trigger was working
in general. As you saw, we found that the lamosska trigger
was not working for the entire supermodule 1. After debugging
this problem, the calibrations demonstrated that lamosska was
finally functioning properly for supermodule 1. The second
objective is to check the threshold of the lamosska trigger, and
see that it is rather consistent throughout the detector. I
have up until now been using pulses with a width of 30us, and
I found that it was very difficult to see a threshold. It turns
out that this is due to the fact that the lamosska circuitry
integrates only a portion of the pulse and this seems to depend
greatly on the actual shape of the pulse. So on Wednesday I
performed a lamosska calibration using 10us width pulses, in the
hope that for this case the lamosska circuit will integrate the
entire pulse and I will be able to determine clearly the actual
threshold of the lamosska trigger, and therefore be able to clearly
identify those channels which have a problem. In the past, I
found channels which I thought should have triggered lamosska but
didn't, and in the process of debugging them we found that
lamosska only integrated approximately the first 10us of the
30us pulse, so for two channels which received the same charge in
a 30us pulse one may trigger and the other not depending on the
shape of the pulse (ie. how much charge was contained in the
first part of the pulse).
3) I also spent some time this week on understanding how best
to optimize calibrations, ie. in understanding how much time is
spent talking to the pulser, how much time is spent in setup of
the operation, and what is the effect on dead time when multiple
waveforms are read out simultaneously. This work was basically in
response to questions raised by Doug. My conclusions are as follows:
Average time required to set the pulser settings: ~5.00 sec
(determined from log files, the actual values range from 4.75-5.95)
Average time to turn on or off the pulser: ~1.99 sec
(determined by the difference in duration of runs 90688 and 90687)
Effect of multiple readout on dead time:
30us pulses: 2 largest waveforms/readout : dead time = 13.57%
30us pulses: 8 largest waveforms/readout : dead time = 47.15%
10us pulses: 8 larger waveforms/readout : dead time = 39.55%
1us pulses: 8 large waveforms/readout : dead time = 17.25%
Time needed for setup: Too Much!
As should always be expected, unexpected problems are the largest
factor in the time required to do the calibrations. Between runs
90689 and 90693, an entire hour was spent trying to understand why
everything suddenly stopped working. It turned out to be caused by
the fact that someone had turned off uvax 1.
4) I have also been working on producing a routine which runs on
normal data to monitor the wfds. After seeing the wfd results
for switchbox problems I am incorporating a check for this (ie.
average charge seen by one end of a horizontal approximately
twice the that of the other end).
======================
Erik Katsavounidis did manage to get away for a short vacation during my
shift, however before leaving he had the following activities to report:
1) For quite some time Lori has been telling us about SM1 Lamosska
Calibrations that were not giving data. On July 16, we (LG, BW,
EK) had the chance to debug the problem. There must have been a number
of problems, some of which disappeared while we're wiggling cables or
changing delay times. The problem that was certainly there and our fix
had to do with the width of the STOP signal that was sent to the WFDs
in SM1. Initially it must have been too narrow for the WFD STOP signal
fanout to handle (~50ns). We increased it (and the one for SM2 too) to
100ns and it now works.
Whenever a chance is given to check the Lamosska circuitry in the
rest of the detector, please make sure you check the width of the
signal coming out of the delay units used by Lamosska. If they're
less than 100ns, please increase it to this value.
My guess is that Lamosska in SM1 was actually not functioning properly
for real data until now. A careful look at the data collected so far
may reveal this.
2) I also replaced the S/H servicing 5B01-5B04. I verified that the
previous card was NOT trigerring at all for 5B03. I also verified that
all four channels of the new S/H card are working OK and that TDC/ADC
values of identical pulses between all channels gave the same results.
First MACRO run after replacement: 14320
3) There were several surprises waiting for us when we restarted the
detector after calibrations on the 14th: the SM6 stop master was no-q'ing
all the time. I had the chance to look at the stop signals coming out of SM5
STOP MASTER and getting into the SM6 one (and vice versa). That's a rather
known pathology of this module.. This time, using the scope, I verified
that the flakiness behind this problem comes from the STOP OUT (top) of
the SM5 STOP MASTER (cable and SM6 input is ok). As a temporary fix,
I used a "T" out of the second SM5 STOP MASTER WFD stop output and
everything returned to normal.
Sounds like a next-Wednesday item though: if someone could unplug SM5
stop master and check what's wrong with the top STOP output. Could be
the TTL-->ECL-->NIM logic or the lemo connector itself.
4) I've inserted the decoding of all Lamosska events under a separate file
in the standard LGB area. Look for LAMO_RUNxxxxx.PROB
The equip37 decoding listed there might be unreliable at this moment.
====================
Ioannis Katsavounidis reported on the following activities:
CALMOD calibration constants
============================
A more extensive e-mail follows regarding the specifics of the update of
the official CALMOD DB with the (corrected) constants from the "work" DB.
Other issues related to the calibration constants are
(i) Shorter vertical 8th counters; Paolo and I did the measurements that
verified that these counters are indeed 20cm shorter. Some people know
about it (like Doug), some people didn't (like Alice) but nobody could
remember exactly how much shorter they are. But, CALMOD didn't "know" about
it at all - and that introduced an offset in calculating the TDC position.
I have prepared a .KUMAC file to correct the positions/lengths of these
12 counters. So far, I have not reached to a conclusion about the effect
of this error on calibrations and analyses, even though I expect it to be
very small, given the small acceptance of these vertical counters.
(ii) Other problems related to calibrations; namely, the "inefficiency"
of the attico verticals w.r.t. the lower vertical counters. In looking at
the muon events that survive the CALMOD cuts, the calibration code hardly ever
finds *any* muon going through the center of the attico vertical 8th, 9th
and sometimes 10th counters for SM#1,2,3,4,5, while for SM6 there seems to
be no problem. On the other hand, ERP-muon triggers for these boxes are
almost identical with those for the other vertical tanks, which have no
such problem. What makes the calibration code discard those erp-muons ?
Is it (a) lack of sufficient streamer-tube info (e.g. 4 instead of 5
planes hit) or (b) inconsistency in the position ? Could it (c) just be
a matter of acceptance ? I'm planning to go into the calibration code to
find out whether (a) or (b) applies - people who do analyses should tell
me whether (c) holds or not.
As it turns out, the MACROCAL account (where all the CALMOD constant DB
live) ran out of quota while I was updating the official DB... That means
the update I promised in my report can not be performed now; it will have
to wait for Monday or when I come back.
DARK-BOX LED TEST
=================
The setup is ready; the first test (saving the WFD data in ASCII format)
has been completed, but nobody has looked at the data yet. In the meantime,
Chris Orth has made the necessary modifications to the Command Line Interface
and his analysis code (DASH++) in order to save and process these WFD/LED data
in a fashion very similar to the standard MACRO WFD buffers. This way,
people can process the data we collect *much* more easy than with the ASCII
data. While I'm on vacations, I'll ask Stefano and Chris to work together
in getting and analyzing data in order to obtain some solid answers on
whether there is instability in the LED system, where it comes from and
how we can fix it.
BAD SPLITTER BOXES/CONNECTIONS
==============================
As was witnessed these last 2 Wednesdays, we found and fixed a number
of horizontal counters that were operating with only 1 of the 2 PMTs on
one of the two sides. Lori Gray initiated this search, when she discovered
counters producing more charge on the opposite side from where she was
firing the LED. Having fixed so far 3 of them, and having discovered another
3 (Lori has a list of them that she's gonna mail to everybody in order to
give it top priority next Wed), we realized that this may be a serious
problem for MACRO. Just consider that Lori's calibrations can only probe
the PMT/base close to the LED that we are firing. So, we are only testing
50% of horizontal-counter PMTs this way... Assuming statistical independence
for PMTs that have a bad splitter connected to them, there must be another
6 horizontal counters with the same problem which are far from the LED that
is firing. At any rate, even if not all of these cases end up being bad
splitter boxes, Lori's observations may lead us to PMTs that have lost gain
or have a higher gain, just as she has already led us to PMTs with base
problems.
Along the same lines, the information in the CALMOD database (and more
specifically the "Small signal gain" under the ERP section) can help us
significantly identify problems of this kind. I have already shown to
Lori how this can be done and I also think this check should be part
of the regular weekly calibrations. All you do is check the ratio
between these ADC gains for sides 0 and 1. They should be close to 1.
For all the cases that we found and fixed so far, this ratio is closer
to 2 (...)
Note: in the future, when such operations take place we need to notify
PISA immediately in order to avoid problems with the acquisition
(crazy rates) like the one that followed the fix of 4C03-0...
LASER CALIBRATIONS
==================
Another item that took a big chunk of time last Wed. was the problem of
the laser calibrations on uVAX#2. I have already sent a report on this
issue, so I would just like to emphasize how important is to do the
laser calibrations next Wed. on uVAX#2 and see if we really fixed anything
or not. I'm pretty confident, although, that at least the problem of the
laser-lower fakebox for SM3 is fixed. In the same spirit, the problems
of laser calibrations with the rest of the detector need to be addressed.
Of course, we still do not process the laser data in order to obtain
ADC pedestals and TIME-WALK corrections, but once the quality of the
data improves, I will invite Jim Musser to have a look at them and decide
whether we can use them or not. We may as well decide to write a different
piece of software that processes the laser data, as suggested by Doug.
Broken WFD channel
==================
Channel 26 on SM6 (6W09-0, 6W11-0 and 6W13-0) was swapped out with the
working spare. The problem observed on this card was that two of its
inputs (6W09-0 and 6W13-0) had a significant pedestal oscillation and
also during Lori's big charge calibrations registered pulses of 50usec,
even though the pulser setting was at 30usec. The entire WFD card (chs.
24,25,26 and 27) was swapped with a calibrated spare one. Since then,
the warnings for this channel disappeared from Ed Kearns' WFD-check log
files.
LeCroy broken card fixed - 2 more to go
=======================================
We(IK and BW) had a chance to fix one of the spare LeCroy HV cards -
this card had a channel that was supplying a voltage lower than that
requested. This gives us three working spares at this time. In addition,
BW looked at the remaining two broken HV cards and noted the problems that
each was experiencing for future repair.
======================
Massimo Orsini reports on the following activities over the past two weeks:
For the past two weeks I have been trying to fix some broken Pisa power
supplies and I found out that the most frequent cause for breakdown
is a driver transistor ( BUZ 84 ) which doesn't work properly.
I tried to replace the old BUZ 84 with other drivers ( BUZ 332 ) and for
two days, I have been testing the Pisa power supply under full load. These
repaired supplies seem to work better with these two different drivers.
The question is: Do we have to add the fix to the other broken Pisa power
supplies by using the BUZ 332 instead of BUZ 84 ( the original ones )???
Next Monday I'm going to discuss about this issue with Stefano Stalio and
Roberto Pazzi who will be on shift here next week.
=======================
Paolo Saggese passed the following items along for this report:
1) On Wednesday the 16th, we did try to debug the HIPT problem on SM 5/6.
We have used a pulser and an extra fanout to "inject" signals directly on
the ribbon cables at the BU fanout side to create two face CSPAM/HIPT
coincidences and watched the acq input register LEDs for triggers # 13 & 14.
(of course, we had a mini-acq running there! 8-)
At the end of the tests, I swapped the PS discriminator that was for
HIPT Top & South with the one that was for HIPT East & West. Data from the
RUNs following the swap shows that the problem has moved accordingly. Thus,
I would say that we have identified the problem source.
Unfortunately, we have no spare PS discriminator at this time to make the
necessary repair here.
2) Paolo also helped with a number of the other activities already
reported here. In addition, he also worked with Nat to study the
performance of the new VME DC voltage monitoring boards that had been
installed on Nat's shift.
=======================
Sophia 's report on her work on monopole calibrations:
During the last two weeks Sophia and Erik have tried to
revive the old monopole calibration procedure from the files that
were on disk. Monopole calibrations consist of two steps.
The first step is a quick led run without wfds, firing all leds
at the same time. The analysis of the above data determines the voltage
settings for the LEDs for the second run.
During the second step we fire one tank at a time and we record wfds.