apollo user manual - infn genova

Apollo User Manual

S. Di Domizio,1, 2 A. Giachero,1, 3 E. Guardincerri,4 and M. Pallavicini1, 2

1Universita di Genova

2Sezione INFN di Genova

3Laboratori Nazionali del Gran Sasso

4Nuclear Science Division, Lawrence Berkeley National Laboratory

(Dated: May 14, 2007)

Contents

Introduction 1

1 Running Apollo 3

1.1 Intoduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Running Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Data taking modes of Diana within Apollo . . . . . . . . . . . . . . 31.2.1.1 Mode 0 - Normal . . . . . . . . . . . . . . . . . . . . . . . 31.2.1.2 Mode 1 - LoadCurve 1 . . . . . . . . . . . . . . . . . . . . 31.2.1.3 Mode 2 - LoadCurve 2 . . . . . . . . . . . . . . . . . . . . 31.2.1.4 Mode 3 - LoadCurve 3 . . . . . . . . . . . . . . . . . . . . 4

2 Installation of Apollo 5

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Processes running in Apollo 7

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 Processes definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4 Data Base for Apollo 9

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5 Graphical User Interface 11

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.2 List of GUI windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6 Trigger 13

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136.2 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

7 Load Curves 15

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157.2 Description of the procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 15

7.2.1 Step 0: Best gain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

ii CONTENTS

7.2.2 Step 1: I-V curve . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167.2.3 Step 2: Heater scan around IP . . . . . . . . . . . . . . . . . . . . . 167.2.4 Step 3: Measure average heater pulse and noise in heater curve . . . 17

7.3 Implementation details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187.3.1 Inter Process Communication . . . . . . . . . . . . . . . . . . . . . 187.3.2 Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187.3.3 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

7.3.3.1 Init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197.3.3.2 Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207.3.3.3 Done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7.3.4 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Introduction

To be done

Chapter 1

Running Apollo

1.1 Intoduction

To be done

1.2 Running Mode

To be done

1.2.1 Data taking modes of Diana within Apollo

Diana is used to perform several online operations with different set of modules andconfiguration files. The following is a preliminary list of ”modes” with their function anduse.

1.2.1.1 Mode 0 - Normal

All trigger used defined; heater may be on of or off according to user needs; online monitoravailable; raw data output enabled; single channel DAQ according to user selection. Thisis the normal physics running mode.

1.2.1.2 Mode 1 - LoadCurve 1

Random trigger WYQApolloRandomTrigger; no heater; compute channel voltage baselineafter stop using Diana module MDaqComputeBaseline; data saved in a temporary files.


Heater trigger QApolloHeaterTrigger; heater on; compute peak-base amplitude spec-trum for each channel in module MDaqHeaterIVAnalysis; data saved in a temporary

4 Running Apollo

files.


Heater trigger QApolloHeaterTrigger; heater on; compute peak-base amplitude spec-trum for each channel using Optimum Filter. The very same modules that are used indata analysis will be used to compute the average pulse and to compute the optimumfilter. The final module MDaqFinalIVAnalysis will compute the best working point foreach channel and save into database.

Chapter 2

Installation of Apollo

2.1 Introduction

To be done

Chapter 3

Processes running in Apollo

3.1 Introduction

The following processes are needed by Apollo: DataReader, DataSender, DataReceiver,Builder, DaqServer, SlowServer, MsgServer and ApolloGUI. In case all proceesses runon the same machine (like for example in Hall C) the DataSender and DataReceiverprocesses do not exist.

3.2 Processes definition

The follwing is a brief description of these processes and their functions:

- DataReader: it is the process that continuosly reads data from all channels defined,and apply triggering and possibly filtering algorythms to the data. At this levelthe trigger algotythms just flag the events, without creating the pulses. All dataare then stored into a shared memory segment (one for each channel). There is oneDataReader process for each DAQ crate. In Hall C (and possibly also in Hall A inCuoricino), there is only one DAQ crate. In Cuore the number will be of the orderof 10 or less.

