R. Michaels
update Nov 2000
I. Overview
Here are a few notes about the trigger setup for
the Hall A spectometers. The main, so-called S-Ray
trigger (T1 on R-arm and T3 on L-arm) is formed
from a coincidence between two scintilator planes, S1
and S2. In each paddle of each plane, one first requires
that the left and right PMTs fired, then these coincidences
are fed into an MLU which is programmed to determine
if the paddles that fired belong to an allowed set.
Basically, this allowed set corresponds to tracks
which come at a 45 degree angle to the lab floor,
with some angular tolerance (+/- 1 paddle on each
of S1,S2), and allowing any additional hits to
accompany. Details of MLU programming are below.
There are 5 trigger types:
T1 = Right Spectrometer S-Ray
T2 = Right Spectrometer "junk" (exclusive of T1)
T3 = Left Spectrometer S-Ray
T4 = Left Spectrometer "junk" (exclusive of T3)
T5 = Coincidence between T1 and T3
Prior to Sept 2000, the "Right Spectrometer" detector
package was called the "Electron Arm", and the "Left
Spectrometer" was the "Hadron Arm". This notation will
persist in some parts of our software, though we are
trying to weed it out. From the point of view of trigger
and DAQ, the trigger numbers go with the left/right
spectrometer, but which is electron and which is hadron
changes over time, and this affects mainly PID.
The "junk" triggers allow 1 detector to be missing: 1 out
of [S1,S2,Cerenkov] on whichever spectrometer has a
Cerenkov, 1 out of [S1,S2,S0] if S0 exists instead of Cerenkov.
The junk triggers allow to measure efficiency, but they
are mostly junk and have to be cleaned up with tracking.
NOTE: In setups where neither a Cerenkov nor S0 exists,
the junk trigger is just the ``or'' of S1,S2 and is therefore
very loose. This is the case, for example, for L-arm
during e99007.
There should be no, or extremely few, "missing gate"
events, which had bothered us in the ancient past and
had made the frontend buffering unusable. Nevertheless
it is VERY IMPORTANT to verify good synchronization of
the DAQ, by checking correlations between various quantities,
like : (i) VDC track versus scintillator hit, (ii) ADC channel
versus TDC channel for scintillators, (iii) Target Y from
R-arm versus Y from L-arm, (iv) Scattering angles
of R-arm versus L-arm.
You may see event type 14. If so, be sure to ask
me what they mean. You may also see funny bumps in
the ``TC'' spectra (TC is the ESPACE name for the
coincidence time measured in a TDC on the R-arm.)
Some of these bumps come from inefficiency and
serve as a measure of the trigger inefficiency.
Some come from pileup effects or ``missing gates''.
I have some notes in my office about this. It is
highly recommended to understand it. However, if
you take T5 and demand a track, the strange
bumps disappear.
Each event has a latched pattern of bits showing
which triggers existed nearby in time. This is a
set of 12 TDC channels (model 1877, max 6 hits per
channel per event, 5 microsec window) which see
the trigger pulse of the 12 possible Trigger-Super-
visor module inputs AFTER prescaling. Therefore one
can see, for example, if a prescaled T1 accompanied
an accepted T5. For experiments which use the Trig
Super (TS) on the L-arm (i.e the one with FPP), this
latch TDC is in roc 2, slot 22, channels 0-11. For
experiments with TS on R-arm, the TDC is roc 1, slot 3,
channels 0-11. On the R-arm we also latch the triggers
BEFORE prescaling, in roc1, slot 3, channels 16-27.
Of course, before Sept 2000, roc2 was on the R-arm
and most people called it ``spare 7'' in detector map.
Some code to look at trigger latch pattern:
See jlabs1:/home/rom/evchk/README
part II. Instructions to Download Trigger
On an HP-UX computer like adaqh2, from the ``adaq''
account, type ``trigsetup''.
For some experiments like e99007 you cannot change
anything, so downloading is simply a matter of pushing
``download all'' button as prompted to set up the
default settings.
Answer the obvious questions posed by ``trigsetup''.
There are currently ten setup files to choose from.
To select the one you want, you have to answer the
hadron momentum at the prompt. This assumes the hadron
is a PROTON and the momentum is in GEV. (I will probably
change this for the pi-proton experiment.) The script
will calculate the delay and tell you which setup file
it plans to use, giving you a chance to reply if it is ok.
If you put in a wrong momentum (i.e. outside the
valid range 0.36 to 4.0 GeV), you get a second
chance -- you can choose from the ten setup files
which are listed by the script. You have to answer
which one you want, then XTrigMang is started and
you have to push the button 'download all'
Downloading takes about 1-2 minutes. At the
end, the XTrigMang window becomes alive, and
you can press the ``quit'' button.
If you get errors about "unable to connect", etc,
you might have to reboot the VME crate(s) which
serve CAMAC. This can be done remotely. In some
cases, you may need to reboot CAMAC, which cannot
be done remotely. When electrical power is lost
in Hall A, it is necessary to reload the trigger.
A typical session with trigsetup:
adaqh2> trigsetup
trigsetup will provide to XTrigMang a trigger settings file
corresponding to the hadron momentum which you enter below
The momentum must be for a PROTON, and must be in GEV.
(If you enter in invalid momentum, you will have a chance
to choose from the list of settings files.)
Enter proton momentum in GeV (between 0.36 and 4.00)
.88
Trigger file to download = proton_875-1170.settings
(Reminder: the file names contain the hadron name and
range of the hadron momentum where the settings will work)
Is this what you want ? (answer 'y' for yes)
y
Starting XTrigMang....
Press the button : download all
--------------- end of section II ------------------------------
Part III. MLU files
This long, boring section explains the MLU files
and can be safely ignored by most users.
Concepts:
The 1st MLU is programmed the same for
each spectrometer. There are 12 inputs
from 12 scint. Also, on input 15 is the
pulser which is an "x" (don't care).
The Strobe comes from the OR of S2-OR
or S1-OR. The S2-OR signal comes ~15 nsec
before the S1-OR so it normally defines the
timing.
The outputs of MLU1 are
bit 1 and 4 (4 is a copy) "2-2" S-Ray
bit 2 and 5 S1-OR
bit 3 and 6 S2-OR
bit 7 Strobe (from S1 or S2)
The mlu file is mlu1_scint.data
The version which requires pulser on 15,
and doesn't care about the other 12 inputs
is mlu1_pulse.data.
The Strobe output goes to the re-timing
circuit. Bits 1,2,3 outputs go to the
2nd MLU inputs 1,2,3. If Cerenkov is available,
it goes into input 4 of MLU2. If no Cerenkov
but there is S0 detector, S0 goes into input 4.
If there is neither Cerenkov nor S0, nothing
goes into input 4.
For both spectrometers, if S-Ray is present
it puts out bit 1 = trigger 1 (called trigger
3 for L-arm). If S-Ray is absent, then
trigger 2 (resp 4 on L-arm) may be formed
as follows. Where a third detector is available,
2 out of 3 hits are required from S1-OR, S2-OR,
and the 3rd detector (Cerenkov, S0). As I write this,
the right spectrometer is used for electrons, 3rd
detector is Cerenkov. The 2/3 logic is a majority logic
scheme. The T2,T4 which doesn't have a 3rd detector
is much looser; it required only the OR of S1-OR,
S2-OR. The 2nd MLU is in transparent mode.
The S-Ray does not involve Cerenkov nor S0, neither
logically nor for timing. If one wants to benefit
from S0 timing, one must do so in analysis.
Triggers 1 and 2 are exclusive. Trigger 2
will not go to the coincidence circuit.
Similarly for triggers 3 and 4.
Technical details of MLU programming follow.
I. Files for 1st MLU: mlu1_scint.data
(version for pulser tests: mlu1_pulse.data)
This is used by both R-arm and L-arm.
The 2_2 S-Ray trigger is generated
with
XYmlu -f mlu_2_2_andbgr_generate.dat
and compressed with
mlu_compress
The result is renamed mlu_2_2.data
Note: S0 does not go into MLU1.
The L,R PMTs go into inputs 4,5 of MLU2.
The s1-or is generated with
XYmlu -f s1or_generate.dat
and s2-or with s2or_generate.dat;
both are compressed with mlu_compress.
The results are renamed mlu_s1or.data
and mlu_s2or.data
The 3 files are merged for bit-wise
or of the outputs. Two files can
be merged at a time using mlu_bitmerge.
mlu_bitmerge mlu_2_2.dat mlu_s1or.data
Call the result of this mlu_temp.dat;
then
mlu_bitmerge mlu_temp.dat mlu_s2or.data
The result is the MLU file for MLU1.
Renamed:
<<< mlu1_scint.data >>>
In the case of mlu1_pulse.data, the above
combinations are allowed, in addition the
pulser on input 15 is allowed to overlap
with the any combination of 12 inputs (else
the probability to overlap would be too small).
We do:
XYmlu -f mlu_2_2_pulse_generate.dat
Let result be mlu.data, then concatenate:
cat mlu.data mlu1_scint.data > mlu1_pulse.data
II. File for 2nd MLU on Electron Spectrometer
mlu2_electron.data
Generate with
XYmlu -f mlu2_electron_generate.dat
compress this, call it temp1.dat
Get the luminosity monitor file
XYmlu -f mlu2_lum_generate.dat
compress this, call it temp2.dat
Merge the above two files
mlu_bitmerge temp1.dat temp2.dat
Result:
<<< mlu2_electron.data >>>
III. File for 2nd MLU on Hadron Spectrometer
is mlu2_hadron.data. Version prior to
Nov 20, 199 is stored, e.g. in ./save20nov99.
After Nov 20, 1999 it will also be
called mlu2_hadron.data but will involve
the S0 in a majority logic scheme to
form T4. 2/3 is required from S0,S1,S2
where S0 is both L and R PMTs.
Generate with
XYmlu -f mlu2_hadron_generate.dat
compress this, call it temp1.dat
Get the luminosity monitor file
XYmlu -f mlu2_lum_generate.dat
compress this, call it temp2.dat
Merge the above two files
mlu_bitmerge temp1.dat temp2.dat
Result:
<<< mlu2_hadron.data >>>
Appendix -- MLU utilities routines on adaq HP machines
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