RICH 2014 Testbeam DAQ
Summary and Quick Start Guide
The front-end data are acquired by the DBs (digital boards) that are connected to the ECs (elementary cells). The DBs capture events in response to external triggers (pulser or beam), format the data into MEPs (multi-event packets) and transmit the MEPs to the DAQ PC using Gbit Ethernet. Configuration of the DAQ and the front end electronics is via the same Gbit Ethernet links. The DAQ PC is located in the beam area.
Control of the acquisition is done using Java GUIs. The
JRichEcConfigurator GUI manages sets of elementary cell configuration parameters. The
JRichEcControl GUI takes care of run control functions. These GUIs have superseded the ones used in the beam tests. The main difference is that the management of the EC configuration parameters and the run control functions have been separated. The GUIs are described in more detail in their respective topics. A helper program (
feb-proxy
, that is started automatically by the GUI) forwards configuration packets to the DBs over the network and receives the data packets from the front-end. The packets are decoded by
feb-proxy
and the data saved in
MDF format, one file per DB.
To start the DAQ, first log on to the DAQ account on the DAQ PC. This is usually done using
ssh -Y
from a PC in the control room. Type the command
start_daqgui
at the prompt to start the GUI. Changes to the settings are saved by the GUI and the last saved settings are restored when the GUI is started. A second GUI is used to control and monitor the trigger sources. To start it, use the
start_trigger
command then click on the
Connect
button.
To start a run, first choose the desired trigger source from the trigger GUI (usually
Pulser
or
Beam
) then click
Start
on the DAQ panel to start acquiring data and
Stop
when you have finished. Data are saved to disk only if the
Recording
box is checked. The
Save preferences
box should also be checked to ensure that the settings are saved at the start of each run. The run number is incremented automatically when starting a new run but can also be manually set (set it to one less than the number you want for the next run).
Name of DAQ PC |
lbrichtb.cern.ch |
DAQ login |
richtbuser |
DAQ netmask |
192.168.2.0/24 |
DB 1 IP |
192.168.2.10 |
DB 2 IP |
192.168.2.11 |
PC DAQ NIC IP |
192.168.2.128 |
Data directory |
lbrichtb:/work/tb2014/data |
BB IOEx I2C |
66 (dec) |
BB DAC I2C |
152 (dec) |
The Trigger Logic and GUI
The trigger logic is implemented in an FPGA on a Nexys3 module and is controlled by a Java GUI. The trigger logic board receives an external beam trigger signal which is conditioned and fanned out to the DBs. The board can also generate pulser triggers that are fanned out in the same way. The logic also receives a gate signal from each connected DB indicating that it is ready to accept a trigger. Triggers are only sent when the gate signals of all connected DBs are asserted. The DBs may deassert the gate signal to prevent buffer overflow at high trigger rate. The gate signals are also used to disable triggers when a run is not in progress under control of the DAQ GUI.
The trigger outputs and gate inputs use LVDS differential signalling. The external trigger input is 50Ohm terminated LVTTL. One of the trigger outputs is sent to the beam telescope trigger input via an LVDS to LVCMOS translator.
The trigger GUI displays a number of counters:
Counter name |
Description |
External Tclk |
Number of rising edges on external clock input |
Gated trigger |
Number of triggers for currently selected gated trigger |
Ungated beam |
Number of ungated beam triggers after input conditioning |
Gated beam |
Number of gated triggers after input conditioning |
Telescope |
Number of trigger pulses to telescope |
Gated pulser |
Number of gated pulser triggers |
Radio buttons allow to select between three trigger sources (
Pulser
,
Beam
or
FEB
) or
None
. Buttons are provide to reset the counters and to log the current values of the counters in the elog.
The logic board performs some conditioning of the external input by enforcing a minimum time between triggers of about 400ns.
--
StephenWotton - 13 Oct 2014