- DataSender: a processes that simply take date from the DataReader shared mem-ory and send it to the Builder machine via network (TCP/IP connection). ADataReceiver is there available to collect this data and fill a shared memory seg-ment that is identycal to the one filled by DataReader. In this way the coupleDataSender/DataReceiver can be just removed when everything is installed in thesame machine.

Chapter 4

Data Base for Apollo

4.1 Introduction

To be done

Chapter 5

Graphical User Interface

5.1 Introduction

This section describes the main features of the Apollo Graphical User Interface (ApolloGUI).

5.2 List of GUI windows

The Apollo GUI is made of the following windows:

• Main Apollo Window: This is the main entrance window of the whole GUI. Allother windows can be open from here. This window handles directly the followingfunctions:

– Login: User authentication. Without login no action is allowed. Users thathave a valid login password can be:

∗ GUEST: only viewers of the status of the system. A GUEST can look athistograms or data but cannot change the status of the system in any way

∗ OPERATOR: can start or stop run, and not much else

∗ EXPERT: can perform settings, change hardware parameters, create newprofiles and such

∗ ADMINISTRATOR: can do everything

See ?? section for more details.

– System Setup: Setting of all Apollo Environment variables (i.e. Data Baselocation, computing system variables and similar). See section ?? for moredetails.

• Profile Manager Window: This window allow to create, modify and view a database profile. A new profile can be created starting from the existing status of the

12 Graphical User Interface

system or copying from an already existing profile. Only EXPERT or ADMINIS-TRATORS can use this window.

• Slow Control Window: This window allow to set/view hardware parameters forFront End, Bessel, Pulser and DAQ boards parameters. This window cannot beused during data taking, unless a special test run is in progress. Only EXPERTor ADMINISTRATORS can use this window. A very low level interface is alsoavailable to address physical registers (by-passing logical channel address system).This very low level interface can be used by ADMINISTRATORS only. See ?? fordetails.

• Run Controller Window: Handles start and stop of a given run, allowing triggersetup, profile selection, and options concerning data file saving, format and so on.

• Run analyzer: This is the main window of the data analyzer system. From thiswindow a set of different windows can be open to view data during data taking fordata quality assurance. The list of sub-windows include:

– Single channel analyzer: Displays infos and histograms of data of a singlechannel. Histograms are update real-time during data flow. There are no limitson the number of histograms available, although up to 4 or 8 (depending onmonitor size) can be displayed at the same time. The list of histograms include:

1. Baseline at full resolution (last 5 seconds)

2. Medium resolution baseline (last 10 minutes)

3. Low resolution baseline (from the beginning of run)

4. Sigma baseline after pulse removal (3 histograms as for baseline)

5. Triggering pulses in real time (all pulses)

6. High energy triggering pulses (same as above with high energy threshold)

7. Channel energy spectrum (simple energy calculation as peak-base)

8. Channel energy spectrum with pulser triggers only

9. Channel energy spectrum with particle triggers only (everything but pulser)

10. FFT spectrum of noise after pulse removal

11. FFT spectrum including pulses

– Global analyzer: Displays infos and histograms of data of the whole collec-tion of channels.

Chapter 6

Trigger

6.1 Introduction

We define a trigger an algorythm designed to search, identify and tag any interesting fea-ture (e.g. a pulse) in the data flow of a single DAQ channel. Apollo supports the existenceof several trigger algorythms running at the same time. The number of algorythms is inprinciple unlimited, although in the current implementation no more than 4 can be run atthe same time in a given run. The trigger parameters can be tuned channel by channel.

The trigger algorythms are executed in DataReader.

6.2 Setup

The table trigger in qdaqcontains the trigger setup informations for each run. There are14 fields:

1. run: the run number this record refers to. There must be a record for each validrun.

