miniBooNE Trigger Notes (Version 1.0)

Rex Tayloe, Andrew Green 1/24/03


Find in this document an explanation of the MiniBooNE trigger (with emphasis on the software) and a summary of the trigger settings for the first period of MiniBooNE running (9/02-1/03). See the references listed below for background information.

References to particular pieces of C-code are given by name. Find these at the MiniBooNE CVS repository (Reference 5).

I only briefly describe some aspects of the hardware. See the fine writeups listed below for many more details. Please give them a read.

QT System Summary

See Reference 1, Section 4.2, for more information.


Each miniBooNE PMT is connected to a single coaxial cable that provides the (positive) HV and routes the signal from the tank to the digitizing system. They are connected to a set of preamp cards which determine the HV to each tube (via a step-down resistor) and separates the PMT signal from the HV on the cable. This PMT signal is then amplified by approximately a factor of 20 and routed to the "QT" system.


The QT system consists of 12 VME crates of 16 cards with 8 channels per card. Each channel digitizes the time and charge info for each tube and stores this information into a dual-port sRAM at an address determined by the 11 bits of the 10 MHz system clock (the time-stamp address, "TSA"). This dual-port sRAM serves as a circular buffer of length 2048. The data is continuously digitized and written this circular buffer which wraps around every 2048 x 100ns = 2.048 microsec. Data is read from this circular buffer at times (TSAs) that are determined by the trigger to be "events" (physics, calibration, etc). If the trigger is too slow in asking for data from a particular TSA, the circular buffer wraps around and the data of interest is lost. This is a condition known as latency (see below). When the data from a particular TSA is retrieved from the dual-port sRAM, it is downloaded into a QT FIFO where it is then retrieved under control of the QT single-board computer (SBC) via the VME bus. All 128 channels of data is gathered by the SBC, zero-suppressed, and then shipped to the host computer (via 100 Mb/s ethernet) where the events are assembled and written to disk.

PMT Sum System

Each QT crate also contains a PMT sum card. This card counts the number of channels that fired (discriminator hit) in the last 2 clock cycles (200ns). This information is then routed to the trigger crate main and veto comparator cards which adds the numbers from the main and veto crates for an overall main and veto number of hits. There is time delay of 10 clock cycles for this PMT sum information to be available in the trigger crate.

Trigger Summary

See Reference 1, Section 4.3.1

The miniBooNE trigger works by examining a pattern of bits within a piece of C-code. This code runs on a MVME 2304 single-board computer that sits in the trigger crate. A flowchart of the trigger-code is shown in Figure 1.

The main pieces of C code are (the references point to the correct CVS tag):

The trigger crate contains a handful of other modules that (among other things) serve to gather and digitize the information that will be used within the trigger code to determine if a particular candidate event should be read out from the QT crates. This information consists of:

Note: The main and veto sums are formed by summing the 10 main and 2 veto QT crates separately.

If the OR of bits (DET1,VETO1,E4,E2) are set in a particular 100ns time window, then the data is downloaded to a trigger memory FIFO (this is a hardware action). The original design of the trigger memory card was not wired so that E2 would cause this action. It was jumpered in later for the particular needs of the LSND experiment. With our current trigger scheme, this jumper could be removed, but it hasn't as of this writing. The data available in the trigger FIFO word consists of the 11 bits described above plus 16 bits of the 10 MHz binary clock. Note that one of the 4 bits (DET1,VETO1,E4,E2) must be true or the state of these bits at a particular (16 bit, 10 MHz) time will not be seen by the trigger. This is important to remember! It is also important to remember that the rate of trigger memory FIFO loads (set by the OR of the DET1,VETO1,E4,E2 bits) that the trigger code can handle is limited by the speed at which the trigger code can process and unload the trigger memory words. If this rate is too high, the trigger code can not keep up, and either a latency condition will result (see below) or the trigger FIFO will go half-full which halts the loading of the FIFO and effectively stops data-taking.

The trigger code loops through the bit patterns stored in the trigger memory FIFO ( triggerdataword.c ) and combines the words that are contiguous in time (no skips in time in the trigger FIFO binary times). It combines these contiguous FIFO words into one "trigger data word" with a time equal to the first of the contiguous stream and bits equal to the OR of the bits from the stream.

