FNAL Outer Tracker June 2023 Test Beam

Here we collect all relevant info and instructions for the June 2023 Test Beam.

Contact jennetd@fnalNOSPAMPLEASE.gov, izoi@fnalNOSPAMPLEASE.gov with questions

Participant list

Documentation

Previous Outer Tracker test beam at FNAL https://iopscience.iop.org/article/10.1088/1748-0221/18/04/P04001

Required trainings: https://ftbf.fnal.gov/training-2/

Irradiation Target uniform fluence of 1.4e15 neq across MPAs 1-2, 15-16: https://indico.cern.ch/event/1273981/contributions/5350537/attachments/2632807/4581640/2023.04.20_Dickinson_ITA_updated.pdf

Correct stub settings https://indico.cern.ch/event/1273212/contributions/5346512/attachments/2626153/4541627/OT_SysTest_060423.pdf

Annealing time from Monday 8 at 10:00 to Thursday 11 at 9:45 (room temperature)

Skeleton testing: https://dbweb9.fnal.gov:8443/ECL/uscmsot/E/show?e=57 Module testing in burning Left part only https://dbweb9.fnal.gov:8443/ECL/uscmsot/E/show?e=60]] Full module https://dbweb9.fnal.gov:8443/ECL/uscmsot/E/show?e=62]]

Equipment list

• Chiller: Julabo DYNEO DD 600F (9021704.02)
• Coolant: Julabo Thermal C2
• Cold box: https://indico.cern.ch/event/1273983/contributions/5350551/attachments/2641412/4571163/04.23.2023%20Cooling%20Box.pptx.pdf
• Temperature sensor. To be built from this
• Humidity sensor from Thorlabs this one
• FC7. Recently tested at MaPSA probe station. Currently in the fishbowl cabinet
• Power supplies and cables
• PC is already available at test beam

Firmware

The firmware branch to be used is the master branch here : https://gitlab.cern.ch/cms_tk_ph2/d19c-firmware/

In the past, Inna and Younes had prepared a file to guide firmware configuration. Here it is : https://docs.google.com/document/d/12WWwv6G-DitV24OlTMG4XJJxAMPGw2b_kSclnFRF_GY/edit?usp=sharing

The FMC_FERMI_TRIGGER_BOARD is towards the end of the file for PS modules.

5G firmware compiled by Lesya is on lenny in /home/modtest/FWdevelopment/lesya/testbeam_firmware/compiles/v1 10G /home/modtest/FWdevelopment/lesya/testbeam_firmware/compiles/v2

ADC output calibration

To calibrate the ADC output run the following command. As a precaution I did it one chip at the time since the AMUX output is common to all chips and if the chip that are not being calibrated are not set to high impedance the output could be messed up.

 ot_module_test -f settings/PS_Module_v2.xml --reconfigure --runBias 

In the run output directory the file with the saved registers from the calibration is found (e.g BE0_OG0_FE0_Chip1SSA.txt). This file should be called in the XML to reload the calibration in the chip. Some control distributions are saved in the root file.

Trimming and s-curves

 cd /home/modtest/Programming/Ph2_ACF
source setup.sh 

Be sure that the settings/MyXML.xml has the right CIC version, module type, master patch, lpgbt version etc etc in it and that you are using the correct firmware. The first time you run on a module (assuming it has the LV on) you need to reconfigure it:

fpgaconfig -c settings/PS_Module_v2.xml -i ps_2m_5g_cic2
ot_module_test -f settings/MyXML.xml   --reconfigure

Run the usual noise test (if you already reconfigured the module you can remove the --reconfigure option to be faster):

ot_module_test -f settings/MyXML.xml   --reconfigure -b -m -a -t

The options are:

• -b to run in batch → no canvases popping up
• -t to do the trimming
• -a to run on all channels at once (important for PS modules to speed up the measurement)
• -m to measure the noise with the s-curves

For PSv2.1 it is important that:

• the clock to the SSA2.1 is inverted : cClkCnfg.fClkInvert = 0 in SystemController::ModuleStartUpPS https://gitlab.cern.ch/cms_tk_ph2/Ph2_ACF/-/blob/3eed51b294d9f13f57acce33c90a7d1e89384b9c/HWInterface/SSA2Interface.cc#L466
• EdgeSelT1Raw is set to 0x00 in PSAlignment::ConfigureDefaultAlignmentParameters https://gitlab.cern.ch/cms_tk_ph2/Ph2_ACF/-/blob/3eed51b294d9f13f57acce33c90a7d1e89384b9c/tools/PSAlignment.cc#L154

