Data analysis and trigger words and bits
Last updated: Wed Nov 19 10:22:07 CST 1997
During datataking information about trigger type was stored in camac
data block along with other trigger status data: trigger labels (bits),
amplitudes in scintillator counters, scalers, Programmable Logic Units
and Memory Logic Units output patterns. All this info went into camac data
Data Aquisition System analysed trigger type and depending on event
trigger type and information stored in dis database wrote event
to one of the data streams: charm, primakoff or calibration.
If trigger was not specially described it went to calibration stream. We
had 2 crates (2 blocks) of camac data. First short block was taken for
each event, this called 100% crate. The other block with more data
was stored for some fraction of events, this is so called 1% crate (ratio
is different from 1/100). Data for 1% crate independent of trigger type
also were written to calibration stream.
Programm to read data from camac crate is on fn781a in
$ONLINE_DIR/scc/crate_1.asm -- 100% crate
and set of saved files in this directory. This code defines which
words and in which order were read and written to camac data stream.
Offline routine $OFF781_SRC/unpack_camac.F unpack raw camac data
into common/camac_bk/ of $OFF781_INC/camac_bk.inc
There are 2 logical variables creadout_1 and creadout_2 which
are true when data from crates 1 and/or 2 present. You can consult meaning
of the camac data words here or in comments in files unpack_camac.F
or crate_1.asm or crate_2.asm. There are few latches, each bit or group
of latch bits have special meaning:
crate Latch A: T2 tags, misc.
crate Latch B: T2 tags = t2_mlu_dec output
crate Latch C: T1 triggers and tags
<--- TRIGGER TYPE
Most likely you looking this page to find out how to manage trigger
There is one more routine $OFF781_SRC/unpack_hodo.F
which unpack scintillator hodoscope information into common/hodo_bk/
Related OCS tables are hod_pos.ocs and hod_sz.ocs (includes
also info for hodo unpack).
How it works
We had 3 stage trigger: T0 fires T1, it maybe fire T2, then it maybe fire
T2, which maybe start DAQ which write data into one of the data streams.
Input information for trigger decision or result of logical function
on which these decisions were based were stored.
For each trigger level we might have several subtriggers, which of
them fired this trigger level can be identified by trigger labels.
To make picture more complex, let mension that we had several trigger
logic definitions like Beam, Interaction, Pulser and different versions
and derivatives. In this case meaning of bits and latches might be different
between trigger types and versions, but we were trying keep basic definitions
stable. Which trigger type was loaded for specific run was recorded in
It also was recorded by DAQ in run log, which is now converted into
For given trigger type or version:
In general, we should use for each run or group of runs or trigger type
separate OCS table describing the trigger.
T0 always had the only trigger function (definition), no subtriggers.
T1 had diferrent subtriggers, like
Ex - Exclusive / Exotic
He - hadron/electron scattering
T0 prescaled - typically beam and minimum bias interactions
HYP - Hyperon trigger
HST - Hadron Scattering Processor decision
T2 in most cases had single function T2=T1, and only few test runs were
taken where it applied additional function to T1 (HST*Photon_3 or T1*Matrix).
As a practical matter, T2 was almost always (exept few dedicated runs)
equal to T1 (fired, when T1 fired), and I can't gurantee that T2=T1_prescaled
subtrogger bit was set to 1 in this case, that is we must analyse only
T1 subtrigger type unpacked to "camac_trig_b2" , which in
our case is a trigger type.
Test T2 subtrigger type in Latch_A, 8 bits #9-12, unpacked to "camac_trig_b0"
Test T1 subtrigger type in Latch_C, 8 bits #1-08, unpacked to "camac_trig_b2"
These trigger words are copied (need to check with Jurgen which 'these
words') by DAQ to hard_trig(3) of common /event_header/ of
T1 subtrigger bit # to test T1 subtrigger type pattern described in
first part of $CON781_DIR/kern/trigs.ocs table.
There we have 8 triggers defined with bits (1-8 -- mask 1/2/4/8 etc.)
for charm/Excl/He/T0-prescaled/Hyper/Dummy/HST/Reserved triggers. This
raw camac dataword is unpacked to "camac_trig_b2" of common /camac_bk/
Trigger Types and Runs
List of triggers
List of triggers used to write data
Back to E781