on the completion of the WFD system

Erik Katsavounidis (Erik.Katsavounidis@lngs.infn.it)
Fri, 23 May 1997 14:50:50 +0200 (CET-DST)

Dear WFD people,

As it was discussed quite extensively at the Ann Arbor general meeting,
the 33uF on the fanouts/33nF (23nF+10nF) on the WFDs will be the hardware
solution to implement in the whole detector. This will take care of all
overshoot/undeshoot issues. As you know SM3 is already fully upgraded and
the rest of the supemodules will undergo the same procedure in the course
of the next 5-15 days (pending delivery of parts at GS).

Here I would like to discuss a few of the issues that actually received
a lot of attention during the meeting and had to do with actions we have
to take in order to address issues that go beyond the hardware fanout/WFD
fixes. SINCE WE'RE LOOKING INTO STARTING THE ERA OF MACRO'S RUNNING IN
ITS FINAL CONFIGURATION BY (MAXIMUM) MID-JUNE, I WOULD LIKE TO MAKE SURE
ALL PEOPLE ARE AWARE OF ALL THE ACTIONS WE'RE PLANNING TO TAKE. MOREOVER,
THIS IS THE TIME TO RAISE QUESTIONS, COMMENTS AND SUGGESTIONS. The time
until the completion of all fixes should be the time that all of the
issues below should be clarified and tested.

1) As shown, the PMT afterpulsing can be enough to fill the WFD's memory.
For that, we need a "fast" (<125usec) stop of the WFDs when the charge
of a PMT signal suggest a value that can create enough afterpulse to
kill us. A custom made module (referred to from now on as "LaMosska") has
been prepared and currently being tested in *real* acquisition in SM1/2.
Here the main facts about LaMosska as is now (please check out our
MACRO-Online page at http://wsgs02.lngs.infn.it:8000/macro/hardware.html
for electronics and logic drawings):
- This module is NIM, SM-based.
- This module has a total of 20 (22 for SM1/6) inputs that are coming
from the CSPAM fanouts; each signal corresponds to the sum of *8*
PMT signals.
- This module has TWO integration circuits, one where all "0"-end PMTs
are integrated and another one where all "1"-end PMTs are integrated.
- The outputs of the module are discriminated and their *OR* condition
is delayed by ~110usec (this will be pushed closer to the WFD byte
limit of ~125usec; however you dont't want to make this very close to
125usec as the LaMosska output for long PMT pulses will have usec-long
rise-time). The delayed LaMosska 0.or.1 is further OR'ed with the
"standard" stop master "WFD stop" output; this .OR. stops the WFDs in
every SM.
- The current heavy multiplexing of PMT signals (80:1) in LaMosska
presents implications that have to do with the fact that PMT signals
from all counters/faces resulting from all cosmic ray events (except
from the one and only monopole) will all be integrated within the
same time window. Thus, any nominal LaMosska threshold will effectively
be only a fraction of it, depending on how many detector faces/PMTs are
integrated at the same time.
- The LaMosska threshold after the fanout/WFD capacitor replacement
will need to correspond to PMT charges of the order of 15-20 V*usec
(Imin~0.1 V*usec), i.e. at a level where it should almost never fire
on cosmic ray muon events. As we discussed in Ann Arbor, we want
to collect events from LaMosska at some reasonable rate in order
to make sure the module is not dead. However, I believe the safest
way is to have a weekly calibration that will fire 1 LED pulse in
*every* PMT end and make sure the entire chain of circuitry works
the way it supposed to be.
- There are issues that have to be carefully examined prior to lowering
the LaMosska threshold in order to achieve a non-zero rate. As I
mentioned in the past, if I_th is the ionization threshold set for
LaMosska, then any particle crossing the apparatus in more than ~125usec
(beta~<6x10^-4 for >95% of the acceptance) and its passage through any
counter results in light I>I_th, then WE WILL LOSE THE WAVEFORMS OF
THE DETECTOR'S FACES THAT THE SLOW PARTICLE WILL CROSS ~125usec *AFTER*
IT TRIGGERED LaMosska. I remind you that if we had set LaMosska's
I_th at ~0.25I_min, then NO HARDWARE fanout/WFD modification was needed:
this by itself could have limited the existing overshoot/undershoot/
afterpulses within the 125usec digitizing window.