2. lg: the logical channel number this record refers to. A record with lg=0 is mandatoryfor each run. This record will act as default trigger setup for all channels that areNOT explicitely listed in the following records.If lg is different from 0, the triggersetup of the corresponing channel is overwritten. In this way we can have all channelswith the same trigger parameters by writing the record with lg=0 only, or we cantune channel by channel adding more records.

3. trg1 enable Enable flag for trigger 1 for this channel (or the default value for lg=0)



14 Trigger


7. trg1 name The name of the trigger 1 active in this run.




11. trg1 parsA string describing the parameters for trigger 1 algorythm for this chan-nel, and this run. The syntax of this string must be key1=val1;key2=val2 etc. Thenumber of parameters is unlimited.

12. trg2 parsA string describing the parameters for trigger 2 algorythm for this chan-nel, and this run. The syntax of this string must be key1=val1;key2=val2 etc. Thenumber of parameters is unlimited.

13. trg3 pars A string describing the parameters for trigger 3 algorythm for this chan-nel, and this run. The syntax of this string must be key1=val1;key2=val2 etc. Thenumber of parameters is unlimited.

14. trg4 pars A string describing the parameters for trigger 4 algorythm for this chan-nel, and this run. The syntax of this string must be key1=val1;key2=val2 etc. Thenumber of parameters is unlimited.

Chapter 7

Load Curves

7.1 Introduction

In general the Working Point (WP) of a resistor, or semiconductor, is the point wherethe I-V curve (also called Load Curve) intersects the load line. If, in this point, thesignal/noise ratio is maximized that is called Optimum Working Point (OWP).

Load Curves procedure aims to determine the bias voltage VB that gives the bestsignal to noise ratio as output. Moreover the procedure draws the whole I-V curve and,for a limited set of points surrounding OWP, the relative pulse amplitude.

7.2 Description of the procedure

The Load Curves procedure is split up in several steps: each of them is described in detailin the following subsections. Each step aims to determine some quantity that either isneeded in following steps or is itself of physical interest. Each step is made of two parts:the former consists mainly in measurements while the latter is an overall analysis of theacquired data.

Data acquisition is done using Apollo while Diana is used for data analysis. VariousDAQ running modes are needed during the whole procedure. In what follows runningmodes are only recalled when needed; they are described in detail in section 1.2.

First step aims to determine the biggest gain value that allows the drawing of the wholeI-V curve without reaching Front-End or ADC saturation (step 0); next the I-V curve ismeasured and some useful quantities are evaluated (step 1); in step 2 the range whereOWP is expected to be found is scanned with heater pulses, leading to the determinationof the Maximum Amplitude Point, (MAP); finer measurements and analysis are thenperformed in the last step (step 3): the OWP is determined measuring the OptimumFilter amplitude for several VB values around MAP.

As will be explained later step 3 is quite time-consuming, so the Load Curves procedureallows the possibility to skip it an stop when the MAP has been found.

16 Load Curves

7.2.1 Step 0: Best gain

This preliminary step is required to avoid saturation during load curves procedure. Atreasonably low gain GL, I-V Curve is measured with rough steps. Once the InversionPoint (IP) is found, gain can be set to the maximum value Gbest that prevents fromsaturation at that point. Gbest is given by Gbest < GL · Vbest/Vout(IP), where Vbest is themaximum output voltage allowed by Front-End and DAQ, and Vout(IP) is the outputvoltage measured at IP with gain GL. If IP is not reached Vout obtained at max VB is usedinstead of Vout(IP).

Measurement part of step 0 is made as follows:

1. Channel gain set to a reasonable low value;

2. All bias set to zero nominal;

3. Start data taking with anti-trigger in order to remove possible pulses and to evaluatethe baseline (data taking Mode 1);

4. Increment bias with a rough step, go back to point 3 until end of bias scan;

At the end of this step each channel defined in profile has a proper gain value. Gainis saved in the database cache and Bias is set to zero nominal.

7.2.2 Step 1: I-V curve

