Proton Calorimetry/Equipment/QuARC General Information

QuARC Information Summary

1. Scintillators

The main properties of our scintillators are:

• ρ = (1.03±0.01)g cm-3
• decay constant = 2.5 ns
• maximum emission at 425 nm (blue-violet)
• light output = 56% of anthracene
• n = 1.57

In total we have 302 scintillator sheets. Their production mechanisms and average thicknesses are summarised in this file []. The order in which the scintillators are assembled in each stack is available in the GUI, inside every experimental run log.

• Each sheet thickness is measured in 8 different points of the scintillator: 4 corners, and 4 middle parts of each side.
• The uncertainty is simply calculated as the standard deviation.
• For the scintillator stacks used in Manchester and PARTREC we measured the thickness in 3 points.
• Clear polished scintillators (machine block) offer the best light output.

2. Photodiodes

The first prototype of the QuARC had a CMOS sensor, but it was then upgraded to photodiodes coupled to each sheet individually. There is a direct coupling, so no optical gel is used.

• Model = hamamatsu S12915-16R
• Effective photosensitive area = 6.0 mm2
• Spectral response wavelength between 340-1100 nm
• Quantum efficiency peaks at 960 nm

3. Boards: DDC232

We have two different types of boards (revB and revC) that differ in the number of PD and the space between them. They are directly coupled to the PD, and need a power cable and a PMOD connection that goes to the FPGA.

• revB: 16 photodiodes, spaced 2.86 mm. Uses 12V power cable.
• revC: 32 photodiodes, spaced 3.0 mm. Uses 7V power cable -> revD is a modification of revC, with a change in the heat management.

4. FPGA

The FPGA is used to read the boards and transfer the data to the PC. The FPGA automatically loads the last code designed, but if not we can load it with Vivado: the code used is FTDI.h, which uses libFTDI libraries so they need to be installed in the laptop. We have 2 different boards:

• Nexys board:
• usb104: powered via USB and connected to the board with a PMOD cable.

If we want to run the DAQ, first we have to compile the code as follows:

MacBook: g++ -L/opt/local/lib -I/opt/local/include/libftdi1 -lftdi1 -std=c++17 -O3 FTDI.cpp -o FTDI
Nuc PC: g++ -L/usr/lib64 -I/usr/include/libftdi1 -lftdi1 -std=c++17 -O3 FTDI.cpp -o FTD​I

We can then run the code with the adequate parameters:

./FTDI nexys/usb104 num_DDCports FSR t_INT(us) nmeasurements outputfile board (testmode)

We can also visualise "live" (reads from average.csv) using the livePlot code.

g++ -o livePlot livePlot.cpp `root-config --cflags --glibs` -O3 

./livePlot num_DDCboards FSR yScale revB/C reversetrue/false (clean folder background.txt backST.txt frontST.txt ...)

Running FTDI code the average time per read should be ~170us, giving a data transfer speed of ~0.47MB/s.

• We acquire data using FTDI.cpp code, changing the output file to Run001.txt, Run002.txt and so on.
• If we want to acquire data and show it live we need to use progh.sh

 ./prog.sh nexys/usb104 4 350 0 170 100000 50 true capture.txt revB/C true/false (fit/test/clean) (folder background.txt backST.txt frontST.txt ...)

5. Data analysis

Two different codes are used for the data analysis: replay.py and fit.cpp, their functionalities are described below.

replay.py code calibrates and subtracts the background of each measurement, generating an output text file with header information, all the individual calibrated measurements and the average of them all. An example file with data from Clatterbridge Hospital of what the generated file looks like can be found here [1], every individual run fit takes ~3.3s on a MacBook to be completed. All of them can be processed together by running the shell script ./replayshell.sh. To run this code we need the following arguments:

python3 replay.py t_INT framerate skipahead reverse folder run background backST frontST

fit.cpp averages the data at a user specified frequency (or generic 25 Hz) and then performs Bortfeld and Kelleter fits to the data. After the fitting, the beam energy and range are extracted for each of those averaged measurements. All of them can be processed together by running the shell script ./fitshell.sh An example of what the output of fit.cpp looks like can be found here [2]. This code needs to be compiled, and then run with the appropriate arguments.

g++ -o fit fit.cpp `root-config --cflags --glibs` -O3
./fit reverse energy facility folder run (frequency)

To show these data in the GUI a shell script that iterates through the lines of the fitted output file is necessary.

Previously both of the codes were developed in cpp. The replay.cpp replays the DDC232 acquisition by either stepping through each measurement or averaging measurements at specified frame rate, while fit.cpp performs the fit on calibrated and background subtracted data.

Questions

• Boards: What needs to be done to them? Vivado codes into FPGA but boards? Daisy chaining? What was done in terms of usbC connection?
• FPGA: no longer using nexys? What issues did we have with both of them?
• Experiment: just use FTDI code changing the run number? where are these runs saved? Possible errors during data acquisition? test mode?
• Data analysis: parameters for fit based on what?