Pixie Acquisition and Analysis Software Suite

Introduction

My goal is to build a software package that is maintained by a community of users. We want to make it easy for researchers to do their research. Scientific programs that combine physics and software development can be difficultto maintain. We call this software the Pixie Acquisition and Analysis Software Suite – Laughing Conqueror (PAASS-LC). We based our software on work by the Experimental Nuclear Structure Group at the University of Tennessee. This work is in no way associated or supported by UTK.

XIA’s DGF Pixie-16 modules provide an excellent hardware base for the software to build from. XIA recommends this software for use with these digitizers on Linux based systems. The software links directly to the PLX and XIA API libraries. We make no modifications to those libraries. End users do not need to worry about low level communication with the modules. The analysis software provides users a way to analyze acquired data.

We are working to bring the software up to modern standards. We are adding test coverage, and use continuous integration to ensure quality. The code is becoming DRYer and more SOLID. This process is slow going, since we’re dealing with a decade of code written by over half a dozen people.

We’ll go through some of the major features of the code in the following sections. We’ve broken this up into two parts: Acquisition and Analysis.

Data Acquisition

Module Configuration

We configure the crates and modules using the same method as your test software. Users use pxisys.ini, slot_def.set, and pixie.cfg to configure module communication. CMake generates pixie.cfg based on user installed firmware. We use these three files (along with default.set) to boot the modules. Users can configure the system for

  • Mixed Revision (i.e. RevF / RevD)
  • Mixed Frequency (i.e. 100 MS/s and 250 MS/s)
  • Mixed Bit Resolution (i.e. 12, 14, or 16)

We do not support booting multi-crate systems. This feature, is on our radar, but we do not have the resources to work on it at this time.

We provide users with a program called set2ascii. This program converts a set file to ascii using the DSP var file. Users run this program when they need information from the set file, but cannot boot a module.

Module Setup

Our main DAQ program “poll2” handles all module communication. It includes functions to manage the channel and module parameters. We have written utility programs based on XIA functions that allow

  • Modification of module and channel parameters
  • Capture and tuning of the channel baselines (VOFFSET)
  • A toggle program that allows users to toggle specific bits of the CHANNEL_CSRA.

Poll2 uses ncurses, and provides a terminal based GUI for users. It has command history, tab completion, and scripting. We wanted the GUI to mimic use in a bash environment.

Data Collection

MCA

We provide a C++ class that collects MCA spectra and outputs them for use in ROOT. We couple MCA with a parameter scanner that optimizes energy resolution for peaks.

List Mode Data

We collect list mode data in much the same way as your test program. We allow users to adjust how full the FIFO gets before reads. Users have two choices for list mode data.

First, they can write data to a file. We package it into either an LDF or a PLD. LDFs are data formats used for decades at ORNL. PLDs are an experimental format being developed at UT. I am writing a new data class that will store more metadata useful during analysis. The #1 priority of the list mode data mode is writing data to disk.

Second, users can broadcast the data over a shared memory buffer (SHM). This allows other programs to listen for the data and perform operations. We provide a rate monitor that outputs the ICR and OCR rates for the modules and channels. All analysis programs can use the shared memory buffer to analyze data on the fly. When using SHM users can start the acquisition without writing to disk. This is useful when checking rates, or to determine the effect of TrigConfigs.

Data Generator

We recently developed a simple code that creates data files for users. We made MVP available in the master branch. The program packages data in the same way that modules do. When coupled with the updates in the v4 branch, users will be able to simulate spectra for analysis.

Features in the works

Dummy Interface

At the moment, our only interface uses the XIA API to talk to the modules. We have an experimental v4 branch that includes a new interface structure. It allows users to use the DAQ software without hardware attached. Unfortunately, there are some bugs that prevent Pixie16 modules from booting properly. The interface can train students and researchers how to to use the DAQ.

Custom data format

We are developing a custom data format that will record the specific firmware used to acquire the data file. We’ve found that users often forget to record this information into their logbooks.

Analysis

I have been doing most of my work around the data analysis packages. I’m focused here since I do not have a DAQ to develop with.

Analysis Libraries

XiaListModeData{Encoder, Decoder, Mask}

These classes provide the functionality needed to encode or decode any XIA header. We worked with XIA to create a historyof the changes to the list mode data headers. The history provides a time line of changes to the header. It ensures we use the correct bit masks when decoding list mode data. XiaData stores all the raw information collected by the Pixie-16 modules.

Unpacking

The unpacking classes read list mode data files from poll2. It uses the XiaListModeDataDecoder to decode module data. This class also performs basic statistics as its unpacking data.

Event Building

After we unpack the data, we package them into time structured events. We define an event as any group of channels that fired within a user specified time window. This allows users to analyze time structures and correlations in their data.

Utilities

  • Event Reader – The event reader reads a data file and outputs the events to the terminal.
  • Head Reader – Reads metadata from the list mode data files
  • Hex Reader – Reads data from list mode data files and outputs to the terminal in hex format.
  • Root Scanner – This program provides on-the-fly histogram generation in the ROOT framework. It produces a ROOT file containing the data.
  • Scope – Used to view traces in list mode data. It analyzes traces using CFDs, Fitting Algorithms, or Trapezoidal Filters. Use with SHM mode to set appropriate trace lengths and delays. We adapted Trapezoidal Filter algorithms from an Igor script provided by H. Tan at XIA.
  • Skeleton – A bare bones (get it?) program provided for users to build their own analysis.

Utkscan

This is the main workhorse analysis program. It provides a bunch of classes that are capable of analyzing many detector types. We have written this in a modular format to maximize usability. As the UT group has run experiments we expanded this to analyze many different detectors. Utkscan includes modules for experiment specific analysis. This allows users to expand the functionality without modifying core features. An XML configuration allows users to reconfigure the software without recompiling.

Summary

PAASS-LC provides users with a solid base for their DAQ and Analysis needs. We provide direct access to the Pixie-16 modules for configuration, and have a shared memory system in place. Researchers can use the built in analysis software or roll their own solution.

Leave a Reply

Your email address will not be published. Required fields are marked *