DAQ software stack—TRLO II, Nurdlib, drasi...

General Information

Overview of the DAQ software stack (primarily) maintained at Experimental Subatomic Physics at Chalmers.

It consists of several components, that can be used together or individually with other systems.

Each component has its own means of distribution (typically git) and documentation. The purpose of this page is to cover some combination topics that are not naturally described along with the respective tools.

Mailing list: subexp-daq@lists.chalmers.se (archives).

Components

In rough data-flow order:
TRLO II
Flexible FPGA trigger control.
Nurdlib
NUstar ReaDout LIBrary — the definite library for readout of data collection modules commonly used in nuclear physics experiments.
r3bfuser
User readout routine.
drasi
DAQ (network) data pump — DAQosaurus parati scintilla.
ucesb
unpack & check every single bit — Bridging the gap between DAQ systems and data analysis tools.
plutt
Scriptable spectrum monitor for experimental data — online histogramming

Download and building

Instructions for setting up a Nurdlib-TRLO II-r3bfuser-drasi-ucesb data chain.

Reduced instructions for a free-running Mesytec MDPP16 (SCP) with a CAEN V2718 controller and Nurdlib-drasi-ucesb.

Hardware

Communication with digitization modules is mainly the responsibility of Nurdlib.

When GSI TRIVA modules (or mimiced with TRLO II TRIMI) are used for event synchronisation between crates this is handled by drasi.

VME controllers

Name SiCy MBLT Notes
Motorola MVME5500 1.2 μs 11 MB/s
CES RIO4 0.40 μs 36 MB/s
CAEN Vx718
Mesytec MVLC Work-in-progress (info, using cmvlc)

Performance

For best performance in triggered mode, do the readout in parallell with conversion, as described here: VME Readout at and Below the Conversion Time Limit.
That way, single-event readout latency is irrelevant—up to the limit of available readout bandwidth.

To evaluate the performance of any(?) DAQ system, use two counters (scalers) to determine momentary rates (e.g. as 1-second averages): requested and accepted triggers. Then plot the livetime ratio (accept/request rate) as function of reqested trigger rate. (For a free-running/trigger-less system, let the 'trigger' be any critical signal.)

Comments? f96hajo@chalmers.se

Last modified: Sun Feb 16 11:36:22 CET 2025