Stub and Latency calibration

WORK IN PROGRESS!!!

Check PS alignment:

 ot_module_test -f settings/PS_Module_v2.xml --realign --skipAlignment beStubs -b 

To debug the latency in the lab the commands are:

 ot_module_test -f settings/PS_Module_v2.xml --reconfigure --scanStubs --TestPulseCheck  -b 

 ot_module_test -f settings/PS_Module_v2.xml --reconfigure --scanL1 --TestPulseCheck -b 

 ot_module_test -f settings/PS_Module_v2.xml --reconfigure --scanLatencies --TestPulseCheck -b 

Procedure for Stub and Latency Calibration

Reconfiguration: To begin the reconfiguration process, it is crucial to select the appropriate signal injection type. In this case, we are concerned with Ps alignment. To implement the necessary changes in registers and alignment, execute the following command:

ot_module_test -f settings/PS_Module_v2.xml  --reconfigure

Scan: Now, let's move on to the latency scans of MPA, SSA, and Stubs. These scans help us determine the time delay, known as latency, between a charged particle passing through the Ps module and the production of a signal. For accurate latency measurements, the following command should be executed:

 ot_module_test -f settings/PS_Module_v2.xml --TestPulseCheck --save -b --scanLatencies 

Within the XML file, specific modifications need to be made to suit your requirements. Firstly, select the pixel-strip mode (0) as the mode of operation, enabling the desired functionality. Secondly, opt for the edge mode (0) for clocking purposes. Additionally, set the stub window to a value of 4, defining the permissible range for stub data.

 <StubLogic       mode="2" window="4"/> <!-- Mode (0) pixel-strip, (1) strip-strip, (2) pixel-pixel, (3) strip-pixel  --><!-- Window in half pixels, window will be strictly lower than the set value (ie set 4 -> window is 3.5 pixels) -->
                 <HitLogic        stripMode="0" pixelMode="0" pixelClusterCut="5"/> <!-- (0) edge, (1) level, (2) OR, (3) XOR  -->
                 <Latencies       stripLatency="296" pixelLatency="295" retimePix="4"/>
                 <Thresholds      stripThreshold="250" stripThresholdHigh="250" pixelThreshold="250"/> 
                 <!-- 0 : digital; 1 : analogue --> 
                 <Setting name="InjectionType">1</Setting>
                 <Setting name="TriggerMultiplicity">0</Setting>
                 <Setting name="StartLatency">285</Setting>
                 <Setting name="LatencyRange">20</Setting>
                 <Setting name="StubAlignmentScanStart">85</Setting>

Number of 10 ms periods to wait for in the case of stubs. L1 triggers sent once every 10 ms

 <Setting name="Nevents">500</Setting>

For the accurate measurement of stub latency, it is crucial to modify the corresponding register value within the XML file. In this case, the common_stubdata_delay is set to 218.

 <Register name="common_stubdata_delay"> 218 </Register>

This is the whole part that you need to look at when you are working on xml file and want to get latency scans. The time between when a charged particle passes through the device under test(ps module) and when the device produces a signal is known as the latency. The L1 time range spans from 0 to 300 it serves as a reference for measuring latency. For MPA and SSA, when the L1 time is less than 5, the pixel latency is fixed at 295 to ensures precise measurements. Stub on FPGA at T=82, this serves as a critical reference point for aligning and synchronizing the latency scans. To initiate the latency scans, we need to run the code and it will generate a root file to open that root file and check the L1 latency scans from SSA, MPA and Stub these are plots should be in one bin if they are not in one bin then we need to make the changes in above given snippet of code, The StartLatency setting, specified as #, defines the starting point for the latency scans the L1 time at which the scanning process begins. By setting this value appropriately, we ensure that the scans capture the desired latency information effectively. The LatencyRange setting, set to #, determines the duration of the latency scanning window. It indicates the range of L1 times that will be considered during the scanning process.The StubAlignmentScanStart setting, defined as #, marks the L1 time at which the scanning process for stub alignment commences. This setting is crucial for accurately aligning stub-related information and ensuring synchronization with other elements of the system.This ensures that the scanning window captures the desired latency data accurately. Once all the necessary configurations are in place, the data collection phase can commence. Execute the following command to initiate the scanning process and capture the latency data:

 ot_module_test -f settings/PS_Module_v2.xml --TestPulseCheck  --save -b 

By following this well-structured procedure, you can effectively reconfigure the necessary settings and perform latency scans on the Ps alignment using an analog signal.