The goal of this step is to meausre the wole I-V curve. Performed measurements arethe same as in Step 0, but with much finer bias step and gain set to Gbest. At theend of the measurement part, the whole I-V curve (LC, Load Curve) is saved by moduleMDaqBuildIVCurve into the database cache (and/or temporary files??).

Analysis part consists of fit of the ohmic region with a line and, if possible, calculationof IP. Around IP an interval (IMD, Interval for Maximum amplitude Determination) is alsoevaluated, which is the interval around IP that will be scanned with heater pulses in step3. This operation is done by MDaqIVCurveAnalyzer. At the end all I-V curves (one foreach channel) are saved into database.

7.2.3 Step 2: Heater scan around IP

The goal of this step is to find the MAP scanning the I-V curve with heater pulses. In orderto minimize measurement time, not all the I-V curve is scanned, but only those pointsbelonging to the interval IMD determined in step 1. Choice of heater pulse amplitude isnot critical; anyway two approaches are possible (to be fixed):

– choose amplitude corresponding to energy as close as possible to DBD region

7.2 Description of the procedure 17

– choose max allowed amplitude (compatibly with Front End and ADC range), sincehigher amplitude results in better measurement

Heater scan is made of the following points:

1. Channel gain ad offset set to value deteminated in step 0

2. All bias set to the beginning of IMD interval.

3. Start data taking Mode 2;

4. Increment bias with proper step within interval IMD.

An alternative approach can be defined for heater scan:

1. Channel gain ad offset set to value deteminated in step 0

2. Bias set to the IP;

3. Start data taking Mode 2;

4. Decrease bias with quite big step;

5. If newly acquired pulse amplitude is higher than the last one, then proceed in thesame direction and with the same step size, otherwise dcrease step size and invertdirection;

6. Proceed as in point 5 until a local maximum is found.

Notice that the alternative approach assumes that pulse amplitude has only one max-imum in the scanned region, and requires movements along load curve in both directions.

After analisys of Heater Curve (HC), MAP is determined and saved into temporaryfiles (or in data base in case step 3 will be skipped).

7.2.4 Step 3: Measure average heater pulse and noise in heater

curve

Scan as Step 2 but using run Mode 3. For each point belonging to IMD, or for a subset ofthem, measure multiple baseline samples and heater pulses. Minimum number of acquiredbaseline samples and heater pulses to be fixed. Analysis part of this step will calculateNoise power spectrum (NPS) and Average Pulse (AP) from acquired data; once OF isbuilt, pulses acquired in step 2 (or step 3 itself) are filtered and OWP is determined. Allinformations saved into Db.

Notice that the only difference in measurement part between steps 2 and 3 is thenumber of acquired pulses. So, if step 3 is performed, measurement part of step 2 can beskipped.

18 Load Curves

7.3 Implementation details

In order to succeed in OWP determination and I-V curve drawing, several software toolsare needed. Involved processes are Apollo and Diana as usual, but some specific featuresand dedicated Diana modules are necessary. This section is focused on the details ofsoftware sructure design.

7.3.1 Inter Process Communication

Since several processes are involved in the Load Curves measurement procedure, a master

process must be defined that is in charge of taking decisions and controlling the wholeprogram flow. The two possibilities are DaqServer and Diana. While DaqServer isobviously the best choice for what concern process control capabilities, Diana would bebetter for taking decisions based on acquired data. In both cases some new code has tobe developed, introducing the missing features in the process that is chosen to be the“master”. Probably the best solution is to choose Diana as master process, since thisallows event by event control of program flow. Thus in order to control other processesand to update Front End parameters during execution, a special module is required thatis able to interact via socket with the DaqServer.

7.3.2 Sequences

