I have written up a report on the status of the Stop Masters at
the request of Chris W. While I was at GS, Stefano Stalio worked out a
great testing procedure using the Pisa Camac-Macintosh setup. Using
this we worked out some bugs in the Spare Stop Master, and verified that
the SM1 Master is working. But while blind testing has its place, it
would benefit future debugging of the Stop Masters to understand the
current quirks of the system by looking in data.
So after some good suggestions from Erik while I was at GS I have
delved into the Stop Master guts. I will describe a few of the "features" I
think people should be aware of.
First here is what I did: I looked at the runs 11835, 11836,
11845, 11846, 11847 and 11848. (This is a couple days of the most
recent data I could get my hands on.) I was interested in the
following: Trigger Efficiency, Tohm Face Efficiency, and the bitpatterns
of the timewords for both trigger times and tohm face times (checking
for stuck bits).
To get the Trigger Efficiency I compared the total occupancy of
each Stop Master Trigger bit throughout the data set to the "real"
triggers in the data. For example, if for every time the ERP bit fires
in a Stop Master there is also an Erp box in the SAME super-module, the
efficiency for the Stop Master on that super-module will be 100%.
For the CSPAM/HIP/FMT I define a "real" trigger as the
corresponding bit being on in the Scint. Pattern Register. For the
TOHM, ERP, and LIP data I look in the equipments themselves.
RESULTS
=======
For the ERP, LIP, and HIP the effiencies for each SM are very
nearly 100%.
Efficiency (%)
SM1 SM2 SM3 SM4 SM5 SM6
ERP 100.00 100.10 99.97 99.96 99.97 100.01
LIP 100.10 100.10 100.10 100.00 100.00 100.00
HIP 100.20 100.10 100.00 99.98 99.96 100.01
So I see that the Stop Master is sometimes slightly
under-efficient, and even over-efficient. I have looked for
missed/extra Stop Master Trigger bits in the data, and have found a
disturbing class of events where trigger bits might be missing. More on
that later. I still cannot explain why we would sometimes get EXTRA
bits.
The Stop Master comes out being very inefficient for stopping
on CSPAM events.
Stop Master Efficiency for detecting CSPAM
Efficiency
uVax1: 73.5%
uVax2: 59.0%
uVax3: 73.5%
The Stop Master Efficiency for the FMT is exactly 100% for
SM3,4,5 and 6. But on SM1 it is 170% and on 2 it is 57%. The actual
bin occupancies that lead to these efficiencies are 12/7 and 4/7.
The Tohm Face efficiencies are 99.84+/-.07% (Average over all
faces +/- sigma). If people are interested in the raw numbers I will
post them. The outliers are:
Efficiency
SM1 B 95.9%
SM2 E 94.1%
SM3 W 110%
SM3 E 136%
SM4 W 92.5%
By looking at the bitpatterns for the trigger and tohm times I
see that no time bits are stuck on or off. I looked at the trigger
times collectively for each Stop Master, and the tohm face times
ccollectively for each Stop Master, so I would have missed stuck time
bits in individual trigger times or face times.
Discussion
==========
So What?
First, how important is it that the Scintillator Trigger
efficiencies in the Stop Master are not exactly 100%? To answer this we
have to find out what is causing the misses (or extra hits, as the case
may be).
So a while ago, Chris W emailed me about events where the Stop
Master only knows about a Tohm Trigger even though there are other
triggers in the events. In run 11834 I found 4 such events, and I am
confident that these are what are causing all of the missed triggers.
If you are as interested by this as I am, you will want a little more
info:
First, the event numbers are 3726, 4720, 6079, and 8271 in run
11834.
In 3726, the Stop Master saw only SM4 East Tohm. The TOHM saw
3W08 and 4E10. The Trigger Pattern Unit saw on uVax2 ERP, TOHM, and
CSPAM. The Scintillator Pattern Unit saw the erp and cspam, but it only
saw the TOHM trigger on SM3. In other words, the Stop Master and
Scintillator Pattern Unit disagree completely, but between the two of
them they "tell the whole story".
In 4720 we have a very similar situation on uVax3, only the
relevant Tohm hits are 6E05 and 5T04. Here the Stop Master saw 6E05
only, while the SPU saw a TOHM on SM5 only. The important thing to
point out here is that the offending TOHM channel is limited to Attico
or Lower TOHM.
So what's the deal? I think it is something to do with the way
computer busy is handled in the Stop Master. Either it is ignoring the
computer busy and allowing Tohm Triggers as soon as it is cleared, or it
is somehow receiving the end of the computer busy before the rest of the
ACQ.
Whatever it is, I think it is clear that the problem is that the
Stop Master is receiving Trigger Info from the Tohm, while the ACQ is
not. The result is that the Stop Master is not cleared until the next
event that IS registered by the ACQ.
The other two events I found where this happened had 4E10 as the
early TOHM channel again. 4E10 is a known hot TOHM channel and had been
responsible for bursts in the data rate while I was at GS. In the
scenario where the problem is caused by TOHM triggers received during a
computer busy, but AFTER the Stop Master is cleared, hot tohm channels
would directly affect the rate of the problem. So I am not surprised.
This also means that even though this problem is a .1% effect, even
people not doing monopole analyses should keep a close eye on the TOHM
rates (consider yourself warned, Chris).
The next surprise was the inefficiency associated with the
CSPAM. Note that the efficiency on uVax1 and uVax3 were identical. I
don't think this is a fluke. I think that the signals going to the Stop
Master are missing the OR of signals from coincidence between uVaxes.
The reason I think this is because all events I found where there was a
CSPAM and no Stop Master bit for the CSPAM were multi-uvax CSPAM events.
There is clearly something wrong with the FMT/Stop Masters on
uVax1. It needs looked into. We tested the SM1 stop master pretty
extensively while I was at GS and we didn't notice the FMT bit being
subject to cross-talk, so my guess is that the over-efficiency in SM1 is
really what the Stop Master is being told. (Note the word "guess")
The West and East faces on SM3 were over-efficient. I have
found many events where both the West and East Face on the SM3 Stop
Master fire at the exact same time even though there is actually only a
TOHM trigger in one of those. (I have seen it happen both for when W
and E were the "real" faces hit). But I also saw another event (Run
11834 Event 1759) where both West and East on Stop Master 3 are hit, but
E is delayed by 16.2usec. So the West and East inputs are not simply
tied together. What is strange is that there is not actually an East
face trigger for this even, but there are several E face TOHM
Activities.
So that is all I have to say in this pass about the Stop
Masters. My next Stop Probe will be systematically checking the
Inter-Super Module timing in the Tohm Face Times by comparing them with
the Tohm Trigger Times when there is also a CSPAM. If you think
about the time signature when two adjacent supermodules both have TOHM
and CSPAM triggers, and know how the Stop Master works, I think you'll
agree this is a good self-consistency check (otherwise don't worry, I'll
explain the method in detail after I do the test). Preliminary data
seems to show you don't get what you expect between SM4 and SM5... but
more on that later.
Consider that the teaser for my next report on the Stop Master.
I am also entertaining suggestions on other things I should look
at, and I would be more than happy to clarify points that I may have
muddled up in my descriptions here....
Chris Orth