In addition, the trigger code maintains an "activity stack" and an time-to-last-activity array. ( activitystack.c ). The activity stack is a list of the last 2048 (#define NMAX_ACTIVITY 2048) trigger data words. The time-to-last-activity array (act_dt) is an array of times to the last activity of a certain type (e.g. DET1, VETO1, etc). The time is held in a 32-bit unsigned integer, (units=100ns) and will wrap in 429 seconds. Currently, only the time-to-last-activity array is used. The activity stack could be used if it is deemed necessary to retrieve past events based on a current trigger pattern.

The code then uses the information from the trigger data word (plus history that is stored by the code) to determine whether to call a particular 16 bit time stamp address (the "base" TSA) an "event". If an "event" is found, then the trigger sends a set of TSAs around the base TSA to the trigger broadcast card which then distributes ("broadcasts") this set of TSAs to the QT crates which initiates a download of the QT data. The trigger types, number of TSAs, and offset of the TSA window are set in event_types.h

The various trigger types can be toggled on/off and prescaled by adjusting the control file /home/export/DAQ/share/trigger_conf_file. This file is read by the trigger code upon startup and these settings are used until the trigger code is restarteed.


Readout of the QT cards does not cause the cards to halt digitization. In this sense, we have a "deadtimeless" system. However, there are times when the DAQ is not taking data. This "deadtime" comes in 2 types:

Macroscopic Deadtime
This is when we are not taking data when the beam is on (missing neutrinos) because the DAQ is not running. E.g., in-between runs, recovering from a crash, operator error, etc. PAUSE and RESUME events (with GPS) times are generated by the trigger at the beginning and end of a run.
Microscopic Deadtime
This is when the DAQ is running, however, the trigger is stoped due to: a trigger unenable which may be caused by the trigger or QT fifos filling up. When this happens a PAUSE/RESUME event sequence is issued and the trigger and QTs are reset.

This deadtime is important to monitor as it changes the effective neutrino flux seen by the detector. To do this, the PAUSE and RESUME event GPS times must be recorded. The time between a PAUSE and RESUME is the deadtime of the DAQ system.


"Latency" is when the trigger is too slow in broadcasting TSAs of interest and by the time the data is requested from the QT sRAM, more than 2 microsecs has passed and the data is overwritten. It is known when this condition occurs as the trigger broadcast card returns the current time when a particular TSA is broadcast. If the current time minus the TSA is greater than 2 microsec then the data will be latent. This state is flagged for a given event by setting a latency bit. The principle cause for this condition seems to be loading words into the trigger FIFO at too high a rate. The trigger can not unload and analyze these trigger words fast enough and data becomes latent. This effectively sets a lower limit on the detector and veto comparator settings (and the rate on the trigger memory card BNC inputs).

If the latency bit is set for a particular event, the data in this event is not valid. This event must be rejected and the inefficiency caused by this should be calculated. With the current MiniBooNE trigger, the rates are quite low and latent events are rare. However, it should be monitored, as there are some hardware errors in the trigger system that cause this to increase dramatically.

MiniBooNE Trigger for Run Period 1

Find below the trigger settings that were used for MiniBooNE Run Period 1 (v4_2_1-Data5), which took place from 9/1/02 until 1/21/03.

Detector comparator settings:

trigger bit


trigger bit



# tank hits >= 12


# veto hits >= 6


# tank hits >= 24


# veto hits >= 4


# tank hits >= 40


beam on neutrino target


# tank hits >= 100


strobe (pulser)


# tank hits >= 500




hardware OR of Ebits


Using these bits and appropriate logic within the trigger code, these "windows" and "holdoffs" are created.

Trigger Windows/Holdoffs:

window name


condition (times in μs)


"beam holdoff"


T(E1) <= 20

Holdoff other triggers during beam event.

"Michel window"


3 <= T(DET4 && VETO1) >= 15

A cosmic ray candiate has occured in a window. Look for Michel electrons.

"SuperNova holdoff"


T(DET4) <= 15 ||
T(VETO1) <= 15 || T(E3: LASER) <= 2

A cosmic ray or calibration event has occured in recent past. Holdoff SN triggers.


Using these status of the bits in the current trigger data word and the conditions of the various windows and holdoffs, triggers are formed. beam_toggle 1 1 strobe_toggle 1 1 calib_toggle 1 1 mich_toggle 1 300 sn_toggle 1 1 tank_toggle 1 20000 veto_toggle 1 2000

Trigger Types:

trigger event type

trigger name



base TSA offset

# of TSAs broadcast




!BH && E1




Neutrino beam on target signal. This signal comes 5&mu;s before beam is on target so no addtional offset is needed.



!BH && E2




Pulser signal. Everything else just like beam triggers.



!BH && E3




Calibration OR.



!BH && MW && !VETO1 && DET2




Muon decay Michel electrons. The TSA window is large enough to contain the parent (cosmic-ray) muon.



!BH && !SNH && !VETO1 && DET4 && !DET5




SuperNova candidate.



!BH && DET1




Minimum bias tank tube trigger.



!BH && VETO1




Minimum bias veto tube trigger.



  1. LSND NIM paper: NIM A388, 149, '97.

  2. miniBooNE TDR

  3. "Data Acquistion Electronics and Programmer's Model, BooNE TN-038, Vern Sanberg, 2001.

  4. Slides from MiniBooNE analysis meeting, Rex Tayloe, 2/13/02, " .

  5. MiniBooNE CVS Repository, Trigger Source Code," , and"

Rex Tayloe

Last modified: Sat Feb 1 16:09:56 EST 2003