From the point of view of Diana structure, each of the steps described in 7.2 can beimplemented as a sequence: measurements are event based and can be implemented inDo() methods, while analysis part is based on a set of events and can be implementedinside one or more Done() methods. If needed, sequence can be iterated many times,until the analysis part decides that the current step has ended succesfully. A single se-quence iteration measures in parallel a given set of channels and results in a completemeasurement for that set. When Done() methods are called an overall analysis is per-formed: relevant physical quantities are evaluated and saved for those channels that passvalidation; channel that didn’t pass validation are grouped in a new set and sequence isiterated again for them. When all channels of a set have passed validation the sequenceis iterated again, but with a new set of channels. In what follows a typical sequence isbriefly described. Each module is descibed in more detail in section 7.3.3. Different stepscan require specific modules, but the overall structure is the same.

– reader:

read data from shared memory;

– validator:

validate acquired data basing on single measurement (no drift...);

7.3 Implementation details 19

– analyzer:

perform a preliminary analysis based on all acquired samples and determine settingsfor next measurement;

– actuator:

this modules simply implements a socket client able to send commands to theDaqServer and is tipically used for updating Front End settings according to deci-sion taken by analyzer module;

– writer:

almost standard Diana writer.

7.3.3 Modules

This section is structured as follows: for each of the three main operations inside asequence (Init(),Do(),Done()), the features to be implemented in each module are de-scribed.

The most troublesome aspect is multiple processes synchronization, that is necessaryin order to associate a triggered sample with the exact Front End settings. handling ofsynchronization is only sketched in the following procedure and needs further development.Some comments on that can be found in section 7.3.4.

7.3.3.1 Init

• reader:

- read the total number of channels to be measured from config file or elsewhere

- shared memory initialization

• validator:

- nothing relevant

• analyzer:

- read the total number of channels to be measured from config file or elsewhere

- read the minimum time between two subsequent measurements on the samechannel from config file or elsewhere

- determine optimal channel grouping based on the previous two informations

- determine initial Front End settings for all channels belonging to current set

- choose current channel (i.e. the first channel to be acquired)

• actuator:

20 Load Curves

- set initial Front End settings as specified by analyzer module and wait forresponse from DaqServer

- enable trigger

• writer:

- nothing relevant

7.3.3.2 Do

• reader:

- search for trigger (only for current channel?? to be defined); current channelis detemined from auxData

• validator:

- simple filter module: check if sample is valid and set skipEvent flag accordingly

• analyzer:

- extract relevant quantites from acquired sample (average voltage in case of I-Vcurve, pulse amplitude in case of heater scan...)

- based on previous measurements and current one, take a decision on nextmeasurtement point (can also repeat same measurement)

- determine new Front End settings if necessary (auxData)

- increase current channel if needed (auxData)

• actuator:

- inhibit trigger (to be defined)

- update Front End settings (read auxData from analyzer)

- wait for server response

- re-enable trigger (to be defined)

• writer:

- to be defined

7.3 Implementation details 21

7.3.3.3 Done

• reader:

- to be defined

• validator:

- nothing relevant

• analyzer:

- results of the current step are evaluated here (auxData)

- if necessary, new Front End settings are determined (auxData)

• actuator:

- update Front End settings (read auxData from analyzer)

• writer:

- write relevant quantities into db and/or files (auxData from analyzer)

7.3.4 Comments

This section contains some comments on process synchronization. Since data acquisitionand data analysis processes are asynchronous, some trick must be found in order to makeDiana aware of which hardware settings correspond to the samples being analyzed at agiven time. Moreover not even data acquisition process (DataReader) is aware of changesin Front End settings, since another process (SlowServer) is responsible for that.

The key to solve synchronization problem is to identify without any ambiguiy a timewindow characterized by a given set of Front End parameters. This can be achieved if anychange in Front End settings is bot anticipated and followed by a flag inside data stream.This way each set of Front End configurations can be assigned a unique identifier. Theidentifier is set and then read by the same process (Diana), so there are no conceptualproblems. There are two critical points in doing this:

- group settings in such a way that they are actually applied to Front End as rarelyas possible, in order to minimize measurement dead time.

- find a way to set the flag on data stream when a signal is received by DataReader

process.

apollo user manual - infn genova

Documents