2) The issue of making a trigger out of LaMosska was discussed in Ann Arbor.
Even if LaMosska's threshold is kept as high as it can be, still the creation
of the trigger can function during calibrations (and for the one and only rare
event). Last Wednesday I've looked into the details for the creation of this
trigger and took a test run. Here are my remarks:
- A critical issue in commissioning LaMosska is to come up with a way to
record its timing relative to the triggering PMT, the rest of the
WFD-stopping triggers and the actual STOP of the WFDs. I've looked into
reusing the old latching scalers we used for pre-1993 monopole runs.
At Gran Sasso there are 3 "1990 models" and 3 "1992 models" (we have
another 1992 model at Caltech which I've asked Sophia to bring here- we'll
need it). The idea is to use their ability to count time differences,
something that was used in the past in order to count ToF for TOHM faces.
First of all, almost all of them had signs of people using them for
parts (missing chips 621/245's). By moving chips around, all expect one
1990 model are now complete. All scalers are effectively 6-input ones.
The 1992 models have bit-latching capabilities for more than 20 signals.
The 1990 ones have 6. I've tested all modules. Unfortunately, one 1992
model has one of its counters flaky and it might need a non-straightforward
ACTEL chip burning (that's why we'll need the extra there's at Caltech
now).
- The question is how many bit/time-counters we need for the LaMosska
implementation. The question that was raised in Ann Arbor was which
of all the WFD-stopping triggers to use as a reference in order to
"time" LaMosska/WFD stop. Well, I don't think we need any of them. What
I did in the testing of these modules is I used the "WFD STOP" output of
the "STOP MASTER" instead. This should be able to give us *any* relative
timing we're interested in. Here's the configuration I tested:
Input#1 SM1 LaMosska-0,LaMosska-1 outputs
(signals are latched separately but start the same counter)
Input#2 SM1 LaMosska delayed signal
(this is the actual STOP of the WFDs)
Input#3 SM1 STOP MASTER output
(this should allow to time LaMosska relative to all triggers)
Input#4/#5/#6 same as above but for SM2.
The LaMosska trigger is #11 and it reads two equipments: EQP36 which
is the above info read on a per microvax basis and EQP40 which is the
standard STOP MASTER readout.
- The intallation of the latching scalers in the detector will require
some modifications in order to make things easier: all of its inputs
are TTL and it lacks on-board clock. We'll put NIM->TTL converters
and a clock crystal on board in order to make our life easier. What is
the clock frequency that we want for this scaler? I've used a 10MHz
clock for the test; this is actually a nice number since it matches
the STOP MASTER's clock frequency. Since though we really want to
guarantee the latching of Input#3 and #6 in the above scheme, I suggest
clocking it at 5MHz and REDUCING THE DELAY IN THE STOP MASTER to
anything less than 1msec. Since the average Delta_T between
Input#1(#4)-Input#3-Input#6 is 2msec, we want to make sure that all
these are counted in the 13 bit counter.
- In Ann Arbor I raised the issue of whether or not we want the
input/output of LaMosska getting digitized by a stand-alone WFD
and read via CAMAC for every LaMosska trigger (#11). This falls
rather in the general WFD readout issues that follow.

3) There are a number of WFD readout issues, at least in my mind, that should
be resolved at the same time.
- Readout of TOP scintillator counter WFDs on Streamer Tube monopole events.
In the current scheme, this is not done. Chris Orth has the pascal
code ready and reasonably tested back in February 1997. The effect on
the data volume should be negligible (<5%).
- Readout of WFDs for TOHM *activities*. Chris Orth raised this issue.
There is some benefit behind a readout like this. You have a direct
way to study TOHM's triggering at a *lower* threshold. It makes
searches less susceptible to short pathlengths. It inceases discrimination
power against noise events by allowing the WFD readout at a lower
trigger threshold. Again, Chris has the code ready and tested. I can not
make a precise statement of its effect on the data volume, simply because
it was tested at the same time with other WFD readout changes. Certainly
through, looking at the data, there are few TOHM activities without
a TOHM trigger.
- Another issue is the readout of the entire SM whenever a two-face TOHM
coincidence is formed. The STOP MASTER hardware provides latched bits
with this info, something that makes the pascal implementation
straightforward. As with the previous two items, Chris has the pascal
code ready also for that. In a test we made though back in February,
the introduction of these three WFD readout changes resulted in a data
volume increase of the order of 20-25% with most of it coming from the
two-face slow monopoles.
- An alternative to SM-wide WFD readout on two-face monopoles can be to
add a single WFD digitizer card in each supermodule where multiplexed
PMT signals can be digitized and provide the SM-wide WF picture on
some class of events where we believe it's worth doing (monopole
coincidences, HIPs). This will certainly add minor data volume (only
the channels of this .OR. PMT WFD will be read) and will be able to
function nicely as a MACRO-at-a-glance device on interesting events.
- Finally, given the number of times we expect LaMosska to fire, I think
it is worthwhile to implement SM-wide readout of the WFDs. This will
give us the ability to monitor the hardware better. No effect on the
data volume will be noticable.

That's what I see as action items before the re-commissing of the WFD system.
Of course monopole calibrations remain an issue that has to be addressed
at the same time (and indeed it is); however, here I've focused on hardware
issue over which we should have clear ideas and decisions by the time
the full sensitivity monopole run starts.

--Erik