Notes on Trigger Programming for e00007 and Beyond
===================================================
For other experiments search the README* files on adaq
account in the trigger directory. These notes are mostly
backward compatible for running since Jan 2001.
update Sept, 2002
experts: R. Michaels and B. Reitz
This file describes some details about the Hall A trigger system.
Click HERE for simple instructions to set up the trigger.
I. Overview
The main triggers (T1 on R-arm and T3 on L-arm)
are formed from an overlap of S1 and S2 scintillators.
This is described in detail below.
The triggers are
T1 = Main R-arm trigger
T2 = Loose R-arm trigger, for measuring efficiency
T3 = Main L-arm trigger
T4 = Loose L-arm trigger, for measuring efficiency
T5 = coincidence of T1 and T3.
T8 = 1024 Hz pulser
These may be prescaled by editing ~a-onl/prescale/prescale.dat.
The maximum prescale factors are 24 bits for T1-T4 (i.e.
2^24 - 1 = 16,777,215) and 16 bits for T5-18 (2^16 - 1 = 65535).
The prescale factor is a modulus of these limits, so if you
put ps8=100000, then 100000 % 65536 = 34464 is the prescale factor
you ACTUALLY used. Be careful.
Most of this note is for standard coincidence running, but I will add
paranthetically that for RCS the triggers were
T1 = RCS photon singles trigger
T2 = RCS cosmics trigger
T3 = Main L-arm trigger
T4 = Loose L-arm trigger, for measuring efficiency
T5 = coincidence of T1 and T3
T6 = laser
T8 = 1024 Hz pulser
In addition, the old S-Ray trigger (involving MLU) will
be formed, but not put into trigger supervisor, hence no
events of that type. Instead the S-Ray trigger will only
be put into a scaler, its rate should be similar to the
main trigger.
The MLU is used to form T2 and T4. It could possible be used
to form additional triggers that require other detectors.
Let us first describe the MAIN TRIGGER, T1 and T3, which
is based on scintillators. NOTE: This section pertains to
most run periods, where we used S1 and S2 scintillators.
For E00007/17 (FPP run), see below.
First the Left and Right PMTs are AND'd. There are then 6 signals
from each scintillator planes S1 and S2 (the result of L+R).
These 6 are OR'd to make one signal each from S1 and S2.
Finally, the trigger is the AND of these two signals.
Here is an ASCII diagram:
S1 - paddle 1 - Left --\
S1 - paddle 1 - Right ---AND -->
S1 - paddle 2 - Left --\ \
S1 - paddle 2 - Right ---AND --> \ OR of S1
paddle 3... 6 \
\
\ AND -------> T1 (T3)
/
/
S2 - paddle 1 - Left --\ / OR of S2
S2 - paddle 1 - Right ---AND -->
paddle 2... 6
Note for FPP experiments E00007/17:
To avoid bias from S2, the FPP experiments asked us
to define T3 as the overlap of S1 and S0. The S1 is the
same as defined above ("OR" of 6 paddles). The S0 signal is
the "AND" of its two PMTs. For these experiments, the S0
signal is also the retiming signal. T4 was also affected
(see below).
Note for experiment e01001: The e01001
experimenters tried a different definition of T1, while leaving
T3 the standard definition. Ask Arrington why. The difference to
the above diagram is that the "AND" of the Left and Right PMTs
becomes an "OR". This turned out to be a disaster; see halog for
why. After not much running we returned to the standard definition.
The timing at the trigger supervisor will be such that T5 arrives
first, thus it takes priority in deciding the event type. However,
one may look at the trigger latch pattern to see which triggers
coexist.
A ``trigger latch pattern'' in the datastream shows the
pattern of triggers which co-exist in an event. This is
a TDC 1877 (multi-hit with up to 6 hits, a 5 microsec
window, one trigger on each of 12 channels, each channel
a separate trigger) which shows on channels 1-12 the
trigger 1-12 AFTER prescaling. So, if a T5 is accompanied
by a T3 which survived prescaling, one would see a signal
on channels 3 & 5 with the appropriate timing. This
trigger latch pattern is called ``spare7'' in the detector
map.
T2 and T4 are for measuring efficiency. The definition has
changed over time and at present (Sept 2002) the definition
on R-arm involves majority logic scheme of S0, S1, and S2
and is (imperfectly) exclusive of T1.
T2 = ((S0.and.S1) .or. (S0.and.S2)) .and. (.not.T1)
while T4 on L-arm cannot use S0 since it is used for T3.
(This might get changed back to its original config for
e01020 in November but I'm not sure yet).
Define TT = S1 .or. S0A .or. S0B
(where S0A and S0B are the 2 PMTs of S0)
Then T4 = (S2. and. TT) .and. (.not.T3)
Typically the raw rate of T2/T4 should be 5% of T1/T3.
WARNING !!! WARNING !! WARNING !! :
The "CODA event type" is NOT NECESSARILY the "trigger type".
This is because of trigger supervisor functionality.
We try to arrange it such that the CODA event type is indeed
the trigger type, but the most fundamental way to sort out
what trigger type is to look at the trigger latch pattern explained
above. Here is how the CODA event type is defined: If trigger N
arrives first and survives prescaling then the CODA event type is N.
However, if triggers N and M overlap within 10 nsec and both survive
prescaling, then it is defined as event type 5. (In former times this
was defined as event type 14, but that proved dangerously confusing.)
Ideally all triggers would be split apart enough that there would be
no such ambiguities, but this is difficult to arrange for other reasons.
So, in practice T5 is arranged to arrive first and will make CODA
event type 5, but if T5 is prescaled away then T1 and T3 may overlap
at the TS (especially for EDTM pulser signals) which again makes an
event type 5. I realize this is confusing, but if you rely on the
trigger latch pattern, you can sort things out.
How the coincidence time is measured, and some explanation of
the glitchy features seen there, are explained in this document:
ctime.ps (postscript).
Electronics deadtime is a complicated issue. There can be losses
in the trigger electronics, but also smearing of distributions
(TDCs, etc), and pileup in VDCs. To provide a handle on some
of these things we have implemented a scheme to measure the
electronics deadtime.
Some old software to check the trigger exists, apart from ESPACE. I noticed
that it still works for standard setups like April 2002, but I won't
support this package in the future. You can give it a try, see
hana instructions
II. Range of Validity of Trigger
For April 2002 the trigger was certified in the range of delay differences
-115 to +50 nsec. A negative number means the R-arm is slower, and a
positive number means the L-arm is slower. For reference, a delay of
-112 nsec corresponds to e-P coincidence with P on R-arm at 450 MeV/c
momentum, and a delay of +46 nsec with P on L-arm at 800 MeV/c. These
are the limits that are imposed by the software during April-May 2002.
(You will find out if you try to exceed them.)
When downloading near the limits of the range of validity one may see
warnings like this:
ApplyDelay:WARNING: Could not apply entire delay 108 111
This is because of the T4 delay. It means that I could only apply
108 nsec instead of 111 nsec to this delay, and it is not a problem
as long as these are within 10 nsec.
Another small issue has to do with the EDTM system. EDTM serves two
purposes: 1) Measure electronics deadtime (EDT) and 2) Simulate coincidences
with pulser. These are explained in section I. But the EDTM is restricted
to simulating from -300 to +15, so when we go from +15 to +50 the pulser
does not move. This is not a problem since the coincidence window is
about 110 nsec.
III. MLU Programming -- Concepts
MLU#1
Generate S-Ray pattern
mlu1_Sray_left_generate.dat
mlu1_Sray_right_generate.dat
(left and right spectrometers)
R-arm has bit 14 bad, hence different.
Generate S1-or and S2-or
(same files, though bit 14 bad on R-arm).
s1or_generate.dat
s2or_generate.dat
Since Jan 1, 2001, the S-Ray trigger plays no role anymore,
but it is put into scalers to count.
MLU#2
This MLU is run in strobed mode with the strobe coming from
the OR of S1, S2. That means that at least one of S1,S2 planes
must fire.
Bits
1 = S1-or
2 = S2-or
3 = Gas-Cerenk (if exists), or S0-PMT#1 (if exists)
4 = S0-PMT#2
T2, T4 logic
Ignore S-ray
Veto if main trigger exists.
For e94104 and e98108: Require S1-or or S2-or.
Don't require Cerenkov.
For e99117 and e97103: Require 2 out of 3 from
among S1-or, S2-or, and Cerenkov-or.
For e00102 and beyond: Require 2 out of 3 from among
S1-or, S2-or, and S0. S0 requires both of its
ends to fire.
For April 2002, T4 is like e94104 and T4 is like during
e00102. This is due to availabilty of S0 and the fact
that often protons are used on both arms.
Generate T2, T4 with
mlu2_t2_generate.dat
mlu2_t4_generate.dat
These generation files have changed slightly since Jan 2001.
For convenience I have saved the mlu2* files that were generated
and used:
mlu2_t2_e94104.data, mlu2_t4_e94104.data used by e94104 and e98108
mlu2_cer_t2t4.data used by e99117 and e97103
mlu2_s0_t2t4.data used by e00102
IV. Technical Details of MLU Programming
The following is a typical script for generating the MLU files.
#!/bin/sh
# Directory is adaql1:~atrig/trigger/mlu
# Make Sray for left spectrometer
XYmlu -f mlu1_Sray_left_generate.dat
mlu_compress mlu.data
rm mlu.data
mv mlu_compress.out mlu1_Sray_left.data
# Make s1or and s2or (used for both spectr.)
XYmlu -f s1or_generate.dat
mlu_compress mlu.data
rm mlu.data
mv mlu_compress.out s1or.data
XYmlu -f s2or_generate.dat
mlu_compress mlu.data
rm mlu.data
mv mlu_compress.out s2or.data
# merge to form mlu1_left
mlu_bitmerge mlu1_Sray_left.data s1or.data
mv mlu_bitmerge.out temp.data
mlu_bitmerge temp.data s2or.data
mv mlu_bitmerge.out mlu1_left.data
# Make Sray for right spectrometer
XYmlu -f mlu1_Sray_right_generate.dat
mlu_compress mlu.data
rm mlu.data
mv mlu_compress.out mlu1_Sray_right.data
# merge to form mlu2_right
mlu_bitmerge mlu1_Sray_right.data s1or.data
mv mlu_bitmerge.out temp.data
mlu_bitmerge temp.data s2or.data
mv mlu_bitmerge.out mlu1_right.data
rm temp.data
# make MLU2 file for t2
XYmlu -f mlu2_t2_generate.dat
mlu_compress mlu.data
rm mlu.data
mv mlu_compress.out mlu2_t2.data
# make MLU2 file for t4
XYmlu -f mlu2_t4_generate.dat
mlu_compress mlu.data
rm mlu.data
mv mlu_compress.out mlu2_t4.data
=======================================================
Appendix -- MLU utilities routines
Type the name of the utility without arguments and
it will introduce itself, and explain its usage.
XYmlu -- takes a pattern like 10xx01 and
generates all mlu entries. 1=bit must be true;
0=bit must be false; x=bit may be 0 or 1.
There is a Y option, but it is little used
and not too important.
btst -- Examines a pattern of bits
mlu_compress -- Takes an mlu file and
examines all pairs of line-entries. If the
two line entries are identical, one is kept,
the other discarded (this isn't really necessary
but speeds up the download). Also the bit-wise
OR of 2nd components is taken if first components
are identical.
mlu_compare -- Compares two mlu files
to see what is different. If no optional
argument is given, any difference in the
file are noted. If an argument is given
(any number), only the first entry of each
pair are compared.
mlu_bitmerge -- Merges two mlu files. For
each pair of line entries "X1 Y1" from file 1
and "X2 Y2" from file2, if X1=X2, then the
two entries are merged to form bit-wise OR
of Y1,Y2, i.e. we get "X3 Y3" where Y3 = Y1 | Y2.
This page maintained by rom